We had horribly unintelligible tracebacks logs of AD-Connector rejects for Ticket#2024081521000203 , where AD-C "forgot" to rewrite the AD-LDAP-base to the UCS-LDAP-base and as a result one obtains a nested tracebacks from udm allocators.py and uldap.py. I still have them, if interesting, but the problem can be demonstrated from the CLI: root@primary20:~# ucr set directory/manager/cmd/debug/level='4' root@primary20:~# udm users/user create --position=dc=foo,dc=invalid --set username=test4 --set lastname=name4 --set password=univention 05.09.24 05:23:46.410 LDAP ( INFO ) : uldap.search filter=(&(objectClass=univentionUDMOption)(univentionUDMOptionModule=users/user)) base=cn=univention,dc=foo,dc=invalid,dc=ucs50domain,dc=net scope=sub attr=[] unique=0 required=0 timeout=-1 sizelimit=0 05.09.24 05:23:46.417 ADMIN ( WARN ) : No such object. I think, the UDM should detect earlier that the DN does not make any sense and it should definitely not simply append the UCS LDAP base to "force" the object into UCS LDAP.
I don't quite understand this problem fully. The bug is tagged to UCS 5.0, which behaves: # udm users/user create --position=dc=foo,dc=invalid --set username=test4 --set lastname=name4 --set password=univention No such object. In UCS 5.2: # udm users/user create --position=dc=foo,dc=invalid --set username=test4 --set lastname=name4 --set password=univention LDAP Error: Invalid DN syntax: invalid DN: cn=univention,. Yes, the traceback might help me to understand.