Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Using fq format [%1$s@%2$s] #6440

Closed
paulb-smartit opened this issue Nov 16, 2022 · 10 comments
Closed

Using fq format [%1$s@%2$s] #6440

paulb-smartit opened this issue Nov 16, 2022 · 10 comments

Comments

@paulb-smartit
Copy link

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 to nsswitch.conf and pam.d to use sss.

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

[sudo] [sss_fqnames_init] (0x0100): Using fq format [%1$s@%2$s].

[sssd]
config_file_version = 2
services = nss, pam, sudo
domains = LDAP
use_fully_qualified_domain_name = False
use_fully_qualified_names = False
full_name_format = %1$s
debug_level = 0xFFF0

[domain/LDAP]
cache_credentials = true
enumerate = true
use_fully_qualified_domain_name = False
use_fully_qualified_names = False

full_name_format = %1$s

# LDAP settings redacted

All help gratefully received.

OS

$ sssd --version                              
2.6.3

$ cat /etc/os-release          
NAME="Linux Mint"
VERSION="21 (Vanessa)"
ID=linuxmint
ID_LIKE="ubuntu debian"
PRETTY_NAME="Linux Mint 21"
VERSION_ID="21"
HOME_URL="https://www.linuxmint.com/"
SUPPORT_URL="https://forums.linuxmint.com/"
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
PRIVACY_POLICY_URL="https://www.linuxmint.com/"
VERSION_CODENAME=vanessa
UBUNTU_CODENAME=jammy

sssd_sudo.log

(2022-11-16 13:13:23): [sudo] [sudosrv_response_append_attr] (0x0020): [CID#1] value is not a string
********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE:
   *  [sudo] [become_user] (0x0200): Trying to become user [0][0].
   *  [sudo] [become_user] (0x0200): Already user [0].
   *  [sudo] [ldb] (0x0400): server_sort:Unable to register control with rootdse!
   *  (2022-11-16 13:13:03): [sudo] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb
   *  (2022-11-16 13:13:03): [sudo] [confdb_get_domain_internal] (0x1000): pwd_expiration_warning is -1
   *  (2022-11-16 13:13:03): [sudo] [sss_get_etc_shells] (0x0400): Found shell /bin/sh in /etc/shells
   *  (2022-11-16 13:13:03): [sudo] [sss_get_etc_shells] (0x0400): Found shell /bin/bash in /etc/shells
   *  (2022-11-16 13:13:03): [sudo] [sss_get_etc_shells] (0x0400): Found shell /usr/bin/bash in /etc/shells
   *  (2022-11-16 13:13:03): [sudo] [sss_get_etc_shells] (0x0400): Found shell /bin/rbash in /etc/shells
   *  (2022-11-16 13:13:03): [sudo] [sss_get_etc_shells] (0x0400): Found shell /usr/bin/rbash in /etc/shells
   *  (2022-11-16 13:13:03): [sudo] [sss_get_etc_shells] (0x0400): Found shell /usr/bin/sh in /etc/shells
   *  (2022-11-16 13:13:03): [sudo] [sss_get_etc_shells] (0x0400): Found shell /bin/dash in /etc/shells
   *  (2022-11-16 13:13:03): [sudo] [sss_get_etc_shells] (0x0400): Found shell /usr/bin/dash in /etc/shells
   *  (2022-11-16 13:13:03): [sudo] [sss_get_etc_shells] (0x0400): Found shell /bin/zsh in /etc/shells
   *  (2022-11-16 13:13:03): [sudo] [sss_get_etc_shells] (0x0400): Found shell /usr/bin/zsh in /etc/shells
   *  (2022-11-16 13:13:03): [sudo] [sss_names_init_from_args] (0x0100): Using re [(?P<name>[^@]+)@?(?P<domain>[^@]*$)].
   *  (2022-11-16 13:13:03): [sudo] [sss_fqnames_init] (0x0100): Using fq format [%1$s].
   *  (2022-11-16 13:13:03): [sudo] [sysdb_domain_init_internal] (0x0200): DB File for LDAP: /var/lib/sss/db/cache_LDAP.ldb
   *  (2022-11-16 13:13:03): [sudo] [sysdb_domain_init_internal] (0x0200): Timestamp file for LDAP: /var/lib/sss/db/timestamps_LDAP.ldb
   *  (2022-11-16 13:13:03): [sudo] [sysdb_ldb_connect] (0x4000): No ldb module path set in env
   *  (2022-11-16 13:13:03): [sudo] [ldb] (0x0400): asq: Unable to register control with rootdse!
   *  (2022-11-16 13:13:03): [sudo] [sysdb_ldb_connect] (0x4000): No ldb module path set in env
   *  (2022-11-16 13:13:03): [sudo] [sss_names_init_from_args] (0x0100): Using re [(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))].
   *  (2022-11-16 13:13:03): [sudo] [sss_fqnames_init] (0x0100): Using fq format [%1$s@%2$s].
   *  (2022-11-16 13:13:03): [sudo] [sss_process_init] (0x0400): Responder initialization complete (explicitly configured)
   *  (2022-11-16 13:13:03): [sudo] [sss_ncache_set_str] (0x0400): Adding [NCE/USER/LDAP/root@ldap] to negative cache permanently
   *  (2022-11-16 13:13:03): [sudo] [sss_ncache_set_str] (0x0400): Adding [NCE/GROUP/LDAP/root@ldap] to negative cache permanently
   *  (2022-11-16 13:13:03): [sudo] [sss_ncache_set_str] (0x0400): Adding [NCE/UID/0] to negative cache permanently
   *  (2022-11-16 13:13:03): [sudo] [sss_ncache_set_str] (0x0400): Adding [NCE/GID/0] to negative cache permanently
   *  (2022-11-16 13:13:03): [sudo] [sudo_process_init] (0x0400): SUDO Initialization complete
   *  (2022-11-16 13:13:03): [sudo] [sss_dp_init_done] (0x0400): Client is registered with DP
   *  (2022-11-16 13:13:03): [sudo] [sss_monitor_service_init_done] (0x0100): Got id ack and version (1) from Monitor
   *  (2022-11-16 13:13:03): [sudo] [sss_domain_get_state] (0x1000): Domain LDAP is Active
   *  (2022-11-16 13:13:03): [sudo] [cache_req_domain_new_list_from_domain_resolution_order] (0x0400): Domain resolution order list: not set
   *  (2022-11-16 13:13:03): [sudo] [sysdb_get_certmap] (0x0400): No certificate maps found.
   *  (2022-11-16 13:13:03): [sudo] [sss_ncache_set_str] (0x0400): Adding [NCE/USER/LDAP/root@ldap] to negative cache permanently
   *  (2022-11-16 13:13:03): [sudo] [sss_ncache_set_str] (0x0400): Adding [NCE/GROUP/LDAP/root@ldap] to negative cache permanently
   *  (2022-11-16 13:13:03): [sudo] [sss_ncache_set_str] (0x0400): Adding [NCE/UID/0] to negative cache permanently
   *  (2022-11-16 13:13:03): [sudo] [sss_ncache_set_str] (0x0400): Adding [NCE/GID/0] to negative cache permanently
   *  (2022-11-16 13:13:23): [sudo] [get_client_cred] (0x4000): Client [0x563a95b48380][18] creds: euid[0] egid[0] pid[12547] cmd_line['sudo'].
   *  (2022-11-16 13:13:23): [sudo] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x563a95b48380][18]
   *  (2022-11-16 13:13:23): [sudo] [accept_fd_handler] (0x0400): [CID#1] Client [cmd sudo][uid 0][0x563a95b48380][18] connected!
   *  (2022-11-16 13:13:23): [sudo] [sss_cmd_get_version] (0x0200): [CID#1] Received client version [1].
   *  (2022-11-16 13:13:23): [sudo] [sss_cmd_get_version] (0x0200): [CID#1] Offered version [1].
   *  (2022-11-16 13:13:23): [sudo] [sudosrv_cmd] (0x2000): [CID#1] Using protocol version [1]
   *  (2022-11-16 13:13:23): [sudo] [sudosrv_get_rules_send] (0x0400): [CID#1] Running initgroups for [myuser]
   *  (2022-11-16 13:13:23): [sudo] [cache_req_set_plugin] (0x2000): [CID#1] CR #0: Setting "Initgroups by name" plugin
   *  (2022-11-16 13:13:23): [sudo] [cache_req_send] (0x0400): [CID#1] CR #0: REQ_TRACE: New request [CID #1] 'Initgroups by name'
   *  (2022-11-16 13:13:23): [sudo] [cache_req_process_input] (0x0400): [CID#1] CR #0: Parsing input name [myuser]
   *  (2022-11-16 13:13:23): [sudo] [sss_parse_name_for_domains] (0x0200): [CID#1] name 'myuser' matched without domain, user is myuser
   *  (2022-11-16 13:13:23): [sudo] [cache_req_set_name] (0x0400): [CID#1] CR #0: Setting name [myuser]
   *  (2022-11-16 13:13:23): [sudo] [cache_req_select_domains] (0x0400): [CID#1] CR #0: Performing a multi-domain search
   *  (2022-11-16 13:13:23): [sudo] [cache_req_search_domains] (0x0400): [CID#1] CR #0: Search will check the cache and check the data provider
   *  (2022-11-16 13:13:23): [sudo] [cache_req_validate_domain_type] (0x2000): [CID#1] Request type POSIX-only for domain LDAP type POSIX is valid
   *  (2022-11-16 13:13:23): [sudo] [cache_req_set_domain] (0x0400): [CID#1] CR #0: Using domain [LDAP]
   *  (2022-11-16 13:13:23): [sudo] [cache_req_prepare_domain_data] (0x0400): [CID#1] CR #0: Preparing input data for domain [LDAP] rules
   *  (2022-11-16 13:13:23): [sudo] [cache_req_search_send] (0x0400): [CID#1] CR #0: Looking up myuser@ldap
   *  (2022-11-16 13:13:23): [sudo] [cache_req_search_ncache] (0x0400): [CID#1] CR #0: Checking negative cache for [myuser@ldap]
   *  (2022-11-16 13:13:23): [sudo] [sss_ncache_check_str] (0x2000): [CID#1] Checking negative cache for [NCE/USER/LDAP/myuser@ldap]
   *  (2022-11-16 13:13:23): [sudo] [cache_req_search_ncache] (0x0400): [CID#1] CR #0: [myuser@ldap] is not present in negative cache
   *  (2022-11-16 13:13:23): [sudo] [cache_req_search_cache] (0x0400): [CID#1] CR #0: Looking up [myuser@ldap] in cache
   *  (2022-11-16 13:13:23): [sudo] [cache_req_search_send] (0x0400): [CID#1] CR #0: Returning [myuser@ldap] from cache
   *  (2022-11-16 13:13:23): [sudo] [cache_req_search_ncache_filter] (0x0400): [CID#1] CR #0: This request type does not support filtering result by negative cache
   *  (2022-11-16 13:13:23): [sudo] [cache_req_create_and_add_result] (0x0400): [CID#1] CR #0: Found 19 entries in domain LDAP
   *  (2022-11-16 13:13:23): [sudo] [cache_req_done] (0x0400): [CID#1] CR #0: Finished: Success
   *  (2022-11-16 13:13:23): [sudo] [sysdb_get_sudo_user_info] (0x0400): [CID#1] Original name: myuser@ldap
   *  (2022-11-16 13:13:23): [sudo] [sysdb_get_sudo_user_info] (0x0400): [CID#1] Cased name: myuser@ldap
   *  (2022-11-16 13:13:23): [sudo] [sudosrv_query_cache] (0x0200): [CID#1] Searching sysdb with [(&(objectClass=sudoRule)(dataExpireTimestamp<=1668604403)(|(name=defaults)(sudoUser=ALL)(sudoUser=myuser@ldap)(sudoUser=#1103)(sudoUser=%access-role-sysadmin@ldap)(sudoUser=...REDACTED...)(sudoUser=%access-role-people@ldap)(sudoUser=+*)))]
   *  (2022-11-16 13:13:23): [sudo] [sudosrv_refresh_rules_send] (0x0400): [CID#1] No expired rules were found for [myuser@ldap@LDAP].
   *  (2022-11-16 13:13:23): [sudo] [sudosrv_fetch_rules] (0x0400): [CID#1] Retrieving default options for [myuser@ldap@LDAP]
   *  (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
@paulb-smartit
Copy link
Author

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 -

@paulb-smartit
Copy link
Author

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:

nsswitch.conf

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.

@alexey-tikhonov
Copy link
Member

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)?

@paulb-smartit
Copy link
Author

paulb-smartit commented Feb 21, 2023 •
edited
Loading

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

@paulb-smartit
Copy link
Author

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

@alexey-tikhonov
Copy link
Member

alexey-tikhonov commented Feb 21, 2023 •
edited
Loading

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?

@alexey-tikhonov
Copy link
Member

@pbrezina, do you think it would make sense to add a special case handling for trailing \0 at end of strings?

@pbrezina
Copy link
Member

pbrezina commented Mar 9, 2023

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?

@paulb-smartit
Copy link
Author

paulb-smartit commented Mar 9, 2023 •
edited
Loading

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.

@paulb-smartit
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@pbrezina @alexey-tikhonov @paulb-smartit