On 09/21/2013 04:38 PM, Rowland Penny wrote:
On 20/09/13 08:36, Pavel Březina wrote:
> On 09/19/2013 06:18 PM, Rowland Penny wrote:
>> Ok, I am back again, trying to get sssd to control sudo, but failing.
>>
>> I added the sudo active directory schema ldif to samba4 AD
>>
>> then added this:
>>
>> dn: OU=SUDOers,DC=example,DC=com
>> objectClass: top
>> objectClass: organizationalUnit
>> ou: SUDOers
>>
>> dn: CN=linuxusers,OU=SUDOers,DC=example,DC=com
>> objectClass: top
>> objectClass: sudoRole
>> cn: linuxusers
>> sudoUser: %linuxusers
>> sudoHost: ALL
>> sudoCommand: ALL
>>
>> On a Linux Mint client:
>>
>> sudo apt-get install sudo-ldap
>>
>> Edited /etc/sudo-ldap.conf
>>
>> # TLS certificates (needed for GnuTLS)
>> TLS_CACERT /etc/ssl/certs/ca-certificates.crt
>> BASE DC=example,DC=com
>> URI
ldap://server.example.com
>> ssl=no
>> LDAP_VERSION 3
>> SUDOERS_BASE ou=SUDOers,DC=example,DC=com
>> SUDOERS_SEARCH_FILTER (&(objectClass=sudoRole))
>> BINDDN CN=Administrator,CN=Users,DC=example,DC=com
>> BINDPW xxxxxxxxxx
>>
>> then edited /etc/nsswitch.conf and added
>>
>> sudoers: files ldap
>>
>> restarted sudo
>>
>> then as a normal user, tried to run a command with sudo, this worked.
>>
>> I then altered /etc/sssd/sssd.conf and added
>>
>> services = nss, pam, autofs, sudo
>>
>> [sudo]
>>
>> ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com
>>
>> altered /etc/nsswitch.conf
>>
>> sudoers: files sss
>>
>> restarted sssd
>> restarted sudo
>>
>> tried to run the command with sudo again, this time it failed
>>
>> having been bitten by the way autofs works, I went straight to the way
>> that sudo & sssd do the ldapsearch:
>>
>> SUDO
>> (&(&(objectClass=sudoRole))(|(sudoUser=rowland)(sudoUser=%Domain
>>
Users)(sudoUser=%#20513)(sudoUser=%vboxusers)(sudoUser=%linuxusers)(sudoUser=%#127)(sudoUser=%#21110)(sudoUser=ALL)))
>>
>>
>>
>> SSSD
>>
(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=ThinkPad)(sudoHost=ThinkPad.home.lan)(sudoHost=192.168.0.204)(sudoHost=192.168.0.0/24)(sudoHost=fe80::86a6:c8ff:fe3b:da7b)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*))))
>>
>>
>>
>> sudo searches with objectClass=sudoRole & sudoUser attribute
>> sssd searches with objectClass=sudoRole & sudoHost attribute
>>
>> Now I understand that the sssd search for the sudoHost attribute is to
>> ensure that only sudo rules for the host are downloaded, but it doesn't
>> actually seem to download any rules.
>>
>> Is there anyway I can get the sssd search to include the sudoUser
>> attribute in the same way that the sudo ldap search does?
>
> Hi,
> no, it is not desirable. SSSD periodically downloads all rules that
> are applicable to the machine, and then filters them by user when sudo
> request is performed. In other words: filtering by sudoUser is there,
> only on other place (sssd_sudo process).
>
> Can you send us (sanitized or privately if you want) your complete
> sssd.conf, sssd_yourdomain.log and sssd_sudo.log please?
>
>>
>> Or can anybody tell me where I am going wrong (again).
>>
>
Rowland
>
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi,
OK, I have now got sssd to cache the sudo rules from AD, I found out
that you must have 'defaults' in the AD database, I didn't and thought
you could just use the defaults on the client.
having cn=defaults in LDAP is not necessary. From the logs you've sent
me, I can see that three rules were stored in the cache.
If the rules are not stored when cn=defaults is missing, it is a bug.
However, I am unable to reproduce it.
Now, even though sssd has cached the rules, I still cannot get an AD
user to run a command as the root user.
Anybody got any further ideas? or to put it another way, HELPPPPP!!!!!!
Please, see my earlier response.
Rowland