Univention Bugzilla – Bug 34428
Samba3 to Samba4 migration creates 'Authenticated Users' in AD
Last modified: 2020-07-03 20:53:25 CEST
Ticket#: 2014032721004296 In older UCS installations, a "Authenticated Users" group with sambaGroupType=2 may exist and is provisioned to AD. # univention-ldapsearch -xLLL cn=Authenticated\ Users dn: cn=Authenticated Users,cn=groups,dc=x-y,dc=local sambaGroupType: 2 cn: Authenticated Users objectClass: top objectClass: posixGroup objectClass: univentionGroup objectClass: sambaGroupMapping objectClass: univentionObject univentionObjectType: groups/group gidNumber: 5191 sambaSID: S-1-5-11 uniqueMember: cn=DC Slave Hosts,cn=groups,dc=x-y,dc=local uniqueMember: cn=Windows Hosts,cn=groups,dc=x-y,dc=local # univention-s4search cn=Authenticated\ Users # record 1 dn: CN=Authenticated Users,CN=Groups,DC=x-y,DC=local objectClass: top objectClass: group cn: Authenticated Users instanceType: 4 whenCreated: 20140328105144.0Z whenChanged: 20140328105144.0Z uSNCreated: 4435 uSNChanged: 4435 name: Authenticated Users objectGUID: 44c84061-83e2-46d0-9417-a5fff651b79f objectSid: S-1-5-11 sAMAccountName: Authenticated Users sAMAccountType: 268435456 groupType: -2147483646 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=x-y,DC=local distinguishedName: CN=Authenticated Users,CN=Groups,DC=x-y,DC=local The join of further S4 systems fails in this case: --- workgroup is x-y realm is x-y.local checking sAMAccountName removing samaccount: CN=y-ucs2,OU=Domain Controllers,DC=x-y,DC=local Deleted CN=y-ucs2,OU=Domain Controllers,DC=x-y,DC=local Adding CN=y-UCS2,OU=Domain Controllers,DC=x-y,DC=local Adding CN=y-UCS2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=x-y,DC=local Adding CN=NTDS Settings,CN=y-UCS2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=x-y,DC=local Adding SPNs to CN=y-UCS2,OU=Domain Controllers,DC=x-y,DC=local Setting account password for y-UCS2$ Enabling account Calling bare provision No IPv6 address will be assigned WARNING: No path in service IPC$ - making it unavailable! NOTE: Service IPC$ is flagged unavailable. Provision OK for domain DN DC=x-y,DC=local Starting replication Schema-DN[CN=Schema,CN=Configuration,DC=x-y,DC=local] objects[402/1550] linked_values[0/0] Schema-DN[CN=Schema,CN=Configuration,DC=x-y,DC=local] objects[804/1550] linked_values[0/0] Schema-DN[CN=Schema,CN=Configuration,DC=x-y,DC=local] objects[1206/1550] linked_values[0/0] Schema-DN[CN=Schema,CN=Configuration,DC=x-y,DC=local] objects[1550/1550] linked_values[0/0] Analyze and apply schema objects Partition[CN=Configuration,DC=x-y,DC=local] objects[402/1644] linked_values[0/0] Partition[CN=Configuration,DC=x-y,DC=local] objects[804/1644] linked_values[0/0] Partition[CN=Configuration,DC=x-y,DC=local] objects[1206/1644] linked_values[0/0] Partition[CN=Configuration,DC=x-y,DC=local] objects[1608/1644] linked_values[0/0] Partition[CN=Configuration,DC=x-y,DC=local] objects[1644/1644] linked_values[28/0] Replicating critical objects from the base DN of the domain Partition[DC=x-y,DC=local] objects[98/98] linked_values[47/0] Partition[DC=x-y,DC=local] objects[500/1432] linked_values[0/0] Failed to apply records: ../ldb_tdb/ldb_index.c:1216: Failed to re-index objectGUID in CN=Authenticated Users\0ACNF:44c84061-83e2-46d0-9417-a5fff651b79f,CN=Groups,DC=x-y,DC=local - ../ldb_tdb/ldb_index.c:1148: unique index violation on objectGUID in CN=Authenticated Users\0ACNF:44c84061-83e2-46d0-9417-a5fff651b79f,CN=Groups,DC=x-y,DC=local: Entry already exists Failed to commit objects: WERR_GENERAL_FAILURE Join failed - cleaning up checking sAMAccountName removing samaccount: CN=y-UCS2,OU=Domain Controllers,DC=x-y,DC=local Deleted CN=y-UCS2,OU=Domain Controllers,DC=x-y,DC=local Deleted CN=NTDS Settings,CN=y-UCS2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=x-y,DC=local Deleted CN=y-UCS2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=x-y,DC=local ERROR(<type 'exceptions.TypeError'>): uncaught exception - Failed to process chunk: NT_STATUS_UNSUCCESSFUL File "/usr/lib/python2.6/dist-packages/samba/netcmd/__init__.py", line 175, in _run return self.run(*args, **kwargs) File "/usr/lib/python2.6/dist-packages/samba/netcmd/domain.py", line 560, in run machinepass=machinepass, use_ntvfs=use_ntvfs, dns_backend=dns_backend) File "/usr/lib/python2.6/dist-packages/samba/join.py", line 1220, in join_DC ctx.do_join() File "/usr/lib/python2.6/dist-packages/samba/join.py", line 1102, in do_join ctx.join_replicate() File "/usr/lib/python2.6/dist-packages/samba/join.py", line 842, in join_replicate replica_flags=ctx.domain_replica_flags) File "/usr/lib/python2.6/dist-packages/samba/drs_utils.py", line 256, in replicate schema=schema, req_level=req_level, req=req) ---
Workaround in this case (as the additional group can't be deleted via /var/lib/samba/private/sam.ldb): # /etc/init.d/samba4 stop # ldbdel -H /var/lib/samba/private/sam.ldb.d/DC%3DX-Y,DC%3DLOCAL.ldb \ "CN=Authenticated Users,CN=Groups,DC=x-y,DC=local" # /etc/init.d/samba4 start
occured in another older installation. the described workaround helps but it would be nice to get informations if this group can be removed from LDAP too.
Is it nessesary having this group in LDAP with samba3? Or could it be removed?
Background Info: Q: What's this group? A: The group "Authenticated Users" is one of the "well known" pseudo groups of Active Directory. Q: Ok, why have it in UDM/OpenLDAP then? A: To have a domain wide valid Posix GID (Bug 29000). Q: Ok, then I don't need it in Samba3/NT-only domains? A: Not necessarily. Depends on the details of the environement. In case of a migration to Samba4 the group is created anyway (with sambaGroupType 5 and it doesn't need to be synchronized between UDM and S4 (see e.g. Bug 32461 Comment 2)
Reported 2015022421000152
Also 2015032721000261
Created attachment 6968 [details] fix_authenticated_users_after_s3tos4migration.sh The attached script may fix the issue when run on the master after the migration. It removes the conflicting object from Samba4. Untested. The correct fix would probably be to patch samba classicupdate to not migrate objects with conflicting objectSids.
Actually it is strange that this still happens even though Bug 33338#c11 claims to have fixed classicupgrade.
We had one interesting variation of case with Samba 4.3.7 where univention-s4search objectSid=S-1-5-11 would not find the group. Only looking it up by name found it.
Created attachment 7823 [details] fix_authenticated_users_after_s3tos4migration.sh An adjusted version of the script above.
This is still happening. If the problem is found, the workaround works.
This issue has been filed against UCS 4.2. UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.