Error running univention-s4connector-list-rejected

UCS - Univention Corporate Server
#1

When running univention-s4connector-list-rejected on the UCS Master get this error:

Traceback (most recent call last):
File “/usr/sbin/univention-s4connector-list-rejected”, line 159, in
main()
File “/usr/sbin/univention-s4connector-list-rejected”, line 122, in main
False)
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/init.py”, line 728, in init
univention.s4connector.ucs.init(self, CONFIGBASENAME, property, baseConfig, listener_dir)
File “/usr/lib/pymodules/python2.7/univention/s4connector/init.py”, line 436, in init
self.open_ucs()
File “/usr/lib/pymodules/python2.7/univention/s4connector/init.py”, line 469, in open_ucs
self.lo=univention.admin.uldap.access(host=host, port=port, base=self.baseConfig[‘ldap/base’], binddn=binddn, bindpw=bindpw, start_tls=2, follow_referral=True)
File “/usr/lib/pymodules/python2.7/univention/admin/uldap.py”, line 267, in init
raise univention.admin.uexceptions.authFail, _( “Authentication failed” )
univention.admin.uexceptions.authFail: Authentication failed

Also doing univention-ldapsearch -s base -h $(ucr get hostname).$(ucr get domainname)

I now get:

ldap_bind: Invalid credentials (49)
additional info: Simple Bind Failed: NT_STATUS_LOGON_FAILURE

Both worked before adding the UCS Backup Domain.

Everything thing else seem to be working/replicating OK.

#2

Does running “univention-ldapsearch” without further arguments work? Does the file /etc/machine.secret exist, and does it contain something that looks like a password?

Can you please take a look at the log file /var/log/univention/server_password_change.log on the master and look for irregularities?

#3

univention-ldapsearch does work.

/var/log/univention/server_password_change.log is filled with occuring every few seconds.
No server password change scheduled for today, terminating without a change.

/etc/machine.secret I have two with the same date…one is marked OLD.
-rw------- 1 root root 20 Oct 11 01:03 machine.secret
-rw------- 1 root root 99 Oct 11 01:03 machine.secret.old

Both have a hash in them, however machine.secret only has 1 hash, and machine.secret.old has 3 in it.

Since this server appears to be degrading daily, we are moving things around.

We are in the process of migrating data to another server, just in case, this results in us rebuilding the master/backup/slaves UCS DCs.

It has also appears that DNS has stopped resolving outside of the server. If I do nslookup the host name (bebucsmdc1) it fails from a workstation to the server. However if I nslookup from the server (bebw10wkt1)to the workstation it works. Both have the Master and Backup UCS as their DNS (primary and secondary respectively.)

We are in the process of migrating to another DNS server, just in case.

Users are still able to log into their windows/linux workstations both authenticate against the UCS. Users are still getting their emails which runs off the Backup DC.

We plan to move users emails to another server as well as soon as data migration is done, again just in case.

#4

Great, this means that /etc/machine.secret is still valid.

If you call univention-ldapsearch without parameters then it uses the server’s machine account for authentication against the OpenLDAP directory (bind DN “ucr get ldap/hostdn” and the password from /etc/machine.secret). The reason your “univention-ldapsearch” didn’t work is that you told it to search the AD’s LDAP directory (the default port, 389, is used by Samba 4’s AD LDAP directory, and the OpenLDAP directory is listening on the non-standard port 7389). The naming scheme inside the Samba 4 AD LDAP directory is different from the OpenLDAP one, therefore the machine account’s DN used to make the bind doesn’t work.

That’s quite normal as the server password change script is started regularly via cron. Anyway, the machine.secret is working just fine, and there’s no problem with the password change. So let’s abandon this line in inquiry.

[quote]Since this server appears to be degrading daily, we are moving things around.

We are in the process of migrating data to another server, just in case, this results in us rebuilding the master/backup/slaves UCS DCs.[/quote]

If you’re already reinstalling then there’s not much use in debugging this issue further, don’t you agree?

Does resolving the server’s fully qualified domain name from the workstation work? Meaning does this work: “nslookup bebucsmdc1.your.domain ip.of.your.ucs-master”? If so it may be an issue with the DNS configuration on your workstation (either the domain suffix is wrong or the name server’s IP address is).

If your UCS backup DC is working fine and you don’t want to re-install the whole domain you can promote the backup DC to a master DC. That’s what a backup DC is there for (it’s its solve reason for existence, in fact). However, this is a one-way street; you cannot demote it again, and you must decommission your old master DC. See the admin documentation for details.

#5

We are not reinstalling yet (we are just moving our data off in case it blows up completely or we do resort to rebuilding the UCS Domain.) As we are thinking our Master UCS is in a last of it’s deathrows, as email which was working on it has started failing this morning. We think it is a matter of time before Samba4 starts to go an we lose access to our data and Windows access.

Also…
Looking up resolving the server’s fully qualified domain name from the workstation - This does work.
However resolving the server’s fully qualified domain name from the UCS Master server itself FAILS with NO host name found. (It has itself as Primary DNS and the Backup DC Secondary DNS, the Slave DC is 3rd DNS.)

Doing reverse look-ups work just fine for both of the above (So this now REALLY confused ME! LOL ) Reverse DNS on the Slave also work for both the workstation and the Master, however forward lookup fail for everything (again it has Master DC as Primary DNS, Itself as Secondary, Backup DC as 3rd DNS.)

If your UCS backup DC is working fine and you don’t want to re-install the whole domain you can promote the backup DC to a master DC. - Well the only thing that works is LDAP/DNS. This Backup DC (at a co-location site) does not have Samba4 installed. We installed Samba4 on the Master (at headquarters) and a Slave DC (in a remote office) only. We left the Backup DC alone with no mail server and no Samba4.

It seems to us a lot of the problem land on servers that have Samba4 on them. So…

I think we are going to abandon UCS for the moment as this is the second time it blew up on us with Samab4 being involved. We’ll spin up 2 Windows AD VPS Servers, swing our Windows workstations/application servers to those true ADs for DNS/authentication, then take another look into UCS for just our Linux/Unix based workstations & servers for the DNS and authentication. And just sync the two (4 servers actually…one primary and secondary of each true AD and UCS Master/Backup.) I don’t think UCS Samba4 is ready for windows prime time in our environment yet.

Mastodon