Orphaned user in LDAP

UCS - Univention Corporate Server
, ,
#1

Hi guys,

I’m currently testing an UCS Memberserver (version 4.4-3 errata438) in an AD-Domain (SBS 2011). The UCS Memberserver holds the Kopano Core, WebApp etc.

It looks like almost all AD entries have been successfully replicated to LDAP. But one user account seems to have a problem. I wasn’t able to change the primary e-mail address at this user. That means I changed it on the Windows AD Server and the e-mail address was not replicate to LDAP. In LDAP still the old e-mail address is listed. In the connection.log I found the following:

05.02.2020 16:24:21.188 LDAP        (PROCESS): sync to ucs: Resync rejected dn: CN=Max Meier,OU=myOU,OU=Benutzer,DC=mydomain,DC=local
05.02.2020 16:24:21.198 LDAP        (PROCESS): sync to ucs:   [          user] [       add] uid=meier,ou=myOU,ou=benutzer,dc=mydomain,dc=local
05.02.2020 16:24:21.218 LDAP        (ERROR  ): Unknown Exception during sync_to_ucs
05.02.2020 16:24:21.218 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/univention/connector/__init__.py", line 1278, in sync_to_ucs
    result = self.add_in_ucs(property_type, object, module, position)
  File "/usr/lib/python2.7/dist-packages/univention/connector/__init__.py", line 1124, in add_in_ucs
    return bool(ucs_object.create())
  File "/usr/lib/python2.7/dist-packages/univention/admin/handlers/__init__.py", line 555, in create
    self._ldap_pre_ready()
  File "/usr/lib/python2.7/dist-packages/univention/admin/handlers/users/user.py", line 1648, in _ldap_pre_ready
    raise univention.admin.uexceptions.mailAddressUsed(self['mailPrimaryAddress'])
mailAddressUsed: meier@mydomain.de

"meier@mydomain.de" is the old address.

For testing purposes I deleted the user account in AD. Now the error is gone but the user account is still listed in LDAP.

Any ideas how to fix that and get rid of this orphaned user account in LDAP?

Thanks in advance

Ingo

#2

Log in to the UMC on your UCS server & delete the orphaned user there?

#3

Exactly that does not work. The delete button is greyed out. UCS is a member of an Active Directory domain.

#4

You can try deleting it from the command line with the udm tool. Judging from the output you posted I assume the user’s DN in the OpenLDAP is uid=meier,ou=myOU,ou=benutzer,dc=mydomain,dc=local Then simply run:

udm users/user remove --dn uid=meier,ou=myOU,ou=benutzer,dc=mydomain,dc=local
#5

I already tried that. The result is the following:

This operation is not allowed on this object: Objects from Active Directory can not be removed.

Do you know if there is an argument to force the removal? Or is there a user with elevated rights?

#6

I see. You can always try deleting directly via LDAP calls instead of going through the Python UDM modules:

ldapdelete -D cn=admin,$(ucr get ldap/base) -y /etc/ldap.secret cn=…
#7

Finally that did the trick :slight_smile:
I did the following:

ldapdelete -D "cn=admin,$(ucr get ldap/base)" -w "$(cat /etc/ldap.secret)" -h "$(ucr get ldap/master)" -p "$(ucr get ldap/master/port)" 'uid=meier,ou=myOU,ou=benutzer,dc=mydomain,dc=local'

Thank you very much for your assistance.

#8

A couple of points:

  1. It’s better to use -y /etc/ldap.secret instead of -w "$(cat /etc/ldap.secret)" as the latter will expose the admin password in the process table (e.g. the output of ps auxw). The former tells ldapdelete to read the password from a file whereas the latter tells the shell to read the password from a file and pass the password as a command line parameter. As ldapdelete is a short-lived process, this isn’t that bad, but in general it’s better never to use passwords on the command line (similar situation is e.g. dumping MySQL databases with mysqldump as that is a long-lived process).
  2. You don’t need -h "$(ucr get ldap/master)" -p "$(ucr get ldap/master/port)" as those are the defaults anyway (see /etc/ldap/ldap.conf).
Mastodon