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
authentication to an intentionally "broken" LDAP server
by Jarett DeAngelis
Hi everyone,
I am trying to get SSSD to auth against an LDAP service provided by an IAM SaaS company that goes out of its way to make its LDAP interface as minimal as possible. All I want SSSD to do is check usernames and passwords against the service (which allows the systems in question to be secured by MFA) and grab UIDs and GIDs from two specified attributes in each user object. It seems to be able to connect fine, but it seems to choke on some missing attributes, as seen in these logs:
```
(2022-08-20 21:17:18): [be[test.ldap]] [sdap_get_generic_op_finished] (0x0400): [RID#6930] Search result: Insufficient access(50), no errmsg set
(2022-08-20 21:17:18): [be[test.ldap]] [sdap_get_generic_op_finished] (0x0040): [RID#6930] Unexpected result from ldap: Insufficient access(50), no errmsg set
* ... skipping repetitive backtrace ...
(2022-08-20 21:17:18): [be[test.ldap]] [generic_ext_search_handler] (0x0020): [RID#6930] sdap_get_generic_ext_recv request failed: [5]: Input/output error
* ... skipping repetitive backtrace ...
(2022-08-20 21:17:18): [be[test.ldap]] [sdap_get_server_opts_from_rootdse] (0x0200): [RID#6930] No known USN scheme is supported by this server!
(2022-08-20 21:17:18): [be[test.ldap]] [sdap_cli_auth_step] (0x0100): [RID#6930] expire timeout is 900
(2022-08-20 21:17:18): [be[test.ldap]] [sdap_cli_auth_step] (0x1000): [RID#6930] the connection will expire at 1661045538
(2022-08-20 21:17:18): [be[test.ldap]] [simple_bind_send] (0x0100): [RID#6930] Executing simple bind as: uid=ldap-bind,ou=users,dc=test,dc=ldap
(2022-08-20 21:17:19): [be[test.ldap]] [simple_bind_done] (0x0080): [RID#6930] ldap_parse_passwordpolicy_control failed.
(2022-08-20 21:17:19): [be[test.ldap]] [sdap_cli_connect_recv] (0x0040): [RID#6930] Unable to establish connection [1432158209]: Internal Error
* ... skipping repetitive backtrace ...
(2022-08-20 21:17:19): [be[test.ldap]] [fo_set_port_status] (0x0100): [RID#6930] Marking port 636 of server 'test.ldap' as 'not working'
(2022-08-20 21:17:19): [be[test.ldap]] [fo_set_port_status] (0x0400): [RID#6930] Marking port 636 of duplicate server 'test.ldap' as 'not working'
```
sssd.conf is as shown:
[sssd]
services = nss, pam
config_file_version = 2
domains = test.ldap
[nss]
[pam]
[domain/test.ldap]
debug_level = 7
ldap_id_use_start_tls = True
cache_credentials = True
ldap_search_base = ou=users,dc=test,dc=ldap
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
access_provider = permit
#sudo_provider = ldap
ldap_uri = ldaps://test.ldap
ldap_default_bind_dn = uid=ldap-bind,ou=users,dc=test,dc=ldap
ldap_default_authtok = some_good_password
ldap_user_uid_number = employeeNumber
ldap_user_gid_number = managerNumber
ldap_user_name = uid
ldap_tls_reqcert = allow
ldap_tls_cacert = /etc/pki/tls/cacert.crt
ldap_tls_cacertdir = /etc/pki/tls
ldap_search_timeout = 50
ldap_network_timeout = 60
#ldap_access_order = filter
#ldap_access_filter = (objectClass=inetOrgPerson)
auto_private_groups = true
Can someone help me figure out how to get around this? Open to all solutions including doing something with a server in between proxying communications between the "broken" LDAP server and our equipment.
1 year, 3 months
RFE: option to not block all permitted users and groups if an unknown domain entered...
by Spike White
sssd personnel,
When a Linux SE fat-fingers the domain name when doing a 'realm permit' or
'realm permit -g', it locks all permitted users and groups.
Even worse, it's not usually obvious from looking at the
'simple_allow_users' and 'simple_allow_groups' lines which entry is the
culprit.
Here's an example:
simple_allow_groups = amerlinuxsup(a)amer.company.com,
amerlinuxeng(a)amer.company.com, emealinuxsup(a)emea.company.com,
emealinuxeng(a)emea.company.com, apaclinuxsup(a)apac.company.com,
apaclinuxeng(a)apac.company.com, gbllinuxsuppw(a)amer.company.com,
pptsupportpac(a)amer.company.com, unv_legato_admins(a)amer.company.com,
scheduling_global(a)amer.company.com, amerlinuxengtfssupt(a)amer.company.com,
amerlnxsvcdelauttfs(a)apac.company.com, fnms_ops(a)amer.company.com,
zabbix-support(a)amer.company.com, bladelogic_linux_users(a)amer.company.com,
iasnprod(a)amer.company.com, unv_dba_login(a)amer.company.com,
engit-ebpa(a)amer.company.com
simple_allow_users = processehcprofiler(a)amer.company.com,
svc_prdautovm(a)amer.company.com, processfoglight(a)amer.company.com,
svc_prdprofoglight01(a)amer.company.com, service_ome_linux(a)amr.company.com,
svc_prdesquadscounix(a)apac.company.com, admmmikolaj(a)amer.company.com
The offending entry is 'service_ome_linux(a)amr.company.com'. The Linux SE
fat-fingered that user when doing a realm permit. Since sssd treats this
as an unknown domain (to sssd), it locks all permitted users and groups.
I've tried to submit this to my OS vendor as a bug, but they claim it's a
'feature'. Ok, but it would be nice to have a configuration option to
ignore permitted users and groups from unknown realms -- to not lock all
existing permitted users and groups.
Spike
1 year, 3 months