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.
7 months, 1 week
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
8 months, 1 week
Enumerate users from external group from AD trust
by Bolke de Bruin
Hello,
I have sssd 1.13.00 working against FreeIPA 4.2 domain. This domain has a trust relationship with a active directory domain.
One of the systems we are using requires to enumerate all users in groups by (unfortunate) design (Apache Ranger). This is done by using
“getent group”. During this enumeration the full user list for a group that has a nested external member group* is not always returned so we thought to
add “getent group mygroup” in order to get more details. Unfortunately this does not seem to work consistently: sometimes this gives information sometimes it does not:
[root@master centos]# getent group ad_users
ad_users:*:1950000004:
[root@master centos]# id bolke(a)ad.local
UID=1796201107(bolke(a)ad.local) GID=1796201107(bolke(a)ad.local) groepen=1796201107(bolke(a)ad.local),1796200513(domain users@ad.local),1796201108(test(a)ad.local)
[root@master centos]# getent group ad_users
ad_users:*:1950000004:bolke@ad.local <mailto:bolke@ad.local>
If I clear the cache (sss_cache -E) the entry is gone again:
[root@master centos]# getent group ad_users
ad_users:*:1950000004:
My question is how do I get sssd to enumerate *all users* in a group consistently?
Thanks!
Bolke
* https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-g...
1 year, 7 months
Group disappears from users / no group name gets resolved
by Jamal Mahmoud
We've been experiencing an intermittent issue relating to SSSD v1.15.2, we are running CentOS7.4 on our workstations. We use SSSD to communicate with our Active Directory to pull users for auth. The majority of users have a certain group set as their primary group and some departments have it as an additional group. Most of the time this group works fine on all workstations but sometimes we will run into an issue where a user can no longer access the privileges attained from the group. For users who have it set as primary, the id command returns a gid without the name and for users who have it as an additional group, it doesn't appear at all. I've managed to capture output from sssd services and there are a few interesting lines that I thought I should share with you as I don't understand what they mean. I should add that when this error occurs, restarting the sssd.service usually works, if not, sss_cache -E works, and if that doesn't work, removing the workstation from the realm, de
leting the sssd db and rejoining seems to be the final trick that works.
Regarding the logs, the symptoms I noted are below:
1. getent group *mygroup* returns nothing
2. id user returns a gid without a resolved group name (if it is a primary group)
3. I had to leave the realm, delete the db and rejoin to get sssd to work properly again.
in sssd_nss.log i found this entry:
(Wed Aug 21 16:22:45 2019) [sssd[nss]] [nss_get_grent] (0x0040): Incomplete group object for group(a)domain.com[0]! Skipping
and in the sssd_domain.com.log:
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_split_members] (0x4000): [CN=USER,OU=IT Privileged accounts,DC=domain,DC=com] is unknown object
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_process_send] (0x0400): More members were missing than the deref threshold
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_process_send] (0x2000): Looking up 11/224 members of group [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com]
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_process_send] (0x2000): Dereferencing members of group [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com]
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_deref_search_send] (0x2000): Server supports ASQ
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_asq_search_send] (0x0400): Dereferencing entry [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com] using ASQ
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_print_server] (0x2000): Searching XXX.XXX.XXX.XXX:389
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_get_generic_ext_send] (0x0400): WARNING: Disabling paging because scope is set to base.
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [no filter][CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com].
I've redacted the entries but I'm sure you can get the jist of whats happening here hopefully. If there is anything else you need, please do not hesitate to ask! If these logs don't point to anything could you maybe provide some advice on what to look for when parsing?
Thanks,
Jamal
1 year, 8 months
SSSD strangeness
by simonc99＠hotmail.com
Hi All
We've got SSSD 1.13.0 installed as part of a Centos 7.2.1511 installation.
We've used realmd to join the host concerned to our 2008R2 AD system. This went really well, and consequently we've been using SSSD to provide login services and kerberos integration for our fairly large hadoop system.
The authconfig that's implicitly run as part of realmd produces the following sssd.conf:
[sssd]
domains = <joined domain>
config_file_version = 2
services = nss, pam
[pam]
debug_level = 0x0080
[nss]
timeout = 20
force_timeout = 600
debug_level = 0x0080
[domain/<joined domain>]
ad_domain = <joined domain>
krb5_realm = <JOINED DOMAIN>
realmd_tags = manages-system joined-with-samba
cache_credentials = true
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = <AD group allowing logins>
krb5_use_kdc_info = False
entry_cache_timeout = 300
debug_level = 0x0080
ad_server = <active directory server>
As I've said - this works really well. We did have some stability issues initially, but they've been fixed by defining the 'ad_server' rather than using autodiscovery.
Logins work fine, kerberos TGTs are issued on login, and password changes are honoured correctly.
However, in general day to day use, we have noticed a few anomalies, that we just can't track down.
Firstly (this has happened a few times), a user will change their AD password (via a Windows PC).
Subsequent logins - sometimes with specific client software - fail with
pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<remote PC name> user=<username>
pam_sss(sshd:auth): received for user <username>: 17 (failure setting user credentials)
So in this example, the person concerned has changed their AD password. Further attempts to access this system via SSH work fine. However, using SFTP doesn't work (the above is output into /var/log/secure).
There are no local controls on sftp logins, and the user concerned was working fine (using both sftp and ssh) until they updated their password.
There is no separate sftp daemon running, and it only affects one individual currently (but we have seen some very similar instances before)
The second issue we have is around phantom groups in AD.
Hadoop uses an id -Gn command to see group membership for authorisation.
With some users - we've seen 6 currently - we see certain groups failing to be looked up:
id -Gn <username>
id: cannot find name for group ID xxxxyyyyy
<group name> <group name> <group name> <group name> <etc...>
The xxxxyyyyy indicates:
xxxx = hashed realm name
yyyyy = RID from group in AD
We can't find any group with that number on the AD side!
We can work around this by adding a local group (into /etc/group) for the GIDs affected. This means the id -Gn runs correctly, and the hadoop namenode can function correctly - but this is a workaround and we'd like to get to the bottom of the issue.
Rather than flooding this post now with logfiles, just thought I'd see if this looked familiar to anyone. Happy to upload any logs, amend logging levels, etc.
Many thanks
Simon
1 year, 8 months
AD user is granted access when it should be denied
by Emil Petersson
Hi,
I am running sssd-1.16.4-21.el7.x86_64 (from CR repo) on a CentOS 7 client. I authenticate to AD 2016, and control access to servers using GPO. For some reason, a completely unprivileged user in AD is allowed to login, and I'd like to understand why.
Here's a sanitized sssd.conf:
[sssd]
domains = prd.domain.com
config_file_version = 2
services = nss, pam, sudo
full_name_format = %1$s
default_domain_suffix = prd.domain.com
[domain/prd.domain.com]
debug_level = 9
ad_domain = prd.domain.com
ad_site = XX1
ad_server = dc000.prd.domain.com, dc001.prd.domain.com
krb5_realm = PRD.DOMAIN.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = false
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = true
use_fully_qualified_names = True
fallback_homedir = /home/%u
access_provider = ad
ldap_sudo_search_base = DC=domain,DC=com
entry_cache_sudo_timeout = 10
enumerate = true
dyndns_update = false
ad_gpo_access_control = enforcing
ldap_idmap_default_domain_sid = S-1-5-21-6607581186-1994368826-2594857426
ldap_idmap_default_domain = prd.domain.com
ad_gpo_implicit_deny = true
auto_private_groups = true
ad_gpo_ignore_unreadable = true
When I try to SSH to the client using my unprivileged user, I am getting the following output from the SSSD debug:
[sysdb_gpo_get_gpo_result_setting] (0x0400): key [SeDenyRemoteInteractiveLogonRight] value [*S-1-5-32-546]
[ad_gpo_access_check] (0x0400): RESULTANT POLICY:
[ad_gpo_access_check] (0x0400): gpo_map_type: Remote Interactive
[ad_gpo_access_check] (0x0400): allowed_size = 0
[ad_gpo_access_check] (0x0400): denied_size = 1
[ad_gpo_access_check] (0x0400): denied_sids[0] = S-1-5-32-546
... snip ...
[ad_gpo_access_check] (0x0400): CURRENT USER:
[ad_gpo_access_check] (0x0400): user_sid = S-1-5-21-6607581186-1994368826-2594857426-2570
[ad_gpo_access_check] (0x0400): group_sids[0] = S-1-5-21-6607581186-1994368826-2594857426-513
[ad_gpo_access_check] (0x0400): group_sids[1] = S-1-5-11
[ad_gpo_access_check] (0x0400): POLICY DECISION:
[ad_gpo_access_check] (0x0400): access_granted = 1
[ad_gpo_access_check] (0x0400): access_denied = 0
[ad_gpo_access_done] (0x0400): GPO-based access control successful.
I'm trying to understand why this user is being granted access. I find it especially confusing as there is clearly one deny sid and no allow sids detected. The wanted behaviour is that the user should be denied access as long as I've not explicitly allowed it in AD.
Thanks!
1 year, 9 months
Question concerning SSH key attributes
by Lawrence Kearney
A question concerning the following SSSD directives:
ldap_user_ssh_public_key =
ldap_host_ssh_public_key =
Both default to "sshPublicKey" values, but other than the obvious stated
use cases (in the directive names and man file entries) I feel I'm missing
something concerning the " ldap_host_ssh_public_key" directive.
For example, using the default configuration, the SSSD pulls down the
public key(s) stored for a user stored in the " sshPublicKey" attribute
using the "/usr/bin/sss_ssh_authorizedkeys" utility. to facilitate access
to a predetermined set of hosts.
What is the use case for the " ldap_host_ssh_public_key" directive? Is it
somehow used to store the public Key for a particular host (and why?) and
does it have any relationship to the "/usr/bin/sss_ssh_knownhostsproxy"
utility used to centralise (and distribute?) host keys?
Any info would be most useful and as always, thank you!
-- lawrence
--
Lawrence Kearney
1 year, 9 months
Allow me to introduce my situation….
by Spike White
All,
In recent postings, there’s been some (quite correct!) inferences about my
situation. Let me dispel any confusion, so you’re aware of my perspective.
I work for a Fortune 500 company in their IT department. Our company and
team has done Linux and UNIX AD integration using 2 ½ commercial products
for over 12 years now. (that third product was used only in a very limited
scope).
Our team has oversight for about 30,000 Linux servers – 17K of them that
are AD-integrated and 13K in the process of getting there.
So, my team and our server support organization has a wealth of experience
with the Linux client configurations of AD integration. We know our
company incident procedures and that escalation process. Thus, I can say
with confidence (for instance) that Linux sysadmins are engaged in the
infrequent occurrence that AD integration is bulloxed on a particular Linux
server.
So, while we have a wealth of experience in AD/LDAP Linux and app
integration, we are frankly newbies to sssd. I fully admit to my
inexperience in sssd configuration and setup. However, I have been using
it and evaluating it for almost a year. I have it working on RHEL7, RHEL8
and (just last week) RHEL6.
I have gone through all anticipated test cases and – except for one totally
obscure edge case -- sssd appears like it can do everything the commercial
AD integration products can do. I say that – although I have two open sssd
cases with our OS vendor.
1. One has been discussed already on this forum – “realm permit”
segfaulting (but only on RHEL8). Our OS vendor has provided a work-around
for this.
2. I believe the second bug is not a “bug” at all – but it’s due to
my lack of understanding of AD and my inexperience with sssd. I’m
currently working that with our OS vendor as well.
Incidentally, if it appears that I’m singularly focused on AD – that’s
because I am. That’s all my company uses for its back-end authentication
mechanism. I’m also singularly focused on RHEL and RHEL-derived Linux
servers, for similar reasons.
Thus, when I suggest an RFE, I’m speaking from my perspective only and my
company’s Linux perspective. I fully realize that other companies have
different escalation policies, different authentication back-ends and
different situations. I fully realize that any RFE I suggest would be
half-baked (at best) – if accepted, it would surely be re-written to be
more generic and useful for a larger target audience.
Spike
1 year, 10 months
Offline caching of group names and memberships?
by Spike White
All,
Our cybersecurity team doesn’t allow Linux sysadmins to directly log in as
root. (violates accountability, auditability and traceability). We log in
with an ADM account, which is then eligible to become root via ‘sudo su –‘.
That is, all members of a particular group are allowed to sudo to root.
This is preferred because with modern sudo versions all sudo sessions are
session-logged.
Anyway, if I log in with my ADM account and someone shuts down sssd, it no
longer knows what groups I’m in. That is, the session is still there – but
it cannot look up the group names.
[admspike_white@zzzdmsdev06 ~]$ id
uid=2025431 gid=1002 groups=1002,2284295
Because the sudo privs are based on group name, it doesn’t allow Linux
sysadmins to become root and thus start sssd.
Is there a way to cache those group names and memberships? Say with nscd?
So that if sssd is (temporarily) shut down, we can become root and start up?
Obviously, we can go look up the root password for the particular server –
but that’s a painful portal. It’d be better if we could cache group names
and memberships, if sssd is temporarily down or offline.
(We have other AD integration products that have this “offline caching”
feature that can enabled or disabled.)
Spike
1 year, 10 months
autofs with samba AD
by wipe＠mailbox.org
Hello list,
I'm trying to setup sssd to access automounter rules stored on an AD (samba 4.7.6).
I followed the instructions on this site, however it doesn't work for me.
https://ovalousek.wordpress.com/2015/08/03/autofs/
In the sssd_logfile I see, that the "auto.master" map is found by sssd within the ldap search path.
However, the reference to the auto.home and the corresponding user mounts does not seem to be found.
Using sssd to authenticate against Active Directory works well.
Any ideas what's going wrong here? Thanks for looking in this issue!
OS: Ubuntu 18.04.3 LTS
sssd 1.16.1-1ubuntu1.4
sssd-ad 1.16.1-1ubuntu1.4
sssd-ad-common 1.16.1-1ubuntu1.4
sssd-common 1.16.1-1ubuntu1.4
sssd-dbus 1.16.1-1ubuntu1.4
sssd-ipa 1.16.1-1ubuntu1.4
sssd-krb5 1.16.1-1ubuntu1.4
sssd-krb5-common 1.16.1-1ubuntu1.4
sssd-ldap 1.16.1-1ubuntu1.4
sssd-proxy 1.16.1-1ubuntu1.4
sssd-tools 1.16.1-1ubuntu1.4
Here is the configuration. Additionally, I attached logfiles with log_level 9
****sssd.conf****
[sssd]
domains = info.privat
config_file_version = 2
services = nss, pam, autofs
[pam]
[nss]
[autofs]
[domain/info.privat]
debug_level = 5
ad_server = tfaddc2.info.privat
access_provider = ad
auth_provider = ad
krb5_realm = INFO.PRIVAT
cache_credentials = True
id_provider = ad
autofs_provider = ad
ldap_autofs_entry_key = cn
ldap_autofs_entry_object_class = nisObject
ldap_autofs_entry_value = nisMapEntry
ldap_autofs_map_name = nisMapName
ldap_autofs_map_object_class = nisMap
ldap_autofs_search_base = ou=automount,dc=info,dc=privat
nsswitch.conf
automount: files sss
****AD****
dn: OU=automount,DC=info,DC=privat
objectClass: top
objectClass: organizationalUnit
ou: automount
name: automount
dn: CN=auto.master,OU=automount,DC=info,DC=privat
objectClass: top
objectClass: nisMap
cn: auto.master
name: auto.master
objectCategory: CN=NisMap,CN=Schema,CN=Configuration,DC=info,DC=privat
nisMapName: auto.master
dn: CN=auto.home,OU=automount,DC=info,DC=privat
objectClass: top
objectClass: nisMap
cn: auto.home
name: auto.home
objectCategory: CN=NisMap,CN=Schema,CN=Configuration,DC=info,DC=privat
nisMapName: auto.home
dn: CN=/home/,CN=auto.master,OU=automount,DC=info,DC=privat
objectClass: top
objectClass: nisObject
objectCategory: CN=NisObject,CN=Schema,CN=Configuration,DC=info,DC=privat
nisMapName: auto.master
cn: /home/
name: /home/
nisMapEntry: auto.home
dn: CN=user1,CN=auto.home,OU=automount,DC=info,DC=privat
objectClass: top
objectClass: nisObject
objectCategory: CN=NisObject,CN=Schema,CN=Configuration,DC=info,DC=privat
nisMapName: auto.home
nisMapEntry: -fstype=nfsv4,nosuid,rw,dir_index,user_xattr,proto=tcp,port=2049 server:/export/lra/user/user1
cn: user1
name: user1
1 year, 10 months
