Only IPv4 addresses in /var/lib/sss/pubconf/kdcinfo.DOMAIN
by Brian J. Murrell
On my dual-stack network where some machines actually don't have IPv4
connectivity I am finding that whatever is writing IP addresses into
/var/lib/sss/pubconf/kdcinfo.DOMAIN is only writing the IPv4 addresses
and not the KDC's IPv6 addresses.
The result is that such an IPv6 machine cannot reach a KDC until I
remove that file. It ends up being recreated at some subsequent point
again with only the KDC's IPv4 addresses.
Is this a bug or a problem with my configuration?
Cheers,
b.
4 months, 2 weeks
'automount -m' segfaults when using sssd
by Prentice Bisbal
sssd-users,
I'm having an odd problem with autmount, that seems to be specific to
using sssd for autofs. The operating system is Springdale Open
Enterprise Linux 9.1, which is a rebuild of RHEL maintained by Princeton
University, so it should be 100% bug compatible with RHEL (and Rocky).
My configuration is using Kerberos for auth, and LDAP directory
services. When my nsswitch.conf entry for automount looks like this:
automount: sss files
Testing the configuration of automount/sssdwith 'automount -m' leads to
a segfault:
# automount -m
autofs dump map information
===========================
global options: none configured
Mount point: /p
source(s):
Segmentation fault (core dumped)
If I change nsswitch.conf to use files only or use ldap like this:
automount: files
or this:
automount files ldap
Everything works as expected. LDAP searches using ldapsearch works just
fine, and using getent to get user and group information (which is
stored in LDAP) works just fine. I've increased the debugging levels
for the relevant SSSD daemons:
# egrep '^\[|debug_level' /etc/sssd/sssd.conf
[domain/PPPL]
debug_level = 8
[sssd]
debug_level = 8
[nss]
debug_level = 8
[pam]
[autofs]
debug_level = 8
Looking in the related log files the logs for my default domain show
that it is getting information from the LDAP directory, and then it
fails saying it can't contact the LDAP server:
(2023-01-24 16:01:31): [be[default]] [sysdb_set_entry_attr] (0x0200):
[RID#6] Entry
[name=/lldap:ou\3Dauto.local\,ou\3Dmounts\,dc\3Dunix\,dc\3Dpppl\,dc\3Dgov,name=auto.master,cn=autofsmaps,cn=custom,cn=default,cn=sysdb]
has set [cache] attrs.
(2023-01-24 16:01:31): [be[default]] [sysdb_entry_attrs_diff] (0x0400):
[RID#6] Entry
[name=/pfsldap:ou\3Dauto.pfs\,ou\3Dmounts\,dc\3Dunix\,dc\3Dpppl\,dc\3Dgov,name=auto.master,cn=autofsmaps,cn=custom,cn=default,cn=sysdb]
differs, reason: ts_cache doesn't trace this type of entry.
(2023-01-24 16:01:31): [be[default]] [sysdb_set_entry_attr] (0x0200):
[RID#6] Entry
[name=/pfsldap:ou\3Dauto.pfs\,ou\3Dmounts\,dc\3Dunix\,dc\3Dpppl\,dc\3Dgov,name=auto.master,cn=autofsmaps,cn=custom,cn=default,cn=sysdb]
has set [cache] attrs.
(2023-01-24 16:01:31): [be[default]] [fo_resolve_service_send] (0x0100):
[RID#6] Trying to resolve service 'LDAP'
(2023-01-24 16:01:31): [be[default]] [get_server_status] (0x1000):
[RID#6] Status of server 'host-a.pppl.gov' is 'working'
(2023-01-24 16:01:31): [be[default]] [get_port_status] (0x1000): [RID#6]
Port status of port 389 for server 'host-a.pppl.gov' is 'not working'
Not only do the earlier log file entries show that sssd_bes actually
getting data from LDAP before it reports an error, but I can run queries
from this machine to our LDAP server with 'ldapsearch', and all the
other computers in our environment, which are running CentOS 7 or Rocky
8 using the same configuration files.
--
Prentice
10 months, 1 week
LDAP/Yubikey PIV authentication problems
by Bill McGrory
Hello,
I am looking for clues on how to debug a problem with my configuration for using LDAP and Yubikey PIV authentication.
I have successfully gotten my sssd config to recognize my ldap server, and can authenticate and log in to a user from there.
I also am prompted to enter my smartcard. my p11_chiuld.log correctly logs the presence of my key, and the certs offered up for authentication.
However, If I configure my pam common-auth so that I only use pam_sss for auth, and comment out pam_unix, I get 3 failed logging attempts, but It never asks me for a pin.
I have debug_level set to 10 for all the different sections, but I in looking at the logs I can't see any particular error that stands out.
I feel like the last relevant sssd_pam.log entries are
Fri Jan 13 08:33:48 2023) [pam] [cache_req_create_and_add_result] (0x0400): CR #5: Found 1 entries in domain closed.aerosoftinc.com
(Fri Jan 13 08:33:48 2023) [pam] [cache_req_done] (0x0400): CR #5: Finished: Success
(Fri Jan 13 08:33:48 2023) [pam] [pd_set_primary_name] (0x0400): User's primary name is mcgrory(a)closed.aerosoftinc.com
(Fri Jan 13 08:33:48 2023) [pam] [pam_initgr_cache_set] (0x2000): [mcgrory] added to PAM initgroup cache
(Fri Jan 13 08:33:48 2023) [pam] [pam_dp_send_req] (0x0100): Sending request with the following data:
(Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
(Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): domain: closed.aerosoftinc.com
(Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): user: mcgrory(a)closed.aerosoftinc.com
(Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): service: sudo
(Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): tty: /dev/pts/1
(Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): ruser: mcgrory
(Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): rhost: not set
(Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): authtok type: 0
(Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): newauthtok type: 0
(Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): priv: 0
(Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): cli_pid: 109539
(Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): logon name: mcgrory
(Fri Jan 13 08:33:48 2023) [pam] [pam_print_data] (0x0100): flags: 513
(Fri Jan 13 08:33:48 2023) [pam] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0
(Fri Jan 13 08:33:48 2023) [pam] [sbus_dispatch] (0x4000): Dispatching.
(Fri Jan 13 08:33:48 2023) [pam] [pam_dp_send_req_done] (0x0200): received: [7 (Authentication failure)][closed.aerosoftinc.com]
this is from sssd_closed.aerosoftinc.com.log
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): domain: closed.aerosoftinc.com
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): user: mcgrory(a)closed.aerosoftinc.com
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): service: sudo
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): tty: /dev/pts/1
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): ruser: mcgrory
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): rhost:
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): authtok type: 0
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): newauthtok type: 0
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): priv: 0
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): cli_pid: 109539
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): logon name: not set
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [pam_print_data] (0x0100): flags: 0
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [dp_attach_req] (0x0400): DP Request [PAM Authenticate #10]: New request. Flags [0000].
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [dp_attach_req] (0x0400): Number of active DP request: 1
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [sss_domain_get_state] (0x1000): Domain closed.aerosoftinc.com is Active
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [dp_req_done] (0x0400): DP Request [PAM Authenticate #10]: Request handler finished [0]: Success
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [_dp_req_recv] (0x0400): DP Request [PAM Authenticate #10]: Receiving request data.
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [dp_req_destructor] (0x0400): DP Request [PAM Authenticate #10]: Request removed.
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [dp_req_destructor] (0x0400): Number of active DP request: 0
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [dp_method_enabled] (0x0400): Target selinux is not configured
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [sbus_issue_request_done] (0x0400): sssd.dataprovider.pamHandler: Success
(Fri Jan 13 08:33:48 2023) [be[closed.aerosoftinc.com]] [sbus_dispatch] (0x4000): Dispatching.
I see no evidence in that log of failure, but I'm not sure what I'm looking for?
my sssd.conf file is as follows
[sssd]
domains = closed.aerosoftinc.com
debug_level = 10
[pam]
pam_cert_auth = true
pam_verbosity = 3
pam_cert_db_path = /etc/sssd/pki/aerosoft_ca.pem
debug_level = 10
[domain/closed.aerosoftinc.com]
debug_level = 10
id_provider = ldap
selinux_provider = none
auth_provider = ldap
ldap_uri = ldaps://backup.closed.aerosoftinc.com
cache_credentials = false
ldap_search_base = dc=closed,dc=aerosoftinc,dc=com
[certmap/closed.aerosoftinc.com/main]
matchrule = <ISSUER>^CN=AeroSoft CA 2,O=AeroSoft Inc,L=Blacksburg,ST=Virginia,C=US$
maprule = (gecos={subject_dn})
domains = closed.aerosoftinc.com
10 months, 4 weeks
Ensure to start a systemd service after users are available
by Ronald Wimmer
Hi,
We have got a systemd service unit file that uses a user that comes from FreeIPA. However, the user is not available when the service tries to start.
Adding
after=sssd.service nss-user-lookup.target
seems not to be sufficient. What's the right way to go?
Cheers,
Ronald
10 months, 4 weeks
Does sssd support direct integration to AzureAD?
by Spike White
All,
Our org uses sssd for direct integration to our corp AD forest, which has
the std MS schema extension (RFC 2307bis IIRC).
Currently, we have some Windows builds running in the Azure cloud,
integrated via AzureAD. I'm not a Windows engineer, so I don't know the
details of this Windows-based user authentication. Other than it works.
Does sssd support direct integration to AzureAD?
I read this with great interest:
https://research.redhat.com/blog/engineering_project/integrate-sssd-with-...
So if sssd supports this, any sssd config changes required for AzureAD?
Spike
11 months
filter_users using user id
by Francois Rigault
Greetings,
we run some podman containers that come with their own local users, such as this one:
ironic-inspector:x:42461:42461::/var/lib/ironic-inspector:/usr/sbin/nologin
when running a top on the server, top tries to resolve the user name for that id and fails, however there is still a BE_REQ_USER request sent:
(2022-12-30 22:42:33): [be[MY.DOMAIN.NET]] [dp_get_account_info_send] (0x0200): Got request for [0x1][BE_REQ_USER][idnumber=42461]
I would hope to get rid of these requests against the domain.
unfortunately in MY.DOMAIN.NET there are uids below and above this number, so I cannot rely on the "min_id" parameter to filter users.
I would like to know if it is possible to support using user ids in the [nss] filter_users to prevent those user requests to the domain, or if anyone has any other suggestion.
I increased the entry_negative_timeout to reduce the number of queries, but filtering them out entirely would be even better.
Thank you!
11 months
