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?
Or can anybody tell me where I am going wrong (again).
Rowland
On (19/09/13 17:18), 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
^^^^^^ This line should be in domain section and not "[sudo]"
I hope it helps.
LS
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?
Or can anybody tell me where I am going wrong (again).
Rowland
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 19/09/13 17:29, Lukas Slebodnik wrote:
On (19/09/13 17:18), 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
^^^^^^ This line should be in domain section and not "[sudo]"
I hope it helps.
LS
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?
Or can anybody tell me where I am going wrong (again).
Rowland
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi, thanks for replying, that was my bad formatting in the post, it is actually under the domain section, there is nothing in the [sudo] section.
Rowland
On 09/19/2013 12:44 PM, Rowland Penny wrote:
On 19/09/13 17:29, Lukas Slebodnik wrote:
On (19/09/13 17:18), 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
^^^^^^ This line should be in domain section and not "[sudo]"
I hope it helps.
LS
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=*[*]*))))
Does the ldap search with this filter return any results?
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?
Or can anybody tell me where I am going wrong (again).
Rowland
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi, thanks for replying, that was my bad formatting in the post, it is actually under the domain section, there is nothing in the [sudo] section.
Rowland
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 19/09/13 23:09, Dmitri Pal wrote:
On 09/19/2013 12:44 PM, Rowland Penny wrote:
On 19/09/13 17:29, Lukas Slebodnik wrote:
On (19/09/13 17:18), 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
^^^^^^ This line should be in domain section and not "[sudo]"
I hope it helps.
LS
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=*[*]*))))
Does the ldap search with this filter return any results?
Yes, it actually returns more than the sudo search but does not seem to use any of them
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?
Or can anybody tell me where I am going wrong (again).
Rowland
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi, thanks for replying, that was my bad formatting in the post, it is actually under the domain section, there is nothing in the [sudo] section.
Rowland
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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
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).
Then it would seem to be the later part that is failing
with 'sudoers: files ldap' in /etc/nsswitch.conf
sudo -l Matching 'Defaults' entries for rowland on this host: env_reset, mail_badpass, secure_path=/usr/local/samba/bin:/usr/local/samba/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User rowland may run the following commands on this host: (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py (root) ALL
with 'sudoers: files sss' in /etc/nsswitch.conf
sudo -l Matching 'Defaults' entries for rowland on this host: env_reset, mail_badpass, secure_path=/usr/local/samba/bin:/usr/local/samba/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User rowland may run the following commands on this host: (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py
Can you send us (sanitized or privately if you want) your complete sssd.conf, sssd_yourdomain.log and sssd_sudo.log please?
No problem, what log level would you like?
Or can anybody tell me where I am going wrong (again).
Rowland
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 09/20/2013 11:09 AM, 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).
Then it would seem to be the later part that is failing
with 'sudoers: files ldap' in /etc/nsswitch.conf
sudo -l Matching 'Defaults' entries for rowland on this host: env_reset, mail_badpass, secure_path=/usr/local/samba/bin:/usr/local/samba/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User rowland may run the following commands on this host: (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py (root) ALL
with 'sudoers: files sss' in /etc/nsswitch.conf
sudo -l Matching 'Defaults' entries for rowland on this host: env_reset, mail_badpass, secure_path=/usr/local/samba/bin:/usr/local/samba/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User rowland may run the following commands on this host: (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py
SSSD will not provide any rules for local users or local groups. So even if root (local user) is part of linuxusers group (I assume LDAP group) than the output is correct.
The rules are provided only for SSSD-managed users and groups.
If you have troubles with LDAP users, I will need those logs.
Can you send us (sanitized or privately if you want) your complete sssd.conf, sssd_yourdomain.log and sssd_sudo.log please?
No problem, what log level would you like?
0x3ff
Or can anybody tell me where I am going wrong (again).
Rowland
On 20/09/13 13:49, Pavel Březina wrote:
On 09/20/2013 11:09 AM, 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).
Then it would seem to be the later part that is failing
with 'sudoers: files ldap' in /etc/nsswitch.conf
sudo -l Matching 'Defaults' entries for rowland on this host: env_reset, mail_badpass, secure_path=/usr/local/samba/bin:/usr/local/samba/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User rowland may run the following commands on this host: (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py (root) ALL
with 'sudoers: files sss' in /etc/nsswitch.conf
sudo -l Matching 'Defaults' entries for rowland on this host: env_reset, mail_badpass, secure_path=/usr/local/samba/bin:/usr/local/samba/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User rowland may run the following commands on this host: (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py
SSSD will not provide any rules for local users or local groups. So even if root (local user) is part of linuxusers group (I assume LDAP group) than the output is correct.
I am now getting a bit confused, I took the output of 'sudo -l' to mean '(user_to_runas) what_to_run', so '(root) ALL' would allow the user to run all programs as root provided that the correct users password is entered when prompted. So as the whole idea is usually for a user to run programs as root and root is always a local user, you lost me there.
The rules are provided only for SSSD-managed users and groups.
I understand this
If you have troubles with LDAP users, I will need those logs.
Can you send us (sanitized or privately if you want) your complete sssd.conf, sssd_yourdomain.log and sssd_sudo.log please?
No problem, what log level would you like?
0x3ff
Have attached log level 9 logs
Or can anybody tell me where I am going wrong (again).
Rowland
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 09/20/2013 03:40 PM, Rowland Penny wrote:
On 20/09/13 13:49, Pavel Březina wrote:
On 09/20/2013 11:09 AM, 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).
Then it would seem to be the later part that is failing
with 'sudoers: files ldap' in /etc/nsswitch.conf
sudo -l Matching 'Defaults' entries for rowland on this host: env_reset, mail_badpass, secure_path=/usr/local/samba/bin:/usr/local/samba/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User rowland may run the following commands on this host: (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py (root) ALL
with 'sudoers: files sss' in /etc/nsswitch.conf
sudo -l Matching 'Defaults' entries for rowland on this host: env_reset, mail_badpass, secure_path=/usr/local/samba/bin:/usr/local/samba/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User rowland may run the following commands on this host: (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py
SSSD will not provide any rules for local users or local groups. So even if root (local user) is part of linuxusers group (I assume LDAP group) than the output is correct.
I am now getting a bit confused, I took the output of 'sudo -l' to mean '(user_to_runas) what_to_run', so '(root) ALL' would allow the user to run all programs as root provided that the correct users password is entered when prompted. So as the whole idea is usually for a user to run programs as root and root is always a local user, you lost me there.
Ah, sorry to confuse you. I messed it up a little. When I saw "root" I somehow managed to think that you run "sudo -l" under root user.
The rules are provided only for SSSD-managed users and groups.
I understand this
If you have troubles with LDAP users, I will need those logs.
Can you send us (sanitized or privately if you want) your complete sssd.conf, sssd_yourdomain.log and sssd_sudo.log please?
No problem, what log level would you like?
0x3ff
Have attached log level 9 logs
Thank for the logs. The LDAP provider stores three rules in the cache. Is this correct (sssd stores only those rules that are applicable to the machine)?
However, sssd_sudo.log says that sudo didn't communicate with sssd sudo responder at all. Did you run 'sudo -l' when you obtained the logs?
Can you double check that you have sudoers: files sss in /etc/nsswitch.conf and libsss_sudo.so installed?
What version of sudo do you use?
On 23/09/13 09:41, Pavel Březina wrote:
On 09/20/2013 03:40 PM, Rowland Penny wrote:
On 20/09/13 13:49, Pavel Březina wrote:
On 09/20/2013 11:09 AM, 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).
Then it would seem to be the later part that is failing
with 'sudoers: files ldap' in /etc/nsswitch.conf
sudo -l Matching 'Defaults' entries for rowland on this host: env_reset, mail_badpass, secure_path=/usr/local/samba/bin:/usr/local/samba/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User rowland may run the following commands on this host: (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py (root) ALL
with 'sudoers: files sss' in /etc/nsswitch.conf
sudo -l Matching 'Defaults' entries for rowland on this host: env_reset, mail_badpass, secure_path=/usr/local/samba/bin:/usr/local/samba/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User rowland may run the following commands on this host: (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py
SSSD will not provide any rules for local users or local groups. So even if root (local user) is part of linuxusers group (I assume LDAP group) than the output is correct.
I am now getting a bit confused, I took the output of 'sudo -l' to mean '(user_to_runas) what_to_run', so '(root) ALL' would allow the user to run all programs as root provided that the correct users password is entered when prompted. So as the whole idea is usually for a user to run programs as root and root is always a local user, you lost me there.
Ah, sorry to confuse you. I messed it up a little. When I saw "root" I somehow managed to think that you run "sudo -l" under root user.
The rules are provided only for SSSD-managed users and groups.
I understand this
If you have troubles with LDAP users, I will need those logs.
Can you send us (sanitized or privately if you want) your complete sssd.conf, sssd_yourdomain.log and sssd_sudo.log please?
No problem, what log level would you like?
0x3ff
Have attached log level 9 logs
Thank for the logs. The LDAP provider stores three rules in the cache. Is this correct (sssd stores only those rules that are applicable to the machine)?
However, sssd_sudo.log says that sudo didn't communicate with sssd sudo responder at all. Did you run 'sudo -l' when you obtained the logs?
Can you double check that you have sudoers: files sss in /etc/nsswitch.conf and libsss_sudo.so installed?
What version of sudo do you use? _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
This is a test domain and the rules are all set to 'sudoHost: ALL', none of the rules were downloaded until I added a defaults rule.
yes I did run 'sudo -l'
yes I do have the sudoers line in nsswitch.conf
libsss_sudo.so is in /usr/lib/x86_64-linux-gnu
This is where it gets interesting, I was originally trying sudo from my laptop running sssd 1.10.92, but I have now setup a VM running LM15 with sssd 1.9.4 and this has the same problem. I cannot see anywhere in any logs where sudo connects to sssd to get the rules, so I am now beginning to think that this is actually a sudo problem. The fact that using 'ldap' instead of 'sss' in nsswitch.conf works seems to point to this.
It would help if sudo actually logged somewhere without having to jump through hoops ;-)
Rowland
On 09/23/2013 11:45 AM, Rowland Penny wrote:
On 23/09/13 09:41, Pavel Březina wrote:
On 09/20/2013 03:40 PM, Rowland Penny wrote:
On 20/09/13 13:49, Pavel Březina wrote:
On 09/20/2013 11:09 AM, 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).
Then it would seem to be the later part that is failing
with 'sudoers: files ldap' in /etc/nsswitch.conf
sudo -l Matching 'Defaults' entries for rowland on this host: env_reset, mail_badpass, secure_path=/usr/local/samba/bin:/usr/local/samba/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User rowland may run the following commands on this host: (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py (root) ALL
with 'sudoers: files sss' in /etc/nsswitch.conf
sudo -l Matching 'Defaults' entries for rowland on this host: env_reset, mail_badpass, secure_path=/usr/local/samba/bin:/usr/local/samba/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User rowland may run the following commands on this host: (root) NOPASSWD: /usr/lib/linuxmint/mintUpdate/checkAPT.py
SSSD will not provide any rules for local users or local groups. So even if root (local user) is part of linuxusers group (I assume LDAP group) than the output is correct.
I am now getting a bit confused, I took the output of 'sudo -l' to mean '(user_to_runas) what_to_run', so '(root) ALL' would allow the user to run all programs as root provided that the correct users password is entered when prompted. So as the whole idea is usually for a user to run programs as root and root is always a local user, you lost me there.
Ah, sorry to confuse you. I messed it up a little. When I saw "root" I somehow managed to think that you run "sudo -l" under root user.
The rules are provided only for SSSD-managed users and groups.
I understand this
If you have troubles with LDAP users, I will need those logs.
Can you send us (sanitized or privately if you want) your complete sssd.conf, sssd_yourdomain.log and sssd_sudo.log please?
No problem, what log level would you like?
0x3ff
Have attached log level 9 logs
Thank for the logs. The LDAP provider stores three rules in the cache. Is this correct (sssd stores only those rules that are applicable to the machine)?
However, sssd_sudo.log says that sudo didn't communicate with sssd sudo responder at all. Did you run 'sudo -l' when you obtained the logs?
Can you double check that you have sudoers: files sss in /etc/nsswitch.conf and libsss_sudo.so installed?
What version of sudo do you use? _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
This is a test domain and the rules are all set to 'sudoHost: ALL', none of the rules were downloaded until I added a defaults rule.
yes I did run 'sudo -l'
yes I do have the sudoers line in nsswitch.conf
libsss_sudo.so is in /usr/lib/x86_64-linux-gnu
This is where it gets interesting, I was originally trying sudo from my laptop running sssd 1.10.92, but I have now setup a VM running LM15 with sssd 1.9.4 and this has the same problem. I cannot see anywhere in any logs where sudo connects to sssd to get the rules, so I am now beginning to think that this is actually a sudo problem. The fact that using 'ldap' instead of 'sss' in nsswitch.conf works seems to point to this.
It would help if sudo actually logged somewhere without having to jump through hoops ;-)
Rowland
Can you put into /etc/sudo.conf the following line? Debug sudo /var/log/sudo_debug all@trace
Re-run sudo and send me the file?
Also what version of sudo do you run?
On 20/09/13 08:36, Pavel Březina wrote:
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).
Hi, from reading the above, I assume that the sudo rules are cached with everything else in /var/lib/sss/db/cache_example.com.ldb. But the only referral to sudo in the db is:
dn: cn=sudorules,cn=custom,cn=example.com,cn=sysdb cn: sudorules sudoLastFullRefreshTime: 1379759042 distinguishedName: cn=sudorules,cn=custom,cn=example.com,cn=sysdb
I take it this is the base where the sudo rules should be stored, but there are none.
Rowland
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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.
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!!!!!!
Rowland
On Sat, Sep 21, 2013 at 03:38:30PM +0100, Rowland Penny wrote:
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.
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!!!!!!
Rowland
Pavel, can you take a look at the issue?
Question: Is it possible to extend AD schema (and if yes, how?) so it can store Sudo rules for SSSD? If yes, the I would be very interested as well. Ondrej ________________________________________ From: sssd-users-bounces@lists.fedorahosted.org [sssd-users-bounces@lists.fedorahosted.org] on behalf of Jakub Hrozek [jhrozek@redhat.com] Sent: Monday, September 23, 2013 10:22 AM To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] sssd and sudo
On Sat, Sep 21, 2013 at 03:38:30PM +0100, Rowland Penny wrote:
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.
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!!!!!!
Rowland
Pavel, can you take a look at the issue? _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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@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
On 23/09/13 09:51, Pavel Březina wrote:
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@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
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi, I am fairly sure that I have fixed my problem, it is not a sssd problem, it is an ubuntu problem.
I was using 'sudo-ldap' as you need this to connect via ldap, so I assumed I needed it to connect via sssd, this it would seem is wrong.
On: https://launchpad.net/ubuntu/+source/sudo/+changelog
I found this:
1.8.6p3-0ubuntu1 Superseded in raring-release on 2012-12-08 Deleted in raring-proposed on 2012-12-09 (Reason: moved to release)
sudo (1.8.6p3-0ubuntu1) raring; urgency=low
* New upstream release (1.8.6p3). * Add patch to fix building with sssd when ldap is disabled. * Drop sudo.manpages and sudo-ldap.manpages as the upstream build system now does the right thing here. * Build the main sudo package with support for sssd, this doesn't add any additional build time or runtime dependency. sudo will dynamically load the sssd library if 'sss' is listed for the 'sudoers' nss service. -- Stephane Graber <email address hidden> Fri, 16 Nov 2012 09:31:32 -0500
Hmm, the 'sudo' package seems to be built to connect to sssd.
Re-installed the 'sudo' package and it now seems to work, so I can only surmise that the 'sudo-ldap' package isn't built to connect to sssd for whatever reason.
It would make more sense to build (well to me anyway) a 'sudo-sssd' package OR just one 'sudo' package.
Rowland
Rowland
On 09/23/2013 12:17 PM, Rowland Penny wrote:
On 23/09/13 09:51, Pavel Březina wrote:
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@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
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi, I am fairly sure that I have fixed my problem, it is not a sssd problem, it is an ubuntu problem.
I was using 'sudo-ldap' as you need this to connect via ldap, so I assumed I needed it to connect via sssd, this it would seem is wrong.
On: https://launchpad.net/ubuntu/+source/sudo/+changelog
I found this:
1.8.6p3-0ubuntu1 Superseded in raring-release on 2012-12-08 Deleted in raring-proposed on 2012-12-09 (Reason: moved to release)
sudo (1.8.6p3-0ubuntu1) raring; urgency=low
- New upstream release (1.8.6p3).
- Add patch to fix building with sssd when ldap is disabled.
- Drop sudo.manpages and sudo-ldap.manpages as the upstream build system now does the right thing here.
- Build the main sudo package with support for sssd, this doesn't add
any additional build time or runtime dependency. sudo will dynamically load the sssd library if 'sss' is listed for the 'sudoers' nss service. -- Stephane Graber <email address hidden> Fri, 16 Nov 2012 09:31:32 -0500
Hmm, the 'sudo' package seems to be built to connect to sssd.
Re-installed the 'sudo' package and it now seems to work, so I can only surmise that the 'sudo-ldap' package isn't built to connect to sssd for whatever reason.
It would make more sense to build (well to me anyway) a 'sudo-sssd' package OR just one 'sudo' package.
Rowland
Rowland
Hi, I'm glad you solved this out. This is indeed confusing. It's probably worth a try to open a packaging bug on ubuntu.
Great. could you share with us the procedure you used to extend AD schema? Thanks, a lot. Ondrej ________________________________________ From: sssd-users-bounces@lists.fedorahosted.org [sssd-users-bounces@lists.fedorahosted.org] on behalf of Rowland Penny [repenny241155@gmail.com] Sent: Monday, September 23, 2013 12:17 PM To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd and sudo [SOLVED]
On 23/09/13 09:51, Pavel Březina wrote:
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@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
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi, I am fairly sure that I have fixed my problem, it is not a sssd problem, it is an ubuntu problem.
I was using 'sudo-ldap' as you need this to connect via ldap, so I assumed I needed it to connect via sssd, this it would seem is wrong.
On: https://launchpad.net/ubuntu/+source/sudo/+changelog
I found this:
1.8.6p3-0ubuntu1 Superseded in raring-release on 2012-12-08 Deleted in raring-proposed on 2012-12-09 (Reason: moved to release)
sudo (1.8.6p3-0ubuntu1) raring; urgency=low
* New upstream release (1.8.6p3). * Add patch to fix building with sssd when ldap is disabled. * Drop sudo.manpages and sudo-ldap.manpages as the upstream build system now does the right thing here. * Build the main sudo package with support for sssd, this doesn't add any additional build time or runtime dependency. sudo will dynamically load the sssd library if 'sss' is listed for the 'sudoers' nss service. -- Stephane Graber <email address hidden> Fri, 16 Nov 2012 09:31:32 -0500
Hmm, the 'sudo' package seems to be built to connect to sssd.
Re-installed the 'sudo' package and it now seems to work, so I can only surmise that the 'sudo-ldap' package isn't built to connect to sssd for whatever reason.
It would make more sense to build (well to me anyway) a 'sudo-sssd' package OR just one 'sudo' package.
Rowland
Rowland
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 23/09/13 11:40, Ondrej Valousek wrote:
Great. could you share with us the procedure you used to extend AD schema? Thanks, a lot. Ondrej ________________________________________ From: sssd-users-bounces@lists.fedorahosted.org [sssd-users-bounces@lists.fedorahosted.org] on behalf of Rowland Penny [repenny241155@gmail.com] Sent: Monday, September 23, 2013 12:17 PM To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd and sudo [SOLVED]
On 23/09/13 09:51, Pavel Březina wrote:
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@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
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi, I am fairly sure that I have fixed my problem, it is not a sssd problem, it is an ubuntu problem.
I was using 'sudo-ldap' as you need this to connect via ldap, so I assumed I needed it to connect via sssd, this it would seem is wrong.
On: https://launchpad.net/ubuntu/+source/sudo/+changelog
I found this:
1.8.6p3-0ubuntu1 Superseded in raring-release on 2012-12-08 Deleted in raring-proposed on 2012-12-09 (Reason: moved to release)
sudo (1.8.6p3-0ubuntu1) raring; urgency=low
* New upstream release (1.8.6p3). * Add patch to fix building with sssd when ldap is disabled. * Drop sudo.manpages and sudo-ldap.manpages as the upstream build system now does the right thing here. * Build the main sudo package with support for sssd, this doesn't add any additional build time or runtime dependency. sudo will dynamically load the sssd library if 'sss' is listed for the 'sudoers' nss service.-- Stephane Graber <email address hidden> Fri, 16 Nov 2012 09:31:32 -0500
Hmm, the 'sudo' package seems to be built to connect to sssd.
Re-installed the 'sudo' package and it now seems to work, so I can only surmise that the 'sudo-ldap' package isn't built to connect to sssd for whatever reason.
It would make more sense to build (well to me anyway) a 'sudo-sssd' package OR just one 'sudo' package.
Rowland
Rowland
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
OK, to add sudo to sssd on samba4, you need the following ldifs:
sudo_attr.ldif
dn: CN=sudoUser,CN=Schema,CN=Configuration,DC=example,DC=com objectClass: top objectClass: attributeSchema attributeID: 1.3.6.1.4.1.15953.9.1.1 schemaIDGUID:: JrGcaKpnoU+0s+HgeFjAbg== cn: sudoUser name: sudoUser lDAPDisplayName: sudoUser adminDisplayName: sudoUser adminDescription: User(s) who may run sudo attributeSyntax: 2.5.5.5 isSingleValued: FALSE showInAdvancedViewOnly: TRUE oMSyntax: 22 searchFlags: 1
dn: CN=sudoHost,CN=Schema,CN=Configuration,DC=example,DC=com objectClass: top objectClass: attributeSchema attributeID: 1.3.6.1.4.1.15953.9.1.2 schemaIDGUID:: d0TTjg+Y6U28g/Y+ns2k4w== cn: sudoHost name: sudoHost lDAPDisplayName: sudoHost adminDisplayName: sudoHost adminDescription: Host(s) who may run sudo attributeSyntax: 2.5.5.5 isSingleValued: FALSE showInAdvancedViewOnly: TRUE oMSyntax: 22
dn: CN=sudoCommand,CN=Schema,CN=Configuration,DC=example,DC=com objectClass: top objectClass: attributeSchema attributeID: 1.3.6.1.4.1.15953.9.1.3 schemaIDGUID:: D6QR4P5UyUen3RGYJCHCPg== cn: sudoCommand name: sudoCommand lDAPDisplayName: sudoCommand adminDisplayName: sudoCommand adminDescription: Command(s) to be executed by sudo attributeSyntax: 2.5.5.5 isSingleValued: FALSE showInAdvancedViewOnly: TRUE oMSyntax: 22
dn: CN=sudoRunAs,CN=Schema,CN=Configuration,DC=example,DC=com objectClass: top objectClass: attributeSchema attributeID: 1.3.6.1.4.1.15953.9.1.4 schemaIDGUID:: CP98mCQTyUKKxGrQeM80hQ== cn: sudoRunAs name: sudoRunAs lDAPDisplayName: sudoRunAs adminDisplayName: sudoRunAs adminDescription: User(s) impersonated by sudo (deprecated) attributeSyntax: 2.5.5.5 isSingleValued: FALSE showInAdvancedViewOnly: TRUE oMSyntax: 22
dn: CN=sudoOption,CN=Schema,CN=Configuration,DC=example,DC=com objectClass: top objectClass: attributeSchema attributeID: 1.3.6.1.4.1.15953.9.1.5 schemaIDGUID:: ojaPzBBlAEmsvrHxQctLnA== cn: sudoOption name: sudoOption lDAPDisplayName: sudoOption adminDisplayName: sudoOption adminDescription: Option(s) followed by sudo attributeSyntax: 2.5.5.5 isSingleValued: FALSE showInAdvancedViewOnly: TRUE oMSyntax: 22
dn: CN=sudoRunAsUser,CN=Schema,CN=Configuration,DC=example,DC=com objectClass: top objectClass: attributeSchema attributeID: 1.3.6.1.4.1.15953.9.1.6 schemaIDGUID:: 9C52yPYd3RG3jMR2VtiVkw== cn: sudoRunAsUser name: sudoRunAsUser lDAPDisplayName: sudoRunAsUser adminDisplayName: sudoRunAsUser adminDescription: User(s) impersonated by sudo attributeSyntax: 2.5.5.5 isSingleValued: FALSE showInAdvancedViewOnly: TRUE oMSyntax: 22
dn: CN=sudoRunAsGroup,CN=Schema,CN=Configuration,DC=example,DC=com objectClass: top objectClass: attributeSchema attributeID: 1.3.6.1.4.1.15953.9.1.7 schemaIDGUID:: xJhSt/Yd3RGJPTB1VtiVkw== cn: sudoRunAsGroup name: sudoRunAsGroup lDAPDisplayName: sudoRunAsGroup adminDisplayName: sudoRunAsGroup adminDescription: Groups(s) impersonated by sudo attributeSyntax: 2.5.5.5 isSingleValued: FALSE showInAdvancedViewOnly: TRUE oMSyntax: 22
dn: CN=sudoNotBefore,CN=Schema,CN=Configuration,DC=example,DC=com objectClass: top objectClass: attributeSchema attributeID: 1.3.6.1.4.1.15953.9.1.8 schemaIDGUID:: dm1HnRfY4RGf4gopYYhwmw== cn: sudoNotBefore name: sudoNotBefore lDAPDisplayName: sudoNotBefore adminDisplayName: sudoNotBefore adminDescription: Start of time interval for which the entry is valid attributeSyntax: 2.5.5.11 isSingleValued: TRUE showInAdvancedViewOnly: TRUE oMSyntax: 24
dn: CN=sudoNotAfter,CN=Schema,CN=Configuration,DC=example,DC=com objectClass: top objectClass: attributeSchema attributeID: 1.3.6.1.4.1.15953.9.1.9 schemaIDGUID:: OAr/pBfY4RG9dBIpYYhwmw== cn: sudoNotAfter name: sudoNotAfter lDAPDisplayName: sudoNotAfter adminDisplayName: sudoNotAfter adminDescription: End of time interval for which the entry is valid attributeSyntax: 2.5.5.11 isSingleValued: TRUE showInAdvancedViewOnly: TRUE oMSyntax: 24
dn: CN=sudoOrder,CN=Schema,CN=Configuration,DC=example,DC=com objectClass: top objectClass: attributeSchema attributeID: 1.3.6.1.4.1.15953.9.1.10 schemaIDGUID:: 0J8yrRfY4RGIYBUpYYhwmw== cn: sudoOrder name: sudoOrder lDAPDisplayName: sudoOrder adminDisplayName: sudoOrder adminDescription: an integer to order the sudoRole entries attributeSyntax: 2.5.5.9 isSingleValued: TRUE showInAdvancedViewOnly: TRUE oMSyntax: 2
sudo_class.ldif
dn: CN=sudoRole,CN=Schema,CN=Configuration,DC=example,DC=com objectClass: top objectClass: classSchema governsID: 1.3.6.1.4.1.15953.9.2.1 schemaIDGUID:: SQn432lnZ0+ukbdh3+gN3w== cn: sudoRole name: sudoRole lDAPDisplayName: sudoRole possSuperiors: container possSuperiors: top subClassOf: top mayContain: sudoCommand mayContain: sudoHost mayContain: sudoOption mayContain: sudoRunAs mayContain: sudoRunAsUser mayContain: sudoRunAsGroup mayContain: sudoUser mayContain: sudoNotBefore mayContain: sudoNotAfter mayContain: sudoOrder showInAdvancedViewOnly: FALSE adminDisplayName: sudoRole adminDescription: Sudoer Entries objectClassCategory: 1 systemOnly: FALSE defaultObjectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=home,DC=lan
Stop samba 4 add the sudo_attr.ldif and then the sudo_class.ldif, see: https://wiki.samba.org/index.php/Samba4/Schema_extenstions
Rowland
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Lukas Slebodnik -
Ondrej Valousek -
Pavel Březina -
Rowland Penny