On 03/07/14 08:09, Teemu Keinonen 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
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.
[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 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
OK, I take back all that I said over on the samba list, sssd does not pull the sudo rules from AD
I have just spent two hours trying to get sssd to get the sudo rules from AD on my netbook that I have just installed Linux Mint mate 17 on, to no effect.
after upping sssd debug to 9, I found this search in sssd_example.com.log:
(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=netbook)(sudoHost=netbook.example.com)(sudoHost=192.168.0.229)(sudoHost=192.168.0.0/24)(sudoHost=fe80::1e4b:d6ff:fec0:e307)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*?*)(sudoHost=***)(sudoHost=*[*]*))))
If I try to search with this via ldbsearch, it does not work, all I get is this:
allocating request failed: Unable to parse search expression
If I remove one small part, it does work and displays the sudo roles
So, what does this do?
(sudoHost=***)
because I can only get the search to work without it
Rowland