[Samba] Samba 4 posixGroup mapping

[Gémes Géza]

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