On 03 Jul 2014, at 09:09, Teemu Keinonen Teemu.Keinonen@relex.fi wrote:
On 01/07/14 12:18, "Jakub Hrozek" jhrozek@redhat.com wrote:
On Fri, Jun 27, 2014 at 12:24:44PM +0000, Teemu Keinonen wrote:
Hello,
I’m configuring CentOS 6.5 server to authenticate users and sudo rights against local Samba 4.1.8 (compiled from source). Sssd is 1.9.2 from package repository. User authentication works OK, I can log in with user that exists only in Samba but sudoing with the same user fails. After hours of trying I still can’t get it right, sssd_sudo receives 0 rules from samba. Doing ldapsearch with criteria from logs do return sudoer entries as below. Am I missing something obvious? Below are (in order) ldapsearch, ssssd.conf and sssd_default.log (part which I think relevant).
[root@dc1 sssd]# ldapsearch -h dc1 -Y GSSAPI -b OU=SUDOers,DC=teemu,DC=local '(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=Host01) (sudoHost=Host01.example.com)(sudoHost=192.168.0.21)(sudoHost=192.168.0.0 /24)(sudoHost=fe80::786b:f4ff:fe87:3314)(sudoHost=fe80::/64)(sudoHost=+*) (|(sudoHost=*\*)(sudoHost=*?*)(sudoHost=***)(sudoHost=*[*]*))))' SASL/GSSAPI authentication started SASL username: administrator@TEEMU.LOCAL
I wonder if this ^^ could be the issue.
SSSD authenticates as the host itself, you seem to have authenticated as the administrator. Maybe there are some ACIs on the server preventing SSSD from accessing the rules?
Can you try: kdestroy kinit -k -t /etc/krb5.sssd.keytab dc1$@TEEMU.LOCAL
I’m sorry for the late reply.
Update on this. It seems dc1@TEEMU.LOCAL can’t read required attributes from sudoers and that causes the problem. Do I need to modify LDAP permissions somehow to enable reading of the required attributes? Example of search with missing attributes below.
This is quite expected, the usual principal for a computer account in AD is “shortname$@realm”, the trailing dollar sign is significant.
Can you post the whole sssd_default.log, including the part where SSSD establishes the connection and authorises to the server? In the config file you sent I see that you were using both a bind DN+password and a GSSAPI bind. I think you should use one or the other and I wonder if commenting out the bind would make a difference.
[root@dc1 ~]# kinit 'DC1$@TEEMU.LOCAL' -k -t /etc/krb5.sssd.keytab [root@dc1 ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: DC1$@TEEMU.LOCAL
Valid starting Expires Service principal 07/03/14 10:06:54 07/03/14 20:06:54 krbtgt/TEEMU.LOCAL@TEEMU.LOCAL renew until 07/10/14 10:06:54
[root@dc1 ~]# ldapsearch -h dc1 -Y GSSAPI -b ou=Sudoers,dc=teemu,dc=local
For the record, the above /should/ be exactly what SSSD should be doing.
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 #
# 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: 4 # numEntries: 3
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users