2012-02-06 23:58 keltezéssel, steve írta: > On 02/06/2012 08:10 PM, Gémes Géza wrote: >> 2012-02-06 09:29 keltezéssel, steve írta: >>> On 02/06/2012 07:19 AM, Gémes Géza wrote: >>>> 2012-02-06 01:27 keltezéssel, steve írta: >>>>> Hi >>>>> I've created a Samba 4 group called suseusers and mixed in posixGroup >>>>> and gidNumber using samba-tool group add as a basis. >>>>> >>>>> It works, e.g. when I added an existing user to the group: >>>>> getent group suseusers >>>>> suseusers:*:2000: >>>>> and >>>>> getent passwd steve4 >>>>> steve4:x:3000019:2000:steve4:/home/CACTUS/steve4:/bin/bash >>>>> and >>>>> id >>>>> uid=3000019(steve4) gid=2000(suseusers) groups=2000(suseusers) >>>>> >>>>> but there seems to be something wrong with getent group. A local >>>>> group >>>>> gives this: >>>>> getent group users >>>>> users:x:100:machine >>>>> x not * >>>>> >>>>> This happens both on the Samba 4 machine and a client with his /home >>>>> directory on nfs4. The uid:gid mappings and permissions are >>>>> perfect at >>>>> both ends:) But what is the difference between the group info coming >>>>> from Samba 4 and the group info coming from /etc/group? I'm sure that >>>>> this is an error on my part, but I can't force it into failing no >>>>> matter what I throw at it. >>>>> Thanks, >>>>> Steve >>>>> >>>> For an answer we would need some configuration details, first of all >>>> nsswitch.conf, then depending on that maybe other files >>>> >>>> Regards >>>> >>>> Geza >>> Hi >>> >>> /etc/nsswitch.conf >>> passwd: files ldap >>> group: files ldap >>> shadow: files ldap >>> hosts: files mdns4_minimal [NOTFOUND=return] dns >>> networks: files dns >>> services: files >>> protocols: files >>> rpc: files >>> ethers: files >>> netmasks: files >>> >>> Ah, maybe this has something to do with it. For the user ldapmodify I >>> have: >>> >>> dn: cn=steve4,cn=Users,dc=hh3,dc=site >>> changetype: modify >>> add: objectclass >>> objectclass: posixaccount >>> - >>> add: objectclass >>> objectclass: shadowaccount >>> - >>> add: uidnumber >>> uidnumber: 3000021 >>> - >>> add: gidnumber >>> gidnumber: 2000 >>> - >>> add:unixhomedirectory >>> unixhomedirectory: /home/CACTUS/steve2 >>> - >>> add: loginshell >>> loginshell: /bin/bash >>> >>> and for the group I have: >>> >>> dn: cn=suseusers,cn=Users,dc=hh3,dc=site >>> changetype: modify >>> add: objectclass >>> objectclass: posixGroup >>> - >>> add: gidnumber >>> gidnumber: 2000 >>> >>> /etc/nslcd.conf: >>> uid nslcd-user >>> gid nslcd-user >>> uri ldap://192.168.1.3 >>> base dc=hh3,dc=site >>> map passwd uid sAMAccountName >>> map passwd homeDirectory unixHomeDirectory >>> map shadow uid sAMAccountName >>> #map passwd gidNumber gidNumber >>> sasl_mech GSSAPI >>> sasl_realm HH3.SITE >>> krb5_ccname /tmp/krb5cc_0 >>> >>> Then: >>> samba-tool group addmembers suseusers steve4 >>> >>> getent group suseusers >>> suseusers:*:2000: >>> Comes out with the * >>> >>> But steve4 comes out correctly, as a local user would: >>> getent passwd steve4 >>> steve4:x:3000019:2000:steve4:/home/CACTUS/steve4:/bin/bash >>> >>> The only difference I see is that steve4 has a shadowaccount object >>> which can't be mapped for the group (because it doesn't have one). Is >>> there anything else here? Any other files needed? >>> >>> In fact, I don't think I need shadowaccount mappings at all do I? >>> Isn't that where the unix passwords are stored? But that's probably >>> another thread. >>> >>> Thanks, >>> Steve >> I'm ot sure but maybe you should change how nslcd.conf maps group >> memberships (by default it looks at membership expecting stock >> posixaccount and posixgroup objectclasses, while AD uses member and >> memberoff which are close but not the same). >> You can safely ignore anything shadowaccont related, because you would >> be better authenticating via kerberos anyway. >> >> Regards >> >> Geza > Hi Geza, hi everyone > > This looks like good news. > > I asked the nslcd author directly: > <quote> > > My question is, how do I extract the gid from the ldap? I've tried: > map group gid gidnumber > > You shouldn't need to map the gidNumber attribute because nslcd already > uses that attribute by default. In any case if you're trying to find the > primary group of a user you should do: > > map passwd gidNumber XXX > > (where XXX is the attribute in your LDAP server) The passwd map is what > defines the output of getent passwd, the group map defines the > information on groups. > </quote> > > That seems true. The posixGroup I defined is mapped without me doing > anything in nslcd and > map passwd gidNumber gidNumber > would seem pointless as it's already got the gidNumber. > > You are right about the shadowaccount. This also solves the x and *. I > removed the objectclass shadowaccount from ldap and the map shadow uid > from nslcd and hey: > getent passwd steve4 > steve4:*:3000019:2000:steve4:/home/CACTUS/steve4:/bin/bash > > I interpret that as 'it's an x if there's a shadow entry, a * if there > isn't' > > This is getting to the stage where it's not worth waiting for a > working winbind. i.e. leave the windows side as it is and go with nfs4 > and rpc.idmapd for the the Linux side. > > How difficult do you think it would be to script the adding of the > user posix attributes after creating the s4 user? I envisage something > like: > samba-tool user add steve --posix --defaultgroup=somegroup > Also, a startup script for samba4 and nslcd which I think should just > be a 2 liner. > > Cheers, > Steve > Hi,
I use Samba3/OpenLDAP in production and create my users using similar scripts, so no it shouldn't be difficult, something like: #!/bin/sh samba-tool user add $1 .......... echo "dn: cn=$1,cn=Users,dc=hh3,dc=site changetype: modify add: objectclass objectclass: posixaccount - add: objectclass objectclass: shadowaccount - add: uidnumber uidnumber: $2 - add: gidnumber gidnumber: $3 - add:unixhomedirectory unixhomedirectory: $4 - add: loginshell loginshell: $5" >/some/temporary-file ldbmodify -f /some/temporary-file rm /some/temporary-file Please take into account that it is just a very rough example I've put up in less than a minute. Regards Geza -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba