[Samba] LDAP proxy auth [SOLVED]

Lars Hanke debian at lhanke.de
Sat Oct 25 16:37:05 MDT 2014

Am 26.10.2014 00:02, schrieb Harry Jede:
> On 23:14:49 wrote Lars Hanke:
>> Am 25.10.2014 22:23, schrieb steve:
>>> On 25/10/14 21:33, Lars Hanke wrote:
>>>> During my test phase I used to manage POSIX attributes in my AD
>>>> using ldap-tools with -Y GSSAPI after kinit Administrator. Now
>>>> this became impossible unless I logged in as Administrator, since
>>>> the principal is tied to the user account - be it only for NFS4.
>>>> ;) Administrator so far is not even a POSIX user.
>>>> My first idea was to join my POSIX user to some group, which is
>>>> allowed to modify user data. Does samba4 recognize this? And
>>>> which group would be the correct one?
>>>> Alternatively, is there a way to simple bind with Administrator
>>>> access rights?
>>>> Thanks for your help,
>>>> - lars.
>>> Hi Lars
>>> Kerberos expects the root cache under /tmp. I've asked before if
>>> you are using systemd, which puts the cache under /run/user/0. Of
>>> course /run/user/0 does not exist unless root has logged in and so
>>> root cannot obtain a ticket unless he is logged in already. The
>>> only way is to
>>> workaround [1]:
>> No, I'm not using systemd and my users' keytabs are in /tmp.
>> Searching harder I found a solution for the alternative in my own
>> notes:
>> ldapmodify -H ldap://samba.example.com -D
>> "cn=Administrator,cn=Users,dc=example,dc=com" -W -x -ZZ <
>> changeIt.ldif
>> Works as I wanted it. I probably leave it like this. My original idea
>> was making:
>> ldapmodify -H ldap://samba.example.com -Y GSSAPI < changeIt.ldif
>> work. This would require me, i.e. my user account, to be allowed to
>> do the changes, as Administrator does. I added my account to "Domain
>> Admins", but I still get:
>> ldap_modify: Insufficient access (50)
>> Should I consider another group, or is Administrator simply special
>> in its own right, e.g. by LDAP ACL?
> No, just do it right ;-)
> su - user1
> user1 at dc0:~$ kinit
> user1 at AD.SCHULE.LAN's Password:
> user1 at dc0:~$ id user1
> uid=20000(user1) gid=100(users) Gruppen=100(users),3000008(Domain
> Admins),50000(glob-1),3000000(Administrators)
> user1 at dc0:~$ ldapsearch -LLL -H ldap://dc0 -b DC=ad,DC=schule,DC=lan
> '(cn=administrator)' objectsid uid uidnumber|egrep -v '^#|^$'
> SASL/GSSAPI authentication started
> SASL username: user1 at AD.SCHULE.LAN
> SASL SSF: 56
> SASL data security layer installed.
> dn: CN=Administrator,CN=Users,DC=ad,DC=schule,DC=lan
> objectSid:: AQUAAAAAAAUVAAAAF8hslq59BwYdoGtT9AEAAA==
> uidNumber: 0
> uid: Administrator
> As you see, on my dc, the user1 is in "Domain Admins" AND in
>   Administrators. This is because I use nslcd as NSS Provider.
> user1 at dc0:~$ ldapsearch -LLL -H ldap://dc0 -b DC=ad,DC=schule,DC=lan '(|
> (cn=domain admins)(cn=administrators))' member|egrep -v '^#|^$'
> SASL/GSSAPI authentication started
> SASL username: user1 at AD.SCHULE.LAN
> SASL SSF: 56
> SASL data security layer installed.
> dn: CN=Administrators,CN=Builtin,DC=ad,DC=schule,DC=lan
> member: CN=Domain Admins,CN=Users,DC=ad,DC=schule,DC=lan
> member: CN=Enterprise Admins,CN=Users,DC=ad,DC=schule,DC=lan
> member: CN=Administrator,CN=Users,DC=ad,DC=schule,DC=lan
> dn: CN=Domain Admins,CN=Users,DC=ad,DC=schule,DC=lan
> member: CN=Administrator,CN=Users,DC=ad,DC=schule,DC=lan
> member: CN=user1,CN=Users,DC=ad,DC=schule,DC=lan
> member: CN=user4,CN=Users,DC=ad,DC=schule,DC=lan
> user1 is only member of "Domain Admins". This is the best way to do it.

Having user1 in Domain Admins nested into Administrators did not work 
for me. But adding user1 to Administrators directly yielded proper access.

Thanks for hint.

More information about the samba mailing list