Teemu Keinonen
2014-Jul-03 08:29 UTC
[Samba] How to manipulate ldap access rights on Samba 4?
Hi, I'm having hard time getting sssd_sudo to work: when sssd_sudo accesses Samba ldap with host principal 'dc1$@teemu.local' it can't read necessary attributes like objectclass: sudoRole. When accessing as Administrator all attributes are shown. How can I enable other users then Administrator to access sudoers' attributes? Below is an example. [root at dc1 var]# kinit administrator at TEEMU.LOCAL Password for administrator at TEEMU.LOCAL: Warning: Your password will expire in 35 days on Wed Aug 6 22:20:25 2014 [root at dc1 var]# ldapsearch -h dc1 -Y GSSAPI -b ou=SUDOers,dc=teemu,dc=local SASL/GSSAPI authentication started SASL username: administrator at TEEMU.LOCAL SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <ou=SUDOers,dc=teemu,dc=local> with scope subtree # filter: (objectclass=*) # requesting: ALL # # reima, SUDOers, teemu.local dn: CN=reima,OU=SUDOers,DC=teemu,DC=local objectClass: top objectClass: sudoRole cn: reima instanceType: 4 whenCreated: 20140625194650.0Z whenChanged: 20140625194650.0Z uSNCreated: 3799 uSNChanged: 3799 name: reima objectGUID:: U1paZdVOSke2zmInSenFTg=objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=teemu,DC=local sudoUser: reima sudoHost: ALL sudoCommand: ALL distinguishedName: CN=reima,OU=SUDOers,DC=teemu,DC=local # SUDOers, teemu.local dn: OU=SUDOers,DC=teemu,DC=local objectClass: top objectClass: organizationalUnit ou: SUDOers instanceType: 4 whenCreated: 20140625194301.0Z whenChanged: 20140625194301.0Z uSNCreated: 3797 uSNChanged: 3797 name: SUDOers objectGUID:: avd+e6OrGkOV5qqtjV39vQ=objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=teemu,DC local distinguishedName: OU=SUDOers,DC=teemu,DC=local # defaults, SUDOers, teemu.local dn: CN=defaults,OU=SUDOers,DC=teemu,DC=local objectClass: top objectClass: sudoRole cn: defaults description: Default sudoOption's go here instanceType: 4 whenCreated: 20140625194645.0Z whenChanged: 20140625194645.0Z uSNCreated: 3798 uSNChanged: 3798 name: defaults objectGUID:: vrCxbL/QkUGFyZWvELWj/w=objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=teemu,DC=local sudoOption: env_keep+=SSH_AUTH_SOCK distinguishedName: CN=defaults,OU=SUDOers,DC=teemu,DC=local # %wheel, SUDOers, teemu.local dn: CN=%wheel,OU=SUDOers,DC=teemu,DC=local objectClass: top objectClass: sudoRole cn: %wheel instanceType: 4 whenCreated: 20140626094147.0Z whenChanged: 20140626094147.0Z uSNCreated: 3800 uSNChanged: 3800 name: %wheel objectGUID:: jpGX5AmGUkimPw1yl+oZkA=objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=teemu,DC=local sudoUser: %wheel sudoHost: ALL sudoCommand: ALL distinguishedName: CN=%wheel,OU=SUDOers,DC=teemu,DC=local # search result search: 4 result: 0 Success # numResponses: 5 # numEntries: 4 [root at dc1 var]# kdestroy [root at dc1 var]# kinit 'dc1$@TEEMU.LOCAL' -k -t /etc/krb5.sssd.keytab [root at dc1 var]# ldapsearch -h dc1 -Y GSSAPI -b ou=SUDOers,dc=teemu,dc=local SASL/GSSAPI authentication started SASL username: dc1$@TEEMU.LOCAL SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <ou=SUDOers,dc=teemu,dc=local> with scope subtree # filter: (objectclass=*) # requesting: ALL # # reima, SUDOers, teemu.local dn: CN=reima,OU=SUDOers,DC=teemu,DC=local # SUDOers, teemu.local dn: OU=SUDOers,DC=teemu,DC=local objectClass: top objectClass: organizationalUnit ou: SUDOers instanceType: 4 whenCreated: 20140625194301.0Z whenChanged: 20140625194301.0Z uSNCreated: 3797 uSNChanged: 3797 name: SUDOers objectGUID:: avd+e6OrGkOV5qqtjV39vQ=objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=teemu,DC local distinguishedName: OU=SUDOers,DC=teemu,DC=local # defaults, SUDOers, teemu.local dn: CN=defaults,OU=SUDOers,DC=teemu,DC=local # %wheel, SUDOers, teemu.local dn: CN=%wheel,OU=SUDOers,DC=teemu,DC=local # search result search: 4 result: 0 Success # numResponses: 5 # numEntries: 4 -- --Teemu Keinonen
Rowland Penny
2014-Jul-03 09:46 UTC
[Samba] How to manipulate ldap access rights on Samba 4?
On 03/07/14 09:29, Teemu Keinonen wrote:> Hi, > > I'm having hard time getting sssd_sudo to work: when sssd_sudo > accesses Samba ldap with host principal 'dc1$@teemu.local' it can't > read necessary attributes like objectclass: sudoRole. When accessing > as Administrator all attributes are shown. How can I enable other > users then Administrator to access sudoers' attributes? Below is an > example. > > [root at dc1 var]# kinit administrator at TEEMU.LOCAL > Password for administrator at TEEMU.LOCAL: > Warning: Your password will expire in 35 days on Wed Aug 6 22:20:25 2014 > [root at dc1 var]# ldapsearch -h dc1 -Y GSSAPI -b ou=SUDOers,dc=teemu,dc=local > SASL/GSSAPI authentication started > SASL username: administrator at TEEMU.LOCAL > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base <ou=SUDOers,dc=teemu,dc=local> with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # reima, SUDOers, teemu.local > dn: CN=reima,OU=SUDOers,DC=teemu,DC=local > objectClass: top > objectClass: sudoRole > cn: reima > instanceType: 4 > whenCreated: 20140625194650.0Z > whenChanged: 20140625194650.0Z > uSNCreated: 3799 > uSNChanged: 3799 > name: reima > objectGUID:: U1paZdVOSke2zmInSenFTg=> objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=teemu,DC=local > sudoUser: reima > sudoHost: ALL > sudoCommand: ALL > distinguishedName: CN=reima,OU=SUDOers,DC=teemu,DC=local > > # SUDOers, teemu.local > dn: OU=SUDOers,DC=teemu,DC=local > objectClass: top > objectClass: organizationalUnit > ou: SUDOers > instanceType: 4 > whenCreated: 20140625194301.0Z > whenChanged: 20140625194301.0Z > uSNCreated: 3797 > uSNChanged: 3797 > name: SUDOers > objectGUID:: avd+e6OrGkOV5qqtjV39vQ=> objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=teemu,DC> local > distinguishedName: OU=SUDOers,DC=teemu,DC=local > > # defaults, SUDOers, teemu.local > dn: CN=defaults,OU=SUDOers,DC=teemu,DC=local > objectClass: top > objectClass: sudoRole > cn: defaults > description: Default sudoOption's go here > instanceType: 4 > whenCreated: 20140625194645.0Z > whenChanged: 20140625194645.0Z > uSNCreated: 3798 > uSNChanged: 3798 > name: defaults > objectGUID:: vrCxbL/QkUGFyZWvELWj/w=> objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=teemu,DC=local > sudoOption: env_keep+=SSH_AUTH_SOCK > distinguishedName: CN=defaults,OU=SUDOers,DC=teemu,DC=local > > # %wheel, SUDOers, teemu.local > dn: CN=%wheel,OU=SUDOers,DC=teemu,DC=local > objectClass: top > objectClass: sudoRole > cn: %wheel > instanceType: 4 > whenCreated: 20140626094147.0Z > whenChanged: 20140626094147.0Z > uSNCreated: 3800 > uSNChanged: 3800 > name: %wheel > objectGUID:: jpGX5AmGUkimPw1yl+oZkA=> objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=teemu,DC=local > sudoUser: %wheel > sudoHost: ALL > sudoCommand: ALL > distinguishedName: CN=%wheel,OU=SUDOers,DC=teemu,DC=local > > # search result > search: 4 > result: 0 Success > > # numResponses: 5 > # numEntries: 4 > > > [root at dc1 var]# kdestroy > [root at dc1 var]# kinit 'dc1$@TEEMU.LOCAL' -k -t /etc/krb5.sssd.keytab > [root at dc1 var]# ldapsearch -h dc1 -Y GSSAPI -b ou=SUDOers,dc=teemu,dc=local > SASL/GSSAPI authentication started > SASL username: dc1$@TEEMU.LOCAL > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base <ou=SUDOers,dc=teemu,dc=local> with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # reima, SUDOers, teemu.local > dn: CN=reima,OU=SUDOers,DC=teemu,DC=local > > # SUDOers, teemu.local > dn: OU=SUDOers,DC=teemu,DC=local > objectClass: top > objectClass: organizationalUnit > ou: SUDOers > instanceType: 4 > whenCreated: 20140625194301.0Z > whenChanged: 20140625194301.0Z > uSNCreated: 3797 > uSNChanged: 3797 > name: SUDOers > objectGUID:: avd+e6OrGkOV5qqtjV39vQ=> objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=teemu,DC> local > distinguishedName: OU=SUDOers,DC=teemu,DC=local > > # defaults, SUDOers, teemu.local > dn: CN=defaults,OU=SUDOers,DC=teemu,DC=local > > # %wheel, SUDOers, teemu.local > dn: CN=%wheel,OU=SUDOers,DC=teemu,DC=local > > # search result > search: 4 > result: 0 Success > > # numResponses: 5 > # numEntries: 4 >I do not think that your problem has anything to do with AD, it is more likely to be the way that you have setup sssd. It should just work on Centos6.5, see here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-ldap-sudo.html Is your setup like that? Also, Just what clients are you using and does their sudo know about sssd, I think that you need to be using sudo version 1.8.6 or later to get the sudo to sssd connection. Rowland