Computer added to domain does not appear in Computers

Hello friends, I am again raising a testing environment for a service that I will have to start this week and I am facing some problems in Univention 4.1-4. This time I uploaded the domain correctly and it is working correctly, I added a Windows 10 and it responds to DNS and everything.

The problem is that after adding I went to Devices -> Computers, however only the dc01.multiti.local Univention is listed, the WIN10-TI01 is not listed.

The same occurs in DHCP, in DNS it has the registry created correctly, but in DHCP there is no object named WIN10-TI01.

Has anyone been through this or know if this is a bug to report?

is that consistent, so no matter what, your computers do not appear in the UMC? Is the Win10 able to use all of the domainfunctions? Can you execute on the UCS server as root:

# univention-s4connector-list-rejected

and have a look at the “/var/log/univention/listener.log” and the “/var/log/univention/connectors4.log” if there are interesting tracebacks? What version of UCS are you using?

I made the installation of 4.1-3 and this bug does not exist, both FreeNAS and Endian Firewall can recover users correctly, either using the interface or wbinfo -u / -g

I’ve already opened a ticket on the Univention calling system warning you of the problem: forge.univention.org/bugzilla/s … i?id=43253

If I had seen this before I would have tested to see if it would solve or not, but I installed the previous version over the new one in Virtualbox and I do not have a snapshot.

You are jumping from one issue to the next. In the first post you say, there is a Win10 Client that does not appear as a computer in the UMC but can login to the domain. Now it is 2 external devices that cannot use the user database (be it Samba4 or LDAP). Maybe you can be a bit more specific with information. I suspect you have problems with Samba4 or the sync to it, thats the reason I asked for the reject list and a look in the listener.log and connectors4.log.

Hello,

Sorry to jump in but I think I have the same problem.
Our master dc was failing and we needed to do the backup2master to be sure.
The script worked perfectly and the backup became master.

Everything that was added to the domain before we did the backup2master works without problems.

Now when we add a computer (we only have W7), everything works perfectly on the windows side and we can see in the web console that the computer arrives (F5 like crazy) but is deleted immediately afterwards.
So I launched the univention-s4connector-list-rejected script and I have a lot of rejects (only the computers added after the backup2master).

I named the computer TESTSYNC
My connector log file reads:

code: sync from ucs: [windowscomputer] [ add] CN=TESTSYNC,CN=Computers,DC=ccthb,DC=local
28.12.2016 17:55:33,38 LDAP (PROCESS): Unable to sync CN=TESTSYNC,CN=Computers,DC=ccthb,DC=local (GUID: 7503bf7a-4425-46a7-800b-ce0b46b13fa9). The object is currently locked.
28.12.2016 17:55:33,160 LDAP (PROCESS): sync from ucs: [windowscomputer] [ delete] CN=TESTSYNC,CN=Computers,DC=ccthb,DC=local
28.12.2016 17:55:33,161 LDAP (PROCESS): Unable to sync CN=TESTSYNC,CN=Computers,DC=ccthb,DC=local (GUID: 7503bf7a-4425-46a7-800b-ce0b46b13fa9). The object is currently locked.
[/code]

and the listener log reads:

28.12.16 17:56:30.523 LISTENER ( PROCESS ) : samba4-idmap: added entry for S-1-4-2296 28.12.16 17:56:30.679 LISTENER ( PROCESS ) : updating 'cn=TESTSYNC$,cn=uid,cn=temporary,cn=univention,dc=ccthb,dc=local' command d 28.12.16 17:56:30.770 LISTENER ( PROCESS ) : updating 'cn=TESTSYNC,cn=Computers,dc=ccthb,dc=local' command m 28.12.16 17:56:30.773 LISTENER ( PROCESS ) : samba4-idmap: removing entry for S-1-4-2296 28.12.16 17:56:30.946 LISTENER ( PROCESS ) : updating 'cn=TESTSYNC,cn=Computers,dc=ccthb,dc=local' command m 28.12.16 17:56:30.996 LISTENER ( PROCESS ) : updating 'cn=TESTSYNC,cn=Computers,dc=ccthb,dc=local' command d

Something else I noticed but I’m not sure if it has something to do with it is that the _msdcs.ccthb.local record still points to the old dc.

If it can help somebody: I found that adding the computer account in the UCS console before joining the windows to the domain works without errors generated in the sync logs and are fully operational.

Additional Info:
UCS 4.1-4 errata 366
I already tried (on a clone of the machine):
sdb.univention.de/content/6/294/ … jects.html
sdb.univention.de/content/6/274/ … aster.html

Greetings,

Thank you very much,

Edward

Hello again,

Sorry for not waiting for an answer but I thought of something I should have mentioned.

I think it may be a problem with an update and here’s why and what I forgot to tell.

Our original setup (installed on 2016-12-15 on all 3 servers) was a DC master which I will be naming DC01, 2 backup servers I will name BKP01 and BKP02.

Those servers were all installed the same day and updated the same day so all versions were equal.

Last week (I think Tuesday 2016-12-20) we noticed hardware errors and decided to do the backup2master on BKP01 and discarded the old server DC01. Since that day we added more computers to the domain without any problems. We also didn’t update any of the servers but everything worked as it should. This week, we received the new server to replace the old DC01 and added it to the UCS domain as a backup server, let’s say NEWDC01. We did the install as backup, disconnected the new master (BKP01) and ran again the backup2master script on our newly received server (NEWDC01) and I checked the box to search for updates. After that we were no longer able to add computers to the domain the usual (see my first post) way.

The update applied to our original configuration was:

errata.software-univention.de/ucs/4.1/359.html

And the update applied to the last server (NEWDC01) was:

errata.software-univention.de/ucs/4.1/366.html

PS: In my previous post I mentioned that the _msdcs.ccthb.local record still pointed to the old dc but the re-provisioning (on my clone test machine) seemed to have resolved this. I don’t think that this is a problem because our computers were still able to join the domain without any problem from the windows side of view (in UCS there were the rejects).

PPS (sorry, I’m new to forums): Also when I did the re-provisioning, everything that was created before the backup2master synced without problems, everything after, the same reject errors in the s4-connector logs

Hope I’ve helped,
Greetings and thank you,

Edward

Hello,

Ok me again. Now I’m convinced this is update related.

This morning I added a Virtualbox Backup Master to the clients domain. After the installation was done, I didn’t update anything. (We’re on DVD Version 4.1-4 errata324).
I configured my virtualbox UCS Backup and my virtualbox W7 on internal network only so everything turned locally on my laptop without access to the clients network.

I again did the backup2master script on the virtualbox ucs backup so it became master.

Upon rebooting, I configured the W7 so that it had an ip and the only dns was my new virtual master, I changed the name of my vm W7 as to avoid hostnames I added without succeeding because apparently those hostnames still exist somewhere in the LDAP but I can’t find where or in some temporary location where the Domain changes are stored for sync (I don’t fully understand the workings of the connector).

I did a domain join on my vm W7 to my vm UCS master and it joined without problems, and the computer appeared (and stayed) in the console. I am testing now if I have full functionality (GPO’s because that’s how we found out that we had problems on the domain).

If it can be confirmed that it is indeed an update that caused the problems, I think it must be:

errata.software-univention.de/ucs/4.1/365.html

as it is the only one in our update range that talks about the connector. I couldn’t investigate further because I don’t have access to the bugs DB.

Hope to have helped and will post again when my vm W7 is fully tested just to be sure that the “downgrade from versions” didn’t cause any errors.

Greetings,

Thank you,

Edward

Ok, final post for the day because I have to continue my work here:

Tested the vm W7 and everything was applied. Things I verified:

  • group membership of user
  • application of gpo’s (only mapped drives did not work which is normal since I’m not in the network, but the gpresult showed it wanted to apply)

Which is all we really need here from the domain (security groups / users / group policies / DNS / authentication). Pretty much the real basics.

Greetings and have a nice day,

PS: If I see that someone asked me something I’ll try to take the time to answer.

Edward

I have the same problem on a new installation (after AD-takeover) the computer objects are only in samba4 but not in ldap and producing resync entries where the reason in the log says the objects are locked (applied all Updates up to errata 366 during installation)

Hello externa1,

You can do the following,

  1. Remove all added (problematic) computers from the domain without the network cable connected
  2. Rename them to a name not used before on the domain
  3. Login with ssh or local on the server and run univention-s4connector-list-rejected
  4. This will show you a list of things rejected by either ucs or s4
  5. According to which reject list the entries belong to, you run the according script in /usr/share/univention-s4-connector
    5.a. remove_s4_rejected.py for the ones on the s4 connected reject (the second part of the rejected list like this:
    ./remove_s4_rejected.py DC=AIXF05,DC=ccthb.local,CN=MicrosoftDNS,DC=DomainDnsZones,DC=ccthb,DC=local
    5.B. or ./remove_ucs_rejected.py cn=VASP03,cn=computers,dc=ccthb,dc=local
  6. Don’t worry if you have thousands of rejects, because there are a lot that are doubles and will be removed at the same time, I had 5000 and they were removed by running the scripts a total of 20 times
  7. I haven’t tested if you can use the same computer name again but for the moment I avoid it
  8. Add the computer name (not sure if case sensitive but I did it exactly the same) in the ucs webconsole before adding the computer to the domain from the windows side
  9. Bam, working computer and no rejects
  10. You can leave steps 3 to 6 for afterwards when all is running

If you look at my post of:
Thu 29. Dec 2016, 10:21 , you can repair the domain by doing backup2master on a machine that has no updates installed or wait for a patch.

I’m not doing it for the moment because we’re in the middle of a project and because it’s the Friday before new year’s eve, I’m not going to spend my weekend at the customers (however I have a non updated backup installed just to be on the safe side) and I don’t want to take the risk. In any case, you can install a new backup, disconnect all servers but the backup from the network and run the backup2master script, then you can test if everything works and then you have to make sure the other servers (ucs) and computers connect as it should to the new DC.

If however you see that it caused problems, you can disconnect the new master and reconnect the old with all the other ucs servers. Nothing gained, but nothing lost either.

PS: I did the steps 1 -> 10 yesterday and still have no rejects today.

Greetings,

Edward

Hello,

Last post of the year:

For externa1, we had several computers added to the domain before we found out that we had a problem. After the renaming of the computers and the cleaning, I tried to add in the UCS console the hostnames that we tried before. Some worked, others didn’t.

To find out if they will work, you can launch the command:

univention-ldap-search | grep yourcomputername

If you can find any entry that means you are not going to be able to add them manually. Don’t bother trying to find them in the web console in the ldap tree, I searched every OU and didn’t find anything, the only thing I found with the command was “memberuid myhostname” but it was enough to not being able to add the hostname and I’m not courageous enough to be fiddling with the ldap tree directly (clients production system so …). Or you go to the computers page in the console and try to add them, if you get an error, you’ll know enough.

Greetings and thanks for this great distribution, microsoft can suck it.

I’m out, happy new year everybody and best wishes,

Edward

Excuses I ended up accessing the forum in a hurry and I ended up responding incompletely because I had not finished all the tests yet.

Apparently the new version or samba (I heard that newer versions can cause similar problems) or some package in Univentiom 4.1-4 is generating a serious integration problem.

I did several tests with 4.1-4 and apparently Linux and Unix can integrate into the domain, but for some reason, even though they can log in using the kinit Administrator.DOMAIN.LOCAL, it can not pull the users to the local cache.

So much so that I ended up opening a bug as a bugzilla bug forge.univention.org/bugzilla/s … i?id=43253

I hope this problem is easy to resolve and you do not have to wait for the 4.1-5 update.

can you please send the output of the following command?

# for e in $(host -la $(dnsdomainname) | grep msdcs | grep -E '^[0-9a-z]{8}[-]?' | awk '{print $1}'); do host $e; done

Sorry for the delay, I spent all day solving problem and I could only look at the email now.

I made the addition of a Windows 10 and added FreeNAS again to the domain before executing the command and again Windows can pull the users, however FreeNAS does not.

When running the command:

root@dc01:~# for e in $(host -la $(dnsdomainname) | grep msdcs | grep -E '^[0-9a-z]{8}[-]?' | awk '{print $1}'); do host $e; done root@dc01:~#

As you can see, he did not return anything at all.

To prove what I said, they follow images from RSAT and the Univention management interface.


If you want the Samba logs, follow the logs taken yesterday when FreeNAS was added to the domain.

https://drive.google.com/file/d/0Bzo3LmoiOqu_QVRMbHgteEN1dUE/view?usp=sharing

Sincerely, Tácio Andrade.

[code]root@dc01:~# univention-s4connector-list-rejected

UCS rejected

1:   UCS DN: cn=freenas,cn=computers,dc=multiti,dc=local
      S4 DN: <not found>
     Filename: /var/lib/univention-connector/s4/1483415105.688959

2:   UCS DN: cn=freenas,cn=Computers,dc=multiti,dc=local
      S4 DN: <not found>
     Filename: /var/lib/univention-connector/s4/1483415106.698427

3:   UCS DN: cn=freenas,cn=computers,dc=multiti,dc=local
      S4 DN: <not found>
     Filename: /var/lib/univention-connector/s4/1483415113.021582

4:   UCS DN: cn=freenas,cn=computers,dc=multiti,dc=local
      S4 DN: <not found>
     Filename: /var/lib/univention-connector/s4/1483415113.056198

5:   UCS DN: cn=freenas,cn=computers,dc=multiti,dc=local
      S4 DN: <not found>
     Filename: /var/lib/univention-connector/s4/1483415113.069414

6:   UCS DN: cn=freenas,cn=Computers,dc=multiti,dc=local
      S4 DN: <not found>
     Filename: /var/lib/univention-connector/s4/1483415113.112985

7:   UCS DN: cn=freenas,cn=computers,dc=multiti,dc=local
      S4 DN: <not found>
     Filename: /var/lib/univention-connector/s4/1483415179.935657

849: UCS DN: cn=freenas,cn=computers,dc=multiti,dc=local
S4 DN:
Filename: /var/lib/univention-connector/s4/1483561517.046258

850: UCS DN: cn=freenas,cn=Computers,dc=multiti,dc=local
S4 DN:
Filename: /var/lib/univention-connector/s4/1483561517.068194

S4 rejected

1:    S4 DN: CN=MULTI01-TI01,CN=Computers,DC=multiti,DC=local
     UCS DN: <not found>
2:    S4 DN: CN=MULTI01-TI01,CN=Computers,DC=multiti,DC=local
     UCS DN: <not found>
3:    S4 DN: CN=freenas,CN=Computers,DC=multiti,DC=local
     UCS DN: <not found>

    last synced USN: 3966

root@dc01:~# for e in $(host -la $(dnsdomainname) | grep msdcs | grep -E ‘^[0-9a-z]{8}[-]?’ | awk ‘{print $1}’); do host $e; done
root@dc01:~#[/code]

It’s the same domain, I just changed the domain because it’s what I’m using with the client.

I suspect, we may be looking at two seperate problems and I would like to concentrate on the windows client join problem:

Can you set the loglevel of the connector higher:

# ucr set connector/debug/level='4'

Join a client and then send the connector.log (or the relevant parts with the windows client)?

I’m using debuglevel 12 now, do you want it to reduce to 4?

ucr set samba/debug/level=12

In case after this it recommends deleting FreeNAS in the domain and not connecting to VM? Whatever is best for generating the easiest log for you to work on.

I did not find the connector.log, but as a precaution I did the following:

1 - I removed Windows 10 and FreeNAS from the domain via RSAT;
2 - Removed Windows 10 from the domain by throwing it in a WORKGROUP;
3 - Restart Windows 10;
4 - I put Univention in Debug 4;
5 - Restart Univention;
6 - I added Windows 10 to the domain and restarted it;
7 - I was in the management interface of Univention and even with Windows 10 able to log in with the user DOMAIN Administrator, it did not appear between the computers;

So I’ve compacted the whole /var/log/samba directory and I’m making it available here.

drive.google.com/file/d/0Bzo3Lm … sp=sharing

Can you send the /var/log/univention/connectors4.log and the /var/log/univention/listener.log as well (ofc with the higher loglevel of the connector)?

Follow the connector-s4.log, connector-s4-status.log, and listener.log.

https://drive.google.com/file/d/0Bzo3LmoiOqu_NlJpbVh5Tnp2TVU/view?usp=sharing

Mastodon