When enumeration is enabled (required due to legacy application), and where
a group has > 1500 members, and AD's MaxValRange is at the default 1500,
then sssd fails to show more than 1500 group members. Group lookups are no
A further interesting aspect is that if the sssd cache is expired (sssctl
cache-expiry -E), then the correct group membership is shown until such
time as enumeration is processed again (i.e. at most
ldap_enumeration_refresh_timeout + memcache_timeout)
src/providers/ldap/sdap.c's sdap_parse_entry() states:
/* This attribute contained range values and needs more to
> * be retrieved
> /* TODO: return the set of attributes that need additional retrieval
> * For now, we'll continue below and treat it as regular values.
As enumeration is enabled the subsequent ASQ/deref work is never
undertaken. As such sssd only ever processes the initial range retrieved
members (0-1499) (NB that nested groups members are evaluated).
We have looked at the relevant source code, but can't find a way to trigger
Attribute Scope Queries (ASQ)/deref. Indeed, no manner of sssd
configuration settings (other than disabling enumeration - which we sadly
cannot do) appears to change this behaviour. Increasing MaxValRange on AD
defeats the purpose of having MaxValRange.
Has anyone run into this before? Or, should I raise a new issue?
I'm verifying under which conditions sssd will perform successful dns
updates on a DNS server backed by AD.
In this scenario, I have a standalone computer, that has an IP
obviously, but no DNS record yet. My goal was to have the join process
also add a DNS record for this computer.
After tracing calls to nsupdate, it looks like what sssd does is use
the output of `hostname -f`, and I don't see a fault with that
reasoning, except that to have that return an fqdn I need either to be
in DNS already, or hack /etc/hosts. Otherwise, it sends the short name
with a dot suffix, and that won't be accepted:
update delete g-client1. in A
update add g-client1. 3600 in A 10.51.0.8
update delete g-client1. in AAAA
I was wondering if sssd couldn't assume that the domain part is the
same as the realm? I understand there might be many considerations
here, like multiple domains, forests, etc, and maybe that's why this
isn't done. But perhaps there is a way to have the simple case work?
Or is there a config option I missed?
The other trick I see is to set the hostname to the fqdn, so that
`hostname` returns the full thing. It's not technically correct I
suppose, but gets the job done. Is that what people also do?
This is more of a realmd question than sssd, but closely related.
Debian and Ubuntu defaulted to socket activated systemd services for
all the sssd-* daemons. So they are started on demand.
realmd currently always adds a "services = nss, pam" line (or augments
it if it's there already). sssd will then start nss and pam, but so
will systemd, and that creates a (apparently harmless) conflict and
logs errors to the logs.
I don't know if there is a way for realmd to detect this scenario and
not add that services line, or if there should be a command-line
option for it? Or maybe something in realm-<distro>.conf even?
At the moment I'm just disabling adding the services line. Is this too horrible?
@@ -154,8 +154,6 @@
/* Setup a default sssd section */
- if (!realm_ini_config_have (config, "section", "services"))
- realm_ini_config_set (config, "sssd", "services", "nss, pam", NULL);
if (!realm_ini_config_have (config, "sssd", "config_file_version"))
realm_ini_config_set (config, "sssd", "config_file_version", "2", NULL);
@@ -90,7 +90,7 @@
const gchar *data = "[domain/one]\nval=1\n[sssd]\ndomains=one";
- const gchar *check = "[domain/one]\nval=1\n[sssd]\ndomains = one,
two\nconfig_file_version = 2\nservices = nss, pam\n\n[domain/two]\ndos
+ const gchar *check = "[domain/one]\nval=1\n[sssd]\ndomains = one,
two\nconfig_file_version = 2\n\n[domain/two]\ndos = 2\n";
GError *error = NULL;
@@ -140,7 +140,7 @@
test_add_domain_only (Test *test,
- const gchar *check = "\n[sssd]\ndomains = two\nconfig_file_version
= 2\nservices = nss, pam\n\n[domain/two]\ndos = 2\n";
+ const gchar *check = "\n[sssd]\ndomains = two\nconfig_file_version
= 2\n\n[domain/two]\ndos = 2\n";
GError *error = NULL;
I apologize if this has been covered already. But this was just brought up
by our cybersecurity team. They plan to disable "deprecated protocols".
By that, they mean simple LDAP binding to AD's LDAP port. Because of
passing content in clear text.
They flagged our Linux AD connections (using sssd), which are using SASL
binding. The usual sssd stuff:
- adcli join,
- /etc/krb5.keytab file,
- ldap_sasl_authid = <machine account>
to AD's LDAP port and the LDAP GC port.
Flagging those connections is a mistake; these connections are encrypted.
But cybersecurity is asking -- are the question "are these connections
signed?". I don't know the answer to that. If not, is there a simple
parameter that will allow sssd to sign these connections. Or is "signing"
a SASL binding a characteristic of the MS-Specific SASL binding (MS-SPNG)?
BTW, we use a couple of AD integration clients for Linux. sssd can satisfy
95% of the use cases, but there's a couple of use cases that sssd can't
do. For that, we have to use the older (commercial) product. That older
commercial product does *not* have any support to run SASL binding over
So why I realize that I could technically have sssd run its SASL bindings
over LDAPS -- that other client can't. So I'm not really investigating
SASL bindings over LDAPS.
We are trying to use Active Directory site discovery feature for our SSSD configurations. Our Domain Controllers are running on Windows 2016 / 2019 OS. We are not joining our Linux machines to AD Domain and use following sssd domain configurations.
auth_provider = krb5
cache_credentials = True
chpass_provider = krb5
dns_discovery_domain = NORWAY._sites.AD.MYDOMAIN.COM
debug_level = 7
enumerate = False
id_provider = ldap
krb5_realm = AD.MYDOMAIN.COM
ldap_default_authtok = xxxx
ldap_default_authtok_type = obfuscated_password
ldap_default_bind_dn = xxxx
ldap_schema = ad
ldap_search_base = ou=base,dc=ad,dc=mydomain,dc=com
use_fully_qualified_names = False
ldap_id_mapping = True
default_shell = /bin/bash
ldap_tls_cacertdir = /etc/openldap/certs
ldap_user_fullname = displayName
ldap_user_gecos = displayName
ldap_user_objectsid = objectSid
ldap_group_objectsid = objectSid
ldap_use_tokengroups = False
ignore_group_members = true
Here with site discovery, it is able to find the nearest domain controller but it is trying to connect with LDAP server on port 389. Our domain controllers are only allowing connections on port 636 so the requests from linux servers are getting rejected.
If I directly configure domain controller names in ldap_uri settings like below and remove site discover configurations, everything is working fine.
ldap_uri = ldaps://mydc.mydomain.com
But we don't want to hard code our domain controllers in configurations. Is there a way to use AD site discovery feature with ldaps?
Thanks for your time.