thr3ads.net - samba - [Samba] How to manipulate ldap access rights on Samba 4? [Jul 2014]

If this information is useful, please help other people find it:
Share via:

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

head link

[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

Possibly Parallel Threads

Search for more possibly parallel threads

samba - Jul 2014 - How to manipulate ldap access rights on Samba 4?

[Samba] How to manipulate ldap access rights on Samba 4?

[Samba] How to manipulate ldap access rights on Samba 4?

Possibly Parallel Threads