[Samba] LDAP proxy auth

[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.

-- 

Regards
	Harry Jede