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