On 03 Jul 2014, at 09:09, Teemu Keinonen <[email protected]> wrote:
> On 01/07/14 12:18, "Jakub Hrozek" <[email protected]> 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: [email protected] >> >> 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 [email protected] > I’m sorry for the late reply. > Update on this. It seems [email protected] 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 '[email protected]' -k -t /etc/krb5.sssd.keytab > [root@dc1 ~]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: [email protected] > > Valid starting Expires Service principal > 07/03/14 10:06:54 07/03/14 20:06:54 krbtgt/[email protected] > 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: [email protected] > 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 > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/sssd-users _______________________________________________ sssd-users mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-users
