[Samba] LDAP proxy auth [SOLVED]

[Lars Hanke]

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.