Closed paulb-smartit closed 1 year ago
Additional info:
$ sssctl user-checks -s=sudo myuser
user: myuser
action: acct
service: sudo
SSSD nss user lookup result:
- user name: myuser
- user id: 1103
- group id: 501
- gecos: My User
- home directory: /home/myuser
- shell: /bin/zsh
SSSD InfoPipe user lookup result:
- name: myuser
- uidNumber: 1103
- gidNumber: 501
- gecos: My User
- homeDirectory: /home/myuser
- loginShell: /bin/zsh
testing pam_acct_mgmt
pam_acct_mgmt: Success
PAM Environment:
- no env -
I've spent more time looking into how sssd works, and I am coming to the conclusion that the problem isn't with the caching or querying of data.
If I use ldbsearch to query the cache_LDAP.ldb
database, I can see all the users and groups cached in there, and understand the suffix of @ldap
now. @ldap
is an internal database representation, not a domain actually used to query LDAP with.
$ ldbsearch -H /var/lib/sss/db/cache_LDAP.ldb
So what have I got going on? Is there something in the data that fails to return a successful query? The data in OpenLDAP works with sudo-ldap
.
When using sudo
there is a very long pause, 60 seconds, and then it asks for a password. I modified the prompt in LDAP using a sudoOption
.
passprompt=[sudo-ldap] Password for %u on %H:
sudoers: files sss
But I'm only seeing a prompt of [sudo]
I suspect the sss
part is timing out and reverting to files
, hence the standard prompt. I can't see from the logs why it behaves like this, though.
Hi @paulb-opusvl,
Looks like an issue is:
* (2022-11-16 13:13:23): [sudo] [sudosrv_query_cache] (0x0200): [CID#1] Searching sysdb with [(&(objectClass=sudoRule)(name=defaults))]
* (2022-11-16 13:13:23): [sudo] [sysdb_merge_res_ts_attrs] (0x2000): [CID#1] TS cache doesn't handle this DN type, skipping
* (2022-11-16 13:13:23): [sudo] [sudosrv_fetch_rules] (0x0400): [CID#1] Returning 1 default options for [myuser@ldap@LDAP]
* (2022-11-16 13:13:23): [sudo] [sudosrv_build_response] (0x2000): [CID#1] error: [0]
* (2022-11-16 13:13:23): [sudo] [sudosrv_build_response] (0x2000): [CID#1] rules_num: [0]
* (2022-11-16 13:13:23): [sudo] [sudosrv_build_response] (0x2000): [CID#1] rule [1]/[1]
* (2022-11-16 13:13:23): [sudo] [sudosrv_response_append_attr] (0x2000): [CID#1] cn:defaults
* (2022-11-16 13:13:23): [sudo] [sudosrv_response_append_attr] (0x2000): [CID#1] objectClass:sudoRule
* (2022-11-16 13:13:23): [sudo] [sudosrv_response_append_attr] (0x0020): [CID#1] value is not a string
Could you please show output of ldbsearch
for ' [(&(objectClass=sudoRule)(name=defaults))]' filter for domain cache (in /var/lib/sss/db/cache_LDAP.ldb)?
Ok it's been a while, I appreciate you coming back. I reverted users to sudo and delivered sudoers.d
style configs.
This is from my system:
$ sudo ldbsearch -H /var/lib/sss/db/cache_LDAP.ldb '(&(objectClass=sudoRule)(name=defaults))'
asq: Unable to register control with rootdse!
# record 1
dn: name=defaults,cn=sudorules,cn=custom,cn=LDAP,cn=sysdb
cn: defaults
dataExpireTimestamp: 1668693811
entryUSN: 20220825105355Z
name: defaults
objectCategory: sudoRole
objectCategory: top
objectClass: sudoRule
originalDN: cn=defaults,ou=SUDOers,dc=opusvl
sudoOption:: aW5zdWx0cwAA
sudoOption:: c3lzbG9nPXVzZXIAAA==
sudoOption: mailto=sysadmin@opusvl.com
sudoOption:: aWdub3JlX2xvY2FsX3N1ZG9lcnMAAA==
sudoOption:: bWFpbHN1Yj1zdWRvIGFjY2VzcyByZXBvcnQgZnJvbSAlaAA=
sudoOption: pwfeedback
sudoOption: passprompt=[sudo-ldap] Password for %u on %H:
sudoOption: env_reset
distinguishedName: name=defaults,cn=sudorules,cn=custom,cn=LDAP,cn=sysdb
# returned 1 records
# 1 entries
# 0 referrals
decoded parts
sudoOption: mailsub=sudo access report from %h
sudoOption: ignore_local_sudoers
sudoOption: insults
sudoOption: syslog=user
This is didn't like:
$ sudo ldbsearch -H /var/lib/sss/db/cache_LDAP.ldb '[(&(objectClass=sudoRule)(name=defaults))]'
asq: Unable to register control with rootdse!
allocating request failed: Unable to parse search expression
Cleaner output:
$ sudo ldbsearch -H /var/lib/sss/db/cache_LDAP.ldb '(&(objectClass=sudoRule)(name=defaults))' | perl -MMIME::Base64 -MEncode=decode -n -00 -e 's/\n +//g;s/(?<=:: )(\S+)/decode("UTF-8",decode_base64($1))/eg;print'
asq: Unable to register control with rootdse!
# record 1
dn: name=defaults,cn=sudorules,cn=custom,cn=LDAP,cn=sysdb
cn: defaults
dataExpireTimestamp: 1668693811
entryUSN: 20220825105355Z
name: defaults
objectCategory: sudoRole
objectCategory: top
objectClass: sudoRule
originalDN: cn=defaults,ou=SUDOers,dc=opusvl
sudoOption:: insults
sudoOption:: syslog=user
sudoOption: mailto=sysadmin@opusvl.com
sudoOption:: ignore_local_sudoers
sudoOption:: mailsub=sudo access report from %h
sudoOption: pwfeedback
sudoOption: passprompt=[sudo-ldap] Password for %u on %H:
sudoOption: env_reset
distinguishedName: name=defaults,cn=sudorules,cn=custom,cn=LDAP,cn=sysdb
# returned 1 records
# 1 entries
# 0 referrals
It looks like the issue is with values:
sudoOption:: aW5zdWx0cwAA
sudoOption:: c3lzbG9nPXVzZXIAAA==
sudoOption:: aWdub3JlX2xvY2FsX3N1ZG9lcnMAAA==
sudoOption:: bWFpbHN1Yj1zdWRvIGFjY2VzcyByZXBvcnQgZnJvbSAlaAA=
-- there are unexpected chars that make SSSD think this is not a string.
For example:
$ echo -n 'aW5zdWx0cwAA' | base64 --decode | hexdump -C
00000000 69 6e 73 75 6c 74 73 00 00 |insults..|
-- note '00 00' at the end.
Can you check corresponding LDAP content?
@pbrezina, do you think it would make sense to add a special case handling for trailing \0 at end of strings?
Hi, I don't think so. sudoOption is supposed to be a string so I would just say it is malformed value that should be fixed. Is the value intentional? Does it work with sudoers: ldap?
Hi, I don't think so. sudoOption is supposed to be a string so I would just say it is malformed value that should be fixed. Is the value intentional? Does it work with sudoers: ldap?
Yes, 100% with sudo-ldap. I see what you mean by the trailing nulls and have no clue where they come from. They aren't there in a direct ldap query. Actually they are! I use ldapsearch and find the same result.
Exported cn=defaults to ldif, changed entries from base64 encoded to plain text. Imported and now they don't have the nulls. Just need to clear the cache and see if that resolves the issue.
I wasn't seeing the cache get updated.
Eventually, I updated all my nssswitch.conf
from ldap
to sss
and tried sudo
and it worked!
No idea where all those nulls came from, but they were not just in the cn=defaults
also in other sudoRoles
. Once I fixed them all with the export import process, things started to work.
Thank you for your help in identifying the problem
I can't get sssd working with sudo. Firstly I installed and setup ldap auth and tested with sudo-ldap. That's all good. Then I change to using
libsss-sudo
and make changes tonsswitch.conf
andpam.d
to usesss
.The log suggests that all LDAP queries get suffixed with the domain
@LDAP
and even worse@ldap@LDAP
No matter what I try I always see this in the
sssd_sudo.log
All help gratefully received.
OS
sssd_sudo.log