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 SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <OU=SUDOers,DC=teemu,DC=local> with scope subtree # filter: (&(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=*[*]*)))) # requesting: ALL #
# defaults, SUDOers, teemu.local dn: CN=defaults,OU=SUDOers,DC=teemu,DC=local objectClass: top objectClass: sudoRole cn: defaults description: Default sudoOption's go here instanceType: 4 whenCreated: 20140625194645.0Z whenChanged: 20140625194645.0Z uSNCreated: 3798 uSNChanged: 3798 name: defaults objectGUID:: vrCxbL/QkUGFyZWvELWj/w== objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=teemu,DC=local sudoOption: env_keep+=SSH_AUTH_SOCK distinguishedName: CN=defaults,OU=SUDOers,DC=teemu,DC=local
# %wheel, SUDOers, teemu.local dn: CN=%wheel,OU=SUDOers,DC=teemu,DC=local objectClass: top objectClass: sudoRole cn: %wheel instanceType: 4 whenCreated: 20140626094147.0Z whenChanged: 20140626094147.0Z uSNCreated: 3800 uSNChanged: 3800 name: %wheel objectGUID:: jpGX5AmGUkimPw1yl+oZkA== objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=teemu,DC=local sudoUser: %wheel sudoHost: ALL sudoCommand: ALL distinguishedName: CN=%wheel,OU=SUDOers,DC=teemu,DC=local
# reima, SUDOers, teemu.local dn: CN=reima,OU=SUDOers,DC=teemu,DC=local objectClass: top objectClass: sudoRole cn: reima instanceType: 4 whenCreated: 20140625194650.0Z whenChanged: 20140625194650.0Z uSNCreated: 3799 uSNChanged: 3799 name: reima objectGUID:: U1paZdVOSke2zmInSenFTg== objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=teemu,DC=local sudoUser: reima sudoHost: ALL sudoCommand: ALL distinguishedName: CN=reima,OU=SUDOers,DC=teemu,DC=local
# search result search: 4 result: 0 Success
# numResponses: 4 # numEntries: 3
Sssd.conf: [sssd] services = nss, pam, sudo config_file_version = 2 domains = default debug_level = 10
[nss]
[pam]
[sudo] debug_level = 10
[domain/default] debug_level = 10 id_provider = ldap sudo_provider = ldap ldap_schema = rfc2307bis ldap_referrals = false ldap_uri = ldap://dc1.teemu.local ldap_search_base = cn=Users,dc=teemu,dc=local ldap_sudo_search_base = ou=sudoers,dc=teemu,dc=local ldap_force_upper_case_realm = true
# See man sssd-simple access_provider = simple # Uncomment to check for account expiration in DC # access_provider = ldap # ldap_access_order = expire # ldap_account_expire_policy = ad
# Enumeration is discouraged for performance reasons. # enumerate = true
ldap_default_bind_dn = cn=Administrator,cn=Users,dc=teemu,dc=local ldap_default_authtok = XXXXXX
auth_provider = krb5 chpass_provider = krb5 ldap_sasl_mech = gssapi ldap_sasl_authid = dc1$@TEEMU.LOCAL krb5_realm = TEEMU.LOCAL krb5_server = dc1.teemu.local krb5_kpasswd = dc1.teemu.local ldap_krb5_keytab = /etc/krb5.sssd.keytab
ldap_user_object_class = user ldap_user_name = samAccountName ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_user_shell = loginShell
ldap_group_object_class = group
sssd_default.log: (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_sudo_refresh_connect_done] (0x0400): SUDO LDAP connection successful (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_sudo_load_sudoers_next_base] (0x0400): Searching for sudo rules with base [ou=sudoers,dc=teemu,dc=local] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)\ (sudoHost=dc1)(sudoHost=dc1)(sudoHost=10.0.2.15)(sudoHost=10.0.2.0/24)(sudoHost=192.168.1.1)(sudoHost=192.168.1.0/24)(sudoHost=fe80::a00:27ff:fede:ba44)(sudoHost=fe80::/6\ 4)(sudoHost=fe80::a00:27ff:fef3:dc1)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\*)(sudoHost=*?*)(sudoHost=***)(sudoHost=*[*]*))))][ou=sudoers,dc=teemu,dc=local]. (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoCommand] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoHost] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoUser] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOption] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsUser] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsGroup] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotBefore] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotAfter] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOrder] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 12 (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0xfed4e0], connected[1], ops[0xff7c20], ldap[0xfedba0] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_done] (0x1000): Total count [0] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_sudo_load_sudoers_process] (0x0400): Receiving sudo rules with base [ou=sudoers,dc=teemu,dc=local] (Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_sudo_load_sudoers_done] (0x0400): Received 0 rules
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
before the ldapsearch?
btw your config file contains both GSSAPI configuration and a bind user, I suppose you can remove the latter?
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
before the ldapsearch?
Here is the result:
[root@dc1 sssd]# kdestroy [root@dc1 sssd]# kinit -k -t /etc/krb5.sssd.keytab dc1$TEEMU.LOCAL kinit: Keytab contains no suitable keys for dc1.LOCAL@TEEMU.LOCAL while getting initial credentials
So I guess the host doesn’t have access. How would I go about adding access rights? Can you point me to a good document source for these matters?
And thank you!
-TeemuK
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
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
re: https://lists.fedorahosted.org/pipermail/sssd-users/2014-July/001891.html <snip>
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=***)
I'm not sure what this search is supposed to do. What is the intention of this? If it is to search for any sudoHost value with a literal asterisk "*" character in it, then the search filter syntax is wrong. According to http://tools.ietf.org/html/rfc4515, if you want to use a "*" in a search filter, it must be escaped like this: \2A, so the search filter would be (sudoHost=*\2A*)
because I can only get the search to work without it
Rowland
On 09 Jul 2014, at 20:00, Rich Megginson rmeggins@redhat.com wrote:
re: https://lists.fedorahosted.org/pipermail/sssd-users/2014-July/001891.html
<snip> > 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=*\**)
I'm not sure what this search is supposed to do. What is the intention of this? If it is to search for any sudoHost value with a literal asterisk "*" character in it, then the search filter syntax is wrong. According to http://tools.ietf.org/html/rfc4515, if you want to use a "*" in a search filter, it must be escaped like this: \2A, so the search filter would be (sudoHost=*\2A*)
Thanks for chiming in, Rich.
Pavel, can you inspect the code and file a ticket if we have a bug?
because I can only get the search to work without it
Rowland
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 07/09/2014 10:34 PM, Jakub Hrozek wrote:
On 09 Jul 2014, at 20:00, Rich Megginson rmeggins@redhat.com wrote:
re: https://lists.fedorahosted.org/pipermail/sssd-users/2014-July/001891.html
<snip> > 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=*\**)
I'm not sure what this search is supposed to do. What is the intention of this? If it is to search for any sudoHost value with a literal asterisk "*" character in it, then the search filter syntax is wrong. According to http://tools.ietf.org/html/rfc4515, if you want to use a "*" in a search filter, it must be escaped like this: \2A, so the search filter would be (sudoHost=*\2A*)
Thanks for chiming in, Rich.
Pavel, can you inspect the code and file a ticket if we have a bug?
Hi, the search is supposed to find all rules containing a wildcard in sudoHost attribute. Thanks for correcting the filter.
I filed: https://fedorahosted.org/sssd/ticket/2377
In the mean time, if you don't use wildcards you can disable the filter with: ldap_sudo_include_regexp = false in domain section of your sssd.conf.
because I can only get the search to work without it
Rowland
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 09/07/14 19:00, Rich Megginson wrote:
re: https://lists.fedorahosted.org/pipermail/sssd-users/2014-July/001891.html
<snip> > 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=*\**)
I'm not sure what this search is supposed to do. What is the intention of this? If it is to search for any sudoHost value with a literal asterisk "*" character in it, then the search filter syntax is wrong. According to http://tools.ietf.org/html/rfc4515, if you want to use a "*" in a search filter, it must be escaped like this: \2A, so the search filter would be (sudoHost=*\2A*)
because I can only get the search to work without it
Rowland
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
OK, I have done a bit more investigation and I am now of the the opinion that it is a permissions problem.
If I do this ldapsearch on the client:
ldapsearch -h dc1 -Y GSSAPI -b ou=Sudoers,dc=example,dc=com '(&(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=*[*]*))))'
I get this response:
SASL/GSSAPI authentication started SASL username: NETBOOK$@EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <ou=Sudoers,dc=example,dc=com> with scope subtree # filter: (&(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=*[*]*)))) # requesting: ALL #
# search result search: 4 result: 0 Success
# numResponses: 1
But, if I do the ldapsearch this way:
ldapsearch -x -h dc1 -b ou=Sudoers,dc=example,dc=com -D cn=Administrator,cn=Users,dc=example,dc=com -w xxxxxxxx '(&(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=*[*]*))))'
I get this response:
# extended LDIF # # LDAPv3 # base <ou=Sudoers,dc=example,dc=com> with scope subtree # filter: (&(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=*[*]*)))) # requesting: ALL #
# defaults, SUDOers, example.com dn: CN=defaults,OU=SUDOers,dc=example,dc=com objectClass: top objectClass: sudoRole cn: defaults description: Default sudoOptions go here instanceType: 4 whenCreated: 20140703100647.0Z uSNCreated: 7410 name: defaults objectGUID:: CFeHJYb9kUSpz1xbrqnrOA== objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,dc=example,dc=com sudoOption: env_reset sudoOption: mail_badpass sudoOption: secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sb in:/bin" sudoHost: ALL whenChanged: 20140710085142.0Z uSNChanged: 8889 distinguishedName: CN=defaults,OU=SUDOers,dc=example,dc=com
# rowland, SUDOers, example.com dn: CN=rowland,OU=SUDOers,dc=example,dc=com objectClass: top objectClass: sudoRole cn: rowland instanceType: 4 whenCreated: 20140703100648.0Z uSNCreated: 7412 name: rowland objectGUID:: KSCH09FZ4kmM9WIV1qxAPg== objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,dc=example,dc=com sudoUser: rowland sudoCommand: ALL sudoHost: ALL whenChanged: 20140710085009.0Z uSNChanged: 8887 distinguishedName: CN=rowland,OU=SUDOers,dc=example,dc=com
# %sudo, SUDOers, example.com dn: CN=%sudo,OU=SUDOers,dc=example,dc=com objectClass: top objectClass: sudoRole cn: %sudo instanceType: 4 whenCreated: 20140703100647.0Z uSNCreated: 7411 name: %sudo objectGUID:: 0k5Y1dUTjEG0M2UcUJww8g== objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,dc=example,dc=com sudoUser: %sudo sudoCommand: ALL sudoHost: ALL whenChanged: 20140710085009.0Z uSNChanged: 8888 distinguishedName: CN=%sudo,OU=SUDOers,dc=example,dc=com
# search result search: 2 result: 0 Success
# numResponses: 4 # numEntries: 3
Any suggest to what I check next??
Rowland
On 18/07/14 16:18, Jakub Hrozek wrote:
On Thu, Jul 10, 2014 at 11:20:10AM +0100, Rowland Penny wrote:
Any suggest to what I check next??
Sorry for the delayed reply.
Looks like an ACI problem to me, the first search binds as NETBOOK$@EXAMPLE.COM, the second as cn=Administrator,cn=Users,dc=example,dc=com _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
ER, could you please expand 'ACI' for me, I haven't a clue what you are talking about ;-)
As for the part that I did understand, from what I have read, the first search is what sssd does and does not get any results, but by searching as the Administrator( and I suppose as any user) all the rules are found.
I have since tried again on a Linux Mint 17 (aka Ubuntu 14.04) laptop with the standard sssd packages and I still cannot get sudo to work, sssd seems to check for sudo rules but does not find any:
if I examine sssd_example.com.log, I find this:
[sdap_sudo_refresh_connect_done] (0x0400): SUDO LDAP connection successful [sdap_sudo_load_sudoers_next_base] (0x0400): Searching for sudo rules with base [ou=sudoers,dc=example,dc=com] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=ThinkPad)(sudoHost=ThinkPad.example.com)(sudoHost=192.168.0.215)(sudoHost=192.168.0.0/24)(sudoHost=fe80::86a6:c8ff:fe3b:da7b)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\*)(sudoHost=*?*)(sudoHost=***)(sudoHost=*[*]*))))][ou=sudoers,dc=example,dc=com]. [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoCommand] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoHost] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoUser] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOption] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsUser] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsGroup] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotBefore] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotAfter] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOrder] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 6 [sdap_id_op_connect_done] (0x4000): caching successful connection after 2 notifies [be_run_unconditional_online_cb] (0x4000): List of unconditional online callbacks is empty, nothing to do.
would you like the entire sssd logs for the domain ?
I would like to add that sssd works for users and groups, so it it connecting to AD, it just doesn't seem to want to find any sudo rules.
I also take it that sssd & sudo work like this:
sudo rules are put into AD, sssd searches AD and pulls any rules that are relevant to the client, sssd then stores these rules in a cache, when the sudo command is run it first reads the sudo files on the client and then (provided it is set in nssswitch.conf) it reads the cache.
Rowland
On 07/18/2014 11:53 AM, Rowland Penny wrote:
On 18/07/14 16:18, Jakub Hrozek wrote:
On Thu, Jul 10, 2014 at 11:20:10AM +0100, Rowland Penny wrote:
Any suggest to what I check next??
Sorry for the delayed reply.
Looks like an ACI problem to me, the first search binds as NETBOOK$@EXAMPLE.COM, the second as cn=Administrator,cn=Users,dc=example,dc=com _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
ER, could you please expand 'ACI' for me, I haven't a clue what you are talking about ;-)
Access Control Instructions in LDAP on the server side. In one case the account has privileges to get information and in other it does not. You need to change permission on the server for the SSSD account to have permission to do the search.
As for the part that I did understand, from what I have read, the first search is what sssd does and does not get any results, but by searching as the Administrator( and I suppose as any user) all the rules are found.
I have since tried again on a Linux Mint 17 (aka Ubuntu 14.04) laptop with the standard sssd packages and I still cannot get sudo to work, sssd seems to check for sudo rules but does not find any:
if I examine sssd_example.com.log, I find this:
[sdap_sudo_refresh_connect_done] (0x0400): SUDO LDAP connection successful [sdap_sudo_load_sudoers_next_base] (0x0400): Searching for sudo rules with base [ou=sudoers,dc=example,dc=com] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=ThinkPad)(sudoHost=ThinkPad.example.com)(sudoHost=192.168.0.215)(sudoHost=192.168.0.0/24)(sudoHost=fe80::86a6:c8ff:fe3b:da7b)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\*)(sudoHost=*?*)(sudoHost=***)(sudoHost=*[*]*))))][ou=sudoers,dc=example,dc=com].
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoCommand] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoHost] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoUser] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOption] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsUser] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsGroup] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotBefore] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotAfter] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOrder] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 6 [sdap_id_op_connect_done] (0x4000): caching successful connection after 2 notifies [be_run_unconditional_online_cb] (0x4000): List of unconditional online callbacks is empty, nothing to do.
would you like the entire sssd logs for the domain ?
I would like to add that sssd works for users and groups, so it it connecting to AD, it just doesn't seem to want to find any sudo rules.
I also take it that sssd & sudo work like this:
sudo rules are put into AD, sssd searches AD and pulls any rules that are relevant to the client, sssd then stores these rules in a cache, when the sudo command is run it first reads the sudo files on the client and then (provided it is set in nssswitch.conf) it reads the cache.
Rowland _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 18/07/14 20:03, Dmitri Pal wrote:
On 07/18/2014 11:53 AM, Rowland Penny wrote:
On 18/07/14 16:18, Jakub Hrozek wrote:
On Thu, Jul 10, 2014 at 11:20:10AM +0100, Rowland Penny wrote:
Any suggest to what I check next??
Sorry for the delayed reply.
Looks like an ACI problem to me, the first search binds as NETBOOK$@EXAMPLE.COM, the second as cn=Administrator,cn=Users,dc=example,dc=com _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
ER, could you please expand 'ACI' for me, I haven't a clue what you are talking about ;-)
Access Control Instructions in LDAP on the server side. In one case the account has privileges to get information and in other it does not. You need to change permission on the server for the SSSD account to have permission to do the search.
Thanks, you have confirmed what I thought was going on, have you any idea how I can give machines the required rights in Active Directory or can you point me at a webpage that explains how to do it?
Rowland
On 07/18/2014 03:19 PM, Rowland Penny wrote:
On 18/07/14 20:03, Dmitri Pal wrote:
On 07/18/2014 11:53 AM, Rowland Penny wrote:
On 18/07/14 16:18, Jakub Hrozek wrote:
On Thu, Jul 10, 2014 at 11:20:10AM +0100, Rowland Penny wrote:
Any suggest to what I check next??
Sorry for the delayed reply.
Looks like an ACI problem to me, the first search binds as NETBOOK$@EXAMPLE.COM, the second as cn=Administrator,cn=Users,dc=example,dc=com _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
ER, could you please expand 'ACI' for me, I haven't a clue what you are talking about ;-)
Access Control Instructions in LDAP on the server side. In one case the account has privileges to get information and in other it does not. You need to change permission on the server for the SSSD account to have permission to do the search.
Thanks, you have confirmed what I thought was going on, have you any idea how I can give machines the required rights in Active Directory or can you point me at a webpage that explains how to do it?
Sorry, no. I would defer to technical gurus to chime in on Monday.
Rowland _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 18/07/14 20:50, Dmitri Pal wrote:
On 07/18/2014 03:19 PM, Rowland Penny wrote:
On 18/07/14 20:03, Dmitri Pal wrote:
On 07/18/2014 11:53 AM, Rowland Penny wrote:
On 18/07/14 16:18, Jakub Hrozek wrote:
On Thu, Jul 10, 2014 at 11:20:10AM +0100, Rowland Penny wrote:
Any suggest to what I check next??
Sorry for the delayed reply.
Looks like an ACI problem to me, the first search binds as NETBOOK$@EXAMPLE.COM, the second as cn=Administrator,cn=Users,dc=example,dc=com _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
ER, could you please expand 'ACI' for me, I haven't a clue what you are talking about ;-)
Access Control Instructions in LDAP on the server side. In one case the account has privileges to get information and in other it does not. You need to change permission on the server for the SSSD account to have permission to do the search.
Thanks, you have confirmed what I thought was going on, have you any idea how I can give machines the required rights in Active Directory or can you point me at a webpage that explains how to do it?
Sorry, no. I would defer to technical gurus to chime in on Monday.
Rowland _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
OK, I have now got sudo to work on my laptop, but the only way I could find was to add the laptop to Domain Admins. This confirms that it is a permissions problem, but I do not think adding every linux computer to Domain Admins is really a good idea.
So where do we go from here ?? will sssd & sudo work out of the box on any linux distro against AD ?
Rowland
On Sat, Jul 19, 2014 at 02:42:46PM +0100, Rowland Penny wrote:
On 18/07/14 20:50, Dmitri Pal wrote:
On 07/18/2014 03:19 PM, Rowland Penny wrote:
On 18/07/14 20:03, Dmitri Pal wrote:
On 07/18/2014 11:53 AM, Rowland Penny wrote:
On 18/07/14 16:18, Jakub Hrozek wrote:
On Thu, Jul 10, 2014 at 11:20:10AM +0100, Rowland Penny wrote: >Any suggest to what I check next?? Sorry for the delayed reply.
Looks like an ACI problem to me, the first search binds as NETBOOK$@EXAMPLE.COM, the second as cn=Administrator,cn=Users,dc=example,dc=com _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
ER, could you please expand 'ACI' for me, I haven't a clue what you are talking about ;-)
Access Control Instructions in LDAP on the server side. In one case the account has privileges to get information and in other it does not. You need to change permission on the server for the SSSD account to have permission to do the search.
Thanks, you have confirmed what I thought was going on, have you any idea how I can give machines the required rights in Active Directory or can you point me at a webpage that explains how to do it?
Sorry, no. I would defer to technical gurus to chime in on Monday.
Rowland _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
OK, I have now got sudo to work on my laptop, but the only way I could find was to add the laptop to Domain Admins. This confirms that it is a permissions problem, but I do not think adding every linux computer to Domain Admins is really a good idea.
No, it's not :-)
So where do we go from here ?? will sssd & sudo work out of the box on any linux distro against AD ?
No, because sudo is not present on the AD side out of the box. I assume you had to add the entries yourself anyway to the AD server, including extending the schema, so it really depends on how you setup the AD server.
Normally I use ADSI Edit to adit the permissions. If you right-click the sudo container in ADSI, select properties and then go to the Security Tab, do you "Authenticated users" there ? btw I'm using Windows Server 2012, not sure if the dialogs look any different in earlier versions.
Also there were a couple of questions on the subject lately so I wrote up what I did for testing here: https://jhrozek.livejournal.com/3860.html
On 21/07/14 07:03, Jakub Hrozek wrote:
On Sat, Jul 19, 2014 at 02:42:46PM +0100, Rowland Penny wrote:
On 18/07/14 20:50, Dmitri Pal wrote:
On 07/18/2014 03:19 PM, Rowland Penny wrote:
On 18/07/14 20:03, Dmitri Pal wrote:
On 07/18/2014 11:53 AM, Rowland Penny wrote:
On 18/07/14 16:18, Jakub Hrozek wrote: > On Thu, Jul 10, 2014 at 11:20:10AM +0100, Rowland Penny wrote: >> Any suggest to what I check next?? > Sorry for the delayed reply. > > Looks like an ACI problem to me, the first search binds as > NETBOOK$@EXAMPLE.COM, the second as > cn=Administrator,cn=Users,dc=example,dc=com > _______________________________________________ > sssd-users mailing list > sssd-users@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-users ER, could you please expand 'ACI' for me, I haven't a clue what you are talking about ;-)
Access Control Instructions in LDAP on the server side. In one case the account has privileges to get information and in other it does not. You need to change permission on the server for the SSSD account to have permission to do the search.
Thanks, you have confirmed what I thought was going on, have you any idea how I can give machines the required rights in Active Directory or can you point me at a webpage that explains how to do it?
Sorry, no. I would defer to technical gurus to chime in on Monday.
Rowland _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
OK, I have now got sudo to work on my laptop, but the only way I could find was to add the laptop to Domain Admins. This confirms that it is a permissions problem, but I do not think adding every linux computer to Domain Admins is really a good idea.
No, it's not :-)
So where do we go from here ?? will sssd & sudo work out of the box on any linux distro against AD ?
No, because sudo is not present on the AD side out of the box. I assume you had to add the entries yourself anyway to the AD server, including extending the schema, so it really depends on how you setup the AD
I am using a samba4 server and yes I did extend the schema and added the sudo rules, but I did ALL of this on the Debian wheezy backports server.
server.
Normally I use ADSI Edit to adit the permissions. If you right-click the sudo container in ADSI, select properties and then go to the Security Tab, do you "Authenticated users" there ? btw I'm using Windows Server 2012, not sure if the dialogs look any different in earlier versions.
So what you are saying is, to get a UNIX program to work on a UNIX machine running against a UNIX AD DC, you have to to set it up on a WINDOWS machine ??? What happens if you do not have a windows machine or if you do, you don't have ADSI Edit ??
Also there were a couple of questions on the subject lately so I wrote up what I did for testing here: https://jhrozek.livejournal.com/3860.html
Yes, I read that, amongst lots of other things, none of which said that you definitely had to get windows involved.
This is quite likely the biggest bug I personally have ever heard of ;-)
Rowland
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Mon, Jul 21, 2014 at 08:47:24AM +0100, Rowland Penny wrote:
Normally I use ADSI Edit to adit the permissions. If you right-click the sudo container in ADSI, select properties and then go to the Security Tab, do you "Authenticated users" there ? btw I'm using Windows Server 2012, not sure if the dialogs look any different in earlier versions.
So what you are saying is, to get a UNIX program to work on a UNIX machine running against a UNIX AD DC, you have to to set it up on a WINDOWS machine ??? What happens if you do not have a windows machine or if you do, you don't have ADSI Edit ??
No, but this is the first time in this thread you mention you're using Samba and not a real AD.. I know you probably mentioned Samba in some previous threads, but I forgot that, sorry.
I don't have too much experience customizing Samba permissions, but this is a good question to ask on some Samba mailing list or IRC channel.
Or maybe some of the Samba developers hanging out on this list have some answer..
On 21/07/14 11:15, Jakub Hrozek wrote:
On Mon, Jul 21, 2014 at 08:47:24AM +0100, Rowland Penny wrote:
Normally I use ADSI Edit to adit the permissions. If you right-click the sudo container in ADSI, select properties and then go to the Security Tab, do you "Authenticated users" there ? btw I'm using Windows Server 2012, not sure if the dialogs look any different in earlier versions.
So what you are saying is, to get a UNIX program to work on a UNIX machine running against a UNIX AD DC, you have to to set it up on a WINDOWS machine ??? What happens if you do not have a windows machine or if you do, you don't have ADSI Edit ??
No, but this is the first time in this thread you mention you're using Samba and not a real AD.. I know you probably mentioned Samba in some previous threads, but I forgot that, sorry.
Sorry if I didn't explicitly say I was using a samba AD DC, I didn't think it mattered as an AD server is an AD server, whether it a samba AD server or a windows AD server.
From what you posted, I have found the problem(after installing XP in a VM, installing RSAT etc), Domain computers was only being allowed to read 'OU=SUDOers'. it wasn't being allowed to read any of the children.
I now need to work out how to alter the 'nTSecurityDescriptor' attribute of OU=SUDOers ( replacing '(A;;RPLCRC;;;DC)' with '(A;CI;RPLCRC;;;DC)' ) using only linux tools ;-)
Rowland
I don't have too much experience customizing Samba permissions, but this is a good question to ask on some Samba mailing list or IRC channel.
Or maybe some of the Samba developers hanging out on this list have some answer.. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Mon, Jul 21, 2014 at 01:47:47PM +0100, Rowland Penny wrote:
On 21/07/14 11:15, Jakub Hrozek wrote:
On Mon, Jul 21, 2014 at 08:47:24AM +0100, Rowland Penny wrote:
Normally I use ADSI Edit to adit the permissions. If you right-click the sudo container in ADSI, select properties and then go to the Security Tab, do you "Authenticated users" there ? btw I'm using Windows Server 2012, not sure if the dialogs look any different in earlier versions.
So what you are saying is, to get a UNIX program to work on a UNIX machine running against a UNIX AD DC, you have to to set it up on a WINDOWS machine ??? What happens if you do not have a windows machine or if you do, you don't have ADSI Edit ??
No, but this is the first time in this thread you mention you're using Samba and not a real AD.. I know you probably mentioned Samba in some previous threads, but I forgot that, sorry.
Sorry if I didn't explicitly say I was using a samba AD DC, I didn't think it mattered as an AD server is an AD server, whether it a samba AD server or a windows AD server.
No problem.
From what you posted, I have found the problem(after installing XP in a VM, installing RSAT etc), Domain computers was only being allowed to read 'OU=SUDOers'. it wasn't being allowed to read any of the children.
I now need to work out how to alter the 'nTSecurityDescriptor' attribute of OU=SUDOers ( replacing '(A;;RPLCRC;;;DC)' with '(A;CI;RPLCRC;;;DC)' ) using only linux tools ;-)
Rowland
This would be a really nice HOWTO!
On 21/07/14 13:54, Jakub Hrozek wrote:
On Mon, Jul 21, 2014 at 01:47:47PM +0100, Rowland Penny wrote:
On 21/07/14 11:15, Jakub Hrozek wrote:
On Mon, Jul 21, 2014 at 08:47:24AM +0100, Rowland Penny wrote:
Normally I use ADSI Edit to adit the permissions. If you right-click the sudo container in ADSI, select properties and then go to the Security Tab, do you "Authenticated users" there ? btw I'm using Windows Server 2012, not sure if the dialogs look any different in earlier versions.
So what you are saying is, to get a UNIX program to work on a UNIX machine running against a UNIX AD DC, you have to to set it up on a WINDOWS machine ??? What happens if you do not have a windows machine or if you do, you don't have ADSI Edit ??
No, but this is the first time in this thread you mention you're using Samba and not a real AD.. I know you probably mentioned Samba in some previous threads, but I forgot that, sorry.
Sorry if I didn't explicitly say I was using a samba AD DC, I didn't think it mattered as an AD server is an AD server, whether it a samba AD server or a windows AD server.
No problem.
From what you posted, I have found the problem(after installing XP in a VM, installing RSAT etc), Domain computers was only being allowed to read 'OU=SUDOers'. it wasn't being allowed to read any of the children.
I now need to work out how to alter the 'nTSecurityDescriptor' attribute of OU=SUDOers ( replacing '(A;;RPLCRC;;;DC)' with '(A;CI;RPLCRC;;;DC)' ) using only linux tools ;-)
Rowland
This would be a really nice HOWTO! _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Well, changing the ACL's on a folder in AD turned out to be fairly easy, samba4 has a command for it, little or no documentation on how to use it, but that's opensource for you ;-)
I found and read this page:
http://www.netid.washington.edu/documentation/domains/sddl.aspx
This explained just how SDDL's are made up and what their constituents mean, I now just had to work out the syntax for the samba-tool command and after a few failures, this is what I came up with:
samba-tool dsacl set -H /var/lib/samba/private/sam.ldb --objectdn="OU=SUDOers,DC=example,DC=com" --sddl="(A;CI;RPLCRC;;;DC)"
The only problem that I found with that approach was, you can only add ACL's, you cannot replace them.
If a search of 'OU=SUDOers,DC=example,DC=com' shows that the ACL is already set, but is incorrect, then at the moment, you only have two options, use windows tools or use ldbedit:
ldbedit -e nano -H /var/lib/samba/private/sam.ldb -b dc=example,dc=com '(&(objectClass=organizationalUnit)(ou=sudoers))' nTSecurityDescriptor
I actually added the correct SDDL with samba-tool and then deleted the wrong one with ldbedit.
Rowland
On 03 Jul 2014, at 09:09, Teemu Keinonen Teemu.Keinonen@relex.fi 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
I’m sorry for the late reply.
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.
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$@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
For the record, the above /should/ be exactly what SSSD should be doing.
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
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Pavel Březina -
Rich Megginson -
Rowland Penny -
Teemu Keinonen