Diskrepanz in der Gruppenmitgliegschaft zw. LDAP und Samba 4

Beim Ausprobieren des memberOf Attributes im Samba 4 fiel mir auf, dass die Gruppenmitgliedschaften zwischen LDAP und Samba 4 nicht übereinstimmen. Kurz: Gruppen im Samba 4 haben (wenn überhaupt) als einziges Mitglied den Administrator. Unten ist die Ausgabe von ldapsearch sowohl gegen das OpenLDAP als auch Samba4. Ich habe die Domain Users Gruppe genommen, aber es betrifft auch eigene Gruppen.

Soll das so? Habe ich irgendwo eine Einstellung übersehen damit in der UMC angelegte Gruppen auch für Samba 4 übernommen werden?

root@vp-s01:~# ldapsearch -xLLL -D cn=Administrator,cn=users,dc=doa,dc=example,dc=net -W -b dc=doa,dc=example,dc=net -h 127.0.0.1 cn="Domain Users"
Enter LDAP Password: 
dn: CN=Domain Users,CN=Groups,DC=doa,DC=example,DC=net
objectClass: top
objectClass: group
cn: Domain Users
instanceType: 4
whenCreated: 20120815122631.0Z
uSNCreated: 3542
name: Domain Users
objectGUID:: zeUYVR5ANkqbwdESTiAGKA==
objectSid:: AQUAAAAAAAUVAAAAq+BNwzWpWnSe0zMoAQIAAA==
sAMAccountName: Domain Users
sAMAccountType: 268435456
groupType: -2147483646
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=doa,DC=example,DC=net
isCriticalSystemObject: TRUE
memberOf: CN=Users,CN=Builtin,DC=doa,DC=example,DC=net
member: CN=Administrator,CN=Users,DC=doa,DC=example,DC=net
whenChanged: 20121018082444.0Z
uSNChanged: 7504
distinguishedName: CN=Domain Users,CN=Groups,DC=doa,DC=example,DC=net

# refldap://doa.example.net/CN=Configuration,DC=doa,DC=example,DC=net

root@vp-s01:~# ldapsearch -xLLL -D uid=Administrator,cn=users,dc=doa,dc=example,dc=net -W -b dc=doa,dc=example,dc=net -h 127.0.0.1:7389 cn="Domain Users"
Enter LDAP Password: 
dn: cn=Domain Users,cn=groups,dc=doa,dc=example,dc=net
objectClass: top
objectClass: posixGroup
objectClass: univentionGroup
objectClass: sambaGroupMapping
objectClass: univentionObject
univentionObjectType: groups/group
cn: Domain Users
sambaSID: S-1-5-21-3276660907-1952098613-674485150-513
sambaGroupType: 2
gidNumber: 5001
memberUid: Administrator
memberUid: krbtgt
memberUid: dns-vp-s01
memberUid: mss042
[...]
uniqueMember: uid=Administrator,cn=users,dc=doa,dc=example,dc=net
uniqueMember: uid=krbtgt,cn=users,dc=doa,dc=example,dc=net
uniqueMember: uid=dns-vp-s01,cn=users,dc=doa,dc=example,dc=net
uniqueMember: uid=mss042,cn=staff,cn=users,dc=doa,dc=example,dc=net
[...]

root@vp-s01:~# ldapsearch -xLLL -D cn=Administrator,cn=users,dc=doa,dc=example,dc=net -W -b dc=doa,dc=example,dc=net -h 127.0.0.1 cn=mss042
Enter LDAP Password: 
dn: CN=mss042,CN=staff,CN=Users,DC=doa,DC=example,DC=net
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: mss042
sn: Stretz
givenName: Malte
instanceType: 4
whenCreated: 20120918200354.0Z
uSNCreated: 3983
name: mss042
objectGUID:: Z9h3aaRPlUanomYQCyFRjw==
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAq+BNwzWpWnSe0zMocwQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: mss042
sAMAccountType: 805306368
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=doa,DC=example,DC=net
userAccountControl: 512
displayName: Malte Stretz
userPrincipalName: mss042@DOA.EXAMPLE.NET
pwdLastSet: 130047134040000000
whenChanged: 20130207122328.0Z
uSNChanged: 11253
distinguishedName: CN=mss042,CN=staff,CN=Users,DC=doa,DC=example,DC=net

# refldap://doa.example.net/CN=Configuration,DC=doa,DC=example,DC=net

root@vp-s01:~# ldapsearch -xLLL -D uid=Administrator,cn=users,dc=doa,dc=example,dc=net -W -b dc=doa,dc=example,dc=net -h 127.0.0.1:7389 uid=mss042
Enter LDAP Password: 
dn: uid=mss042,cn=staff,cn=users,dc=doa,dc=example,dc=net
uid: mss042
krb5PrincipalName: mss042@DOA.EXAMPLE.NET
objectClass: top
objectClass: person
objectClass: univentionPWHistory
objectClass: posixAccount
objectClass: shadowAccount
objectClass: univentionMail
objectClass: sambaSamAccount
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: krb5Principal
objectClass: krb5KDCEntry
objectClass: univentionObject
uidNumber: 2034
sambaAcctFlags: [U          ]
krb5MaxLife: 86400
cn: Malte Stretz
krb5MaxRenew: 604800
loginShell: /bin/bash
univentionObjectType: users/user
displayName: Malte Stretz
gecos: Malte Stretz
sn: Stretz
homeDirectory: /home/mss042
givenName: Malte
gidNumber: 5001
sambaPrimaryGroupSID: S-1-5-21-3276660907-1952098613-674485150-513
sambaSID: S-1-5-21-3276660907-1952098613-674485150-1139
[...]

Hallo,

aktuell kann ich das beschriebene Verhalten nicht nachvollziehen:

[code]root@master:~# univention-s4search cn=testgroup member

record 1

dn: CN=testgroup,CN=Groups,DC=testing,DC=tim
member: CN=testuser,CN=Users,DC=testing,DC=tim[/code]

[code]root@master:~# univention-ldapsearch cn=testgroup memberUid

extended LDIF

LDAPv3

base <dc=testing,dc=tim> (default) with scope subtree

filter: cn=testgroup

requesting: memberUid

testgroup, groups, testing.tim

dn: cn=testgroup,cn=groups,dc=testing,dc=tim
memberUid: testuser[/code]

[code]root@master:~# univention-s4search cn=testuser memberOf

record 1

dn: CN=testuser,CN=Users,DC=testing,DC=tim
memberOf: CN=testgroup,CN=Groups,DC=testing,DC=tim[/code]

Welche Version von UCS setzen Sie ein?
Können Sie das Verhalten tatsächlich generell beobachten?
Wird die Gruppenzugehörigkeit generell korrekt aufgelöst?

root@master:~# getent group testgroup testgroup:*:5036:testuser

Mit freundlichen Grüßen,
Tim Petersen

[ul]
[li] Dies ist UCS 3.1 (aktuellstes Errata) aktualisiert von UCS 3.0[/li]
[li] Es scheint generell aufzutreten[/li]
[li] Die Gruppenzugehörigkeit wird prinzipiell richtig aufgelöst[/li][/ul]

Es scheint auch in 3.1 angelegte User zu betreffen, das muss ich noch mal prüfen. Interessanter ist vielleicht dass univention-s4search mir einen SPNEGO-Fehler an den Kopf schmeißt:

root@vp-s01:~# kinit Administrator
Administrator@DOA.EXAMPLE.NET's Password: 
root@vp-s01:~# klist
Credentials cache: FILE:/tmp/krb5cc_0
        Principal: Administrator@DOA.EXAMPLE.NET

  Issued                Expires               Principal
Feb 21 15:50:13 2013  Feb 22 01:50:13 2013  krbtgt/DOA.EXAMPLE.NET@DOA.EXAMPLE.NET
root@vp-s01:~# univention-s4search cn="Domain Users" member
SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_NO_LOGON_SERVERS
# record 1
dn: CN=Domain Users,CN=Groups,DC=doa,DC=example,DC=net
member: CN=Administrator,CN=Users,DC=doa,DC=example,DC=net

# Referral
ref: ldap://doa.example.net/CN=Configuration,DC=doa,DC=example,DC=net

# returned 2 records
# 1 entries
# 1 referrals
root@vp-s01:~# univention-ldapsearch cn="Domain Users" memberUid
# extended LDIF
#
# LDAPv3
# base <dc=doa,dc=example,dc=net> (default) with scope subtree
# filter: cn=Domain Users
# requesting: memberUid 
#

# Domain Users, groups, doa.example.net
dn: cn=Domain Users,cn=groups,dc=doa,dc=example,dc=net
memberUid: Administrator
memberUid: krbtgt
memberUid: dns-vp-s01
memberUid: example
memberUid: mss042
memberUid: jla001
memberUid: hjp002
memberUid: amy003
memberUid: ham004
memberUid: mst005
memberUid: bgs006
memberUid: jjm007
memberUid: edd008
memberUid: ava009
memberUid: avo010
memberUid: jth011
memberUid: hbo012
memberUid: sde013
memberUid: ebu014
memberUid: tma015
memberUid: hmi016
memberUid: asa017
memberUid: fte018
memberUid: ssa019
memberUid: vka021
memberUid: cag022
memberUid: rba023
memberUid: hbr024
memberUid: wbr025
memberUid: ebr026
memberUid: cco027
memberUid: khf028
memberUid: bha029
memberUid: gha030
memberUid: kph031
memberUid: hho032
memberUid: mka033
memberUid: bme034
memberUid: sts035
memberUid: bsp036
memberUid: hte037
memberUid: tuh038
memberUid: jwo039
memberUid: rka040
memberUid: dgu041
memberUid: mow043
memberUid: kry044
memberUid: ldap-vp-r01

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1
root@vp-s01:~# univention-s4search cn=mss042 memberOf
SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_NO_LOGON_SERVERS
# record 1
dn: CN=mss042,CN=staff,CN=Users,DC=doa,DC=example,DC=net

# Referral
ref: ldap://doa.example.net/CN=Configuration,DC=doa,DC=example,DC=net

# returned 2 records
# 1 entries
# 1 referrals
root@vp-s01:~# getent group "Domain Users"
Domain Users:*:5001:bgs006,hmi016,tuh038,mst005,vka021,rka040,fte018,ava009,sts035,asa017,jwo039,ebu014,mow043,ssa019,cco027,Administrator,bme034,bsp036,hbo012,ebr026,amy003,hjp002,gha030,tma015,kry044,mka033,rba023,cag022,wbr025,dgu041,hbr024,krbtgt,hte037,ham004,edd008,jjm007,sde013,jla001,jth011,avo010,kph031,hho032,khf028,dns-vp-s01,ldap-vp-r01,example,bha029,mss042

Hallo,

das ist unproblematisch, sehen Sie hierzu gern auch Bug #28819.

Mit freundlichen Grüßen,
Tim Petersen

Ich hatte nach letztem Test vermutet dass es evtl. daran liegen könnte dass aufgrund der SPNEGO-Fehler nur der aktuell angemeldete User angezeigt wird. Dies ist aber auch nicht der Fall:

root@vp-s01:~# ldapsearch -xLLL -D cn=mss042,cn=staff,cn=users,dc=doa,dc=example,dc=net -W -b dc=doa,dc=example,dc=net -h 127.0.0.1:389 cn="Domain Users" member
Enter LDAP Password: 
dn: CN=Domain Users,CN=Groups,DC=doa,DC=example,DC=net
member: CN=Administrator,CN=Users,DC=doa,DC=example,DC=net

# refldap://doa.example.net/CN=Configuration,DC=doa,DC=example,DC=net

In Der Gruppe Domain Users ist auf jeden Fall mindestens ein User der unter UCS 3.1 angelegt wurde.

Das Ganze ist 100%ig reproduzierbar. Ich habe gerade einen User direkt innerhalb des Users containers (nicht im Untercontainer staff) angelegt um das zu testen und dieser wurde ebenfalls nicht in die Samba4 Domain Users Gruppe aufgenommen.

Ich habe mal den relevanten Teil des connector-s4.log als upload_dpXQJi.asc hochgeladen falls Interesse besteht :slight_smile:

Um das Ganze interessanter zu gestalten zwei weitere Punkte:

[ul]
[li] Es scheint nur die primäre Gruppe eines Users zu betreffen. Ich habe dies mit einer anderen Gruppe als Domain Users getestet und kann es da reproduzieren. Zusätzliche Gruppen scheinen richtig in den member/memberOf Attributen abgebildet zu werden.[/li]
[li] Ich habe heute zum Netz einen Windows Server 2003 als Terminal Server hinzugefügt und dort die Anmeldeberechtigungen für Domain Users vergeben. Und es funktioniert. Windows scheint also zu funktionieren. net user $username /domain gibt auch die richtigen Gruppenmitgleidschaften aus.[/li][/ul]

Hallo,

[quote=“mss”]Es scheint nur die primäre Gruppe eines Users zu betreffen. Ich habe dies mit einer anderen Gruppe als Domain Users getestet und kann es da reproduzieren. Zusätzliche Gruppen scheinen richtig in den member/memberOf Attributen abgebildet zu werden.[/quote] im AD-Umfeld ist das normal. Die Mitgliedschaft in der primären Gruppe wird nicht über das member/memberOf Attribut an der Gruppe abgebildet sondern ledgidlich über das PrimaryGroupID Attribut des Benutzers (support.microsoft.com/kb/275523/en-us).

Mit freundlichen Grüßen
Janis Meybohm

Mastodon