UCS-4.4 Windows machine account password change broken (fixed)

UCS - Univention Corporate Server
, ,
#1

Symptoms: Since upgrade to UCS-4.4 all of our windows client systems started to fail to connect to our WPA2-Enterprise Wifi (freeradius->PEAP,MSCHAPv2,ntlm) one by one, because NTLM authentication (with machine credentials) fails.

NTLM authentication works fine with passwords set before 4.4 upgrade or when the machine account’s password is set in UCM manually. But clients will change their passwords eventually.

Steps to reproduce:

  1. have a UCS-4.3 Domain configured, machine$ joined, a WPA2-Enterprise network which relays authentication to UCS-Master freeradius (and machine$ account is allowed network acces)

  2. extract Windows local machine$ account password (i.e. by Get-TSLSASecret.ps1)

  3. validate this password by challenge/response authentication on UCS-Master console: wbinfo --ntlmv2 -a machine$

  4. connect to WiFi using this “host/machine.domain” credentials, this is expected to succeed

  5. upgrade to ucs-4.4

  6. validate step 3 again

  7. try to connect to WiFi again, this is expected to succed

  8. tell Windows machine to change it’s password (i.e. by using powershell Reset-ComputerMachinePassword as domain admin) to simulate 30 day password rollover

  9. try to connect to wifi again, which should fail now

  10. extract machine$ password again (step 2)

  11. validate step 3 again

  12. use ucm to set machine$ account password to the extracted password

  13. try to connect to WiFi again, which should succeed now

  14. reset machine$ trust password by using Reset-ComputerMachinePassword -Credential ldomain\domainadmin succeeds but breaks freeradius-ntlm again

  15. try to connect to wifi again, which should fail again

  16. fix this by repeating steps 2, 3 and 12

So, somehow changing machnine$ password from within windows tool stack breaks freeradius-ntlm (maybe a s4-sync problem?)

(Edit) Probably:
Found this in /var/log/univention/connector-s4.log when a machine changes it’s password

20.06.2019 13:40:43.508 LDAP (ERROR ): get_ucs_object: could not identify UDM object type: cn=lat06,ou=yyy,ou=lab-computer,xxxx,dc=de
20.06.2019 13:40:43.508 LDAP (PROCESS): get_ucs_object: using default: users/user
20.06.2019 13:40:43.509 LDAP (WARNING): get_ucs_object: failure was:

20.06.2019 13:40:43.510 LDAP (WARNING): Traceback (most recent call last):
File “/usr/lib/python2.7/dist-packages/univention/s4connector/init.py”, line 999, in get_ucs_object
ucs_object = univention.admin.objects.get(module, co=None, lo=self.lo, position=’’, dn=searchdn)
File “/usr/lib/pymodules/python2.7/univention/admin/objects.py”, line 113, in get
return module.object(co, lo, position, dn, superordinate=superordinate, attributes=attributes)
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/users/user.py”, line 1243, in init
univention.admin.handlers.simpleLdap.init(self, co, lo, position, dn, superordinate, attributes=attributes)
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/init.py”, line 232, in init
raise univention.admin.uexceptions.wrongObjectType(’%s is not recognized as %s.’ % (self.dn, self.module))
wrongObjectType: cn=lat06,ou=yyyy,ou=lab-computer,dc=xxx,dc=de is not recognized as users/user.

20.06.2019 13:40:43.510 LDAP (ERROR ): password_sync_s4_to_ucs: couldn’t get user-object from UCS

Edit 2
Found a related Bugzilla antry
https://forge.univention.org/bugzilla/show_bug.cgi?id=49649
and fixed in
http://errata.software-univention.de/ucs/4.4/155.html

Mastodon