file provider with multiple kerberos realms
by Techie
Main goal is to authenticate against multiple Kerberos Realms, AD domains
without joining the Linux box to AD.
We have an AD forest with 2 trusted domains and as a result 2 kerberos
realms, 1 per domain. On RHEL5,6,7 I used pam_krb5 for authentication and
passwd/group files for the user store. This allowed me to authenticate
against AD for users in the passwd file that match the KBR5 principal. In
system-auth/password-auth I would stack pam entries for each KRB5 REALM
Parent: EXAMPLE.COM
Domain1: ADA.EXAMPLE.COM
Domain2:ADB.EXAMPLE.COM
passwd user: joe_doe
krb5 principal: joe_doe(a)ADA.EXAMPLE.COM
passwd user: joe_blow
krb5 principal: joe_blow(a)ADB.EXAMPLE.COM
system-auth
auth sufficient pam_krb5.so realm=ADA.EXAMPLE.COM use_first_pass
auth sufficient pam_krb5.so realm=ADB.EXAMPLE.COM use_first_pass
In this case either joe_doe or joe_blow can log in via AD credentials and
pam would iterate through the stacked pam_krb5 entries to locate the
matching krb5 principal
I am trying to replicate this on redhat enterprise linux 8. I am aware
pam_krb5 is not an option and that sssd is the default for this use case.
What I cannot figure out is how to authenticate against multiple Domains in
SSSD. If I define 1 domain in sssd.conf with id_provider = files. I can
authenticate fine against the single domain/kerberos5 realm.
If I add multiple domains, sssd does not iterate through them, it fails if
it does not find the user in the first domain.
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = ADA.EXAMPLE.COM,ADB.EXAMPLE.COM
[pam]
#pam_local_domains = all
[domain/ADA.EXAMPLE.COM]
id_provider = files
auth_provider=krb5
krb5_server = adadc.ada.example.com
krb5_kpasswd = adadc.ada.example.com
krb5_realm = ADA.EXAMPLE.COM
dns_discovery_domain =ADA.EXAMPLE.COM
krb5_validate = false
[domain/ADB.EXAMPLE.COM
id_provider = files
auth_provider=krb5
krb5_server = adbdc.adb.example.com
krb5_kpasswd = adbdc.adb.example.com
krb5_realm =ADB.EXAMPLE.COM
dns_discovery_domain = ADB.EXAMPLE.COM
krb5_validate = false
Is what I am attempting possible without joining AD and using the provider
of AD? I would like to avoid this at all costs.
Thanks
4 weeks
sssd-krb5, krb5_ccachedir, DIR-cache-store...
by Jostein Fossheim
We are working with several kerberos-REALMS and are trying to get our clients to store their kerberos tickets in a DIRECTORY. This seems to work nicely for clients not authenticating at login, with the following configuration set in /etc/krb5.conf.
...
[libdefaults]
...
default_ccache_name = DIR:/tmp/krb5cc_%{uid}
...
user@server:~$ klist
Ticket cache: DIR::/tmp/krb5cc_888/tkt
Default principal: user@REALM
Valid starting Expires Service principal
09/22/19 17:35:50 09/23/19 17:35:48 krbtgt/user@REALM
Each ticket is stored in a separate file.
For clients using sssd for login, I want to set up the same behavior. But when I attempt to login the system creates an "/tmp/krb5cc_${UiD}" - but here the directory don't get the excutable bit set (that is the directory get 0600-permission), and the login fails.
In the man-page from Debian-buster (sssd-version: 1.16.3), there are to settings that seems to regulate this behaviour :
krb5_ccachedir (string)
Directory to store credential caches. All the substitution sequences of krb5_ccname_template can be used here, too, except %d and %P. The directory is created as private and owned by the user, with permissions set to 0700.
Default: /tmp
krb5_ccname_template (string)
Location of the user's credential cache. Three credential cache types are currently supported: "FILE", "DIR" and "KEYRING:persistent". The cache can be specified either as TYPE:RESIDUAL, or as an absolute path, which implies the "FILE" type. In the template, the following sequences are substituted:
[...]
If the template ends with 'XXXXXX' mkstemp(3) is used to create a unique filename in a safe way.
When using KEYRING types, the only supported mechanism is "KEYRING:persistent:%U", which uses the Linux kernel keyring to store credentials on a per-UID basis. This is also the recommended choice, as it is the most secure and predictable method.
The default value for the credential cache name is sourced from the profile stored in the system wide krb5.conf configuration file in the [libdefaults] section. The option name is default_ccache_name. See krb5.conf(5)'s PARAMETER EXPANSION paragraph for additional information on the expansion format defined by krb5.conf.
NOTE: Please be aware that libkrb5 ccache expansion template from krb5.conf(5) uses different expansion sequences than SSSD.
Default: (from libkrb5)
...
I have tried to both set and unset, the two parameters in question like this:
krb5_ccachedir = /tmp/krb5cc_%U
krb5_ccname_template = DIR: %d
krb5_ccname_template = DIR:%d/krb5cc_%U_XXXXXX
But the configuration-options seems to be ignored, no matter what I do, and I have the same behavior: A non-executable directory is created and the user is unable to login.
If I set the +x bit on the directory manually as the root-user, everything works.
1 month
sssd with samba
by Edouard Guigné
Dear sssd users,
I would like to get informations about the use of sssd with samba
(centos 7, samba 4.8.3).
I need it because I configured a samba share, accessible with sssd.
The authentication is against a windows AD.
My /etc/nsswitch.cnf is configured only with sssd :
/passwd: files sss//
//shadow: files sss//
//group: files sss/
For an other purpose, I set an sftpd access also configured with sssd
against the AD.
I followed some discussions on the samba user list about samba + sssd.
I would like to understand if there are some issues with sssd and samba
4.8.3 on centos 7 ?
Or is it with next RHEL 8 ?
/The RHEL 8 documentation states this: //
////
//"Red Hat only supports running Samba as a server with the winbindd //
//service to provide domain users and groups to the local system. Due to //
//certain limitations, such as missing Windows access control list (ACL) //
//support and NT LAN Manager (NTLM) fallback, SSSD is not supported." //
////
//https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/assembly_using-samba-as-a-server_deploying-different-types-of-servers////
////
//What's confusing is that the RHEL 7 documentation says: //
////
//"Prior to Red Hat Enterprise Linux 7.1, only Winbind provided this //
//functionality. In Red Hat Enterprise Linux 7.1 and later, you no longer //
//need to run Winbind and SSSD in parallel to access SMB shares. For //
//example, accessing the Access Control Lists (ACLs) no longer requires //
//Winbind on SSSD clients." //
////
//and //
////
//"4.2.2. Determining Whether to Use SSSD or Winbind for SMB Shares //
//For most SSSD clients, using SSSD is recommended:" //
////
//and most worrisome, in my use case: //
////
//"In environments with direct Active Directory integration where the //
//clients use SSSD for general Active Directory user mappings, using //
//Winbind for the SMB ID mapping instead of SSSD can result in //
//inconsistent mapping."
/
In my case, running samba 4.8.3 with SSSD on centos 7 do I need to :
- enable and start winbind service , in conjunction to sssd ?
- or only sssd is enough with samba ?
- Do I have to fear issues in next release of sssd for the support of
samba ? especially for acls support ?/
/
A nsswitch.conf like :
passwd: files sss winbind
shadow: files sss winbind
group: files sss winbind
or
passwd: files winbind sss
shadow: files winbind sss
group: files winbind sss
Does not seem to work... I test and this is not stable.
Best Regards,
Edouard
1 month, 3 weeks
sssd: AD range retrieval fails when enumeration is enabled
by R Davies
Hi,
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
longer accurate.
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?
Many Thanks.
R.
3 months
DNS updates, chicken-and-egg problem during join?
by Andreas Hasenack
Hi,
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
send
update delete g-client1. in AAAA
send
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?
3 months, 3 weeks
realmd: socket activation and sssd.conf's services= line
by Andreas Hasenack
Hi,
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?
--- a/service/realm-sssd-config.c
+++ b/service/realm-sssd-config.c
@@ -154,8 +154,6 @@
g_strfreev (already);
/* 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);
--- a/tests/test-sssd-config.c
+++ b/tests/test-sssd-config.c
@@ -90,7 +90,7 @@
gconstpointer unused)
{
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
= 2\n";
+ 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;
gchar *output;
gboolean ret;
@@ -140,7 +140,7 @@
test_add_domain_only (Test *test,
gconstpointer unused)
{
- 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;
gchar *output;
gboolean ret;
4 months, 1 week
Are sssd's AD SASL bindings signed?
by Spike White
All,
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.
https://www.pkisolutions.com/reminder-ldap-signing-requirements-in-march-...
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
LDAPS.
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.
Spike
4 months, 1 week
Active Directory site discover with LDAPS
by Vjay
Hi,
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.
[domain/default]
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.
Regards,
//Vjay
4 months, 2 weeks