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
2 months
SSSD and PKI: capability of checking trust/validation/revocation
by Hristina Marosevic
Hello,
I am using SSSD with LDAP directory which provides public keys for each user entry to SSSD.
I am not sure if it is possible to configure SSSD not just to accept the private key (provided by the user during the login) and authenticate the user from LDAP (where his public ke is stored), but also to check the:
- trust (validation of the CA used for signing the user's certificate i.e. public key)
- validity of a user certificate with its public key (its "from" - "to" dates)
- revocation status (configuration of SSSD with CRL lists or OCSP)
or should I manage this on the LDAP side or on application level or somewhere else?
I would be grateful if you share your ideas about the possible solutions of this situation!
BR,
Hristina
9 months, 3 weeks
ldb_modify/sdap_save_group errors
by Orion Poplawski
I'm getting lots of messages like the following in our newer EL8 IPA servers:
(Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr]
(0x0080): ldb_modify failed: [No such object](32)[ldb_wait from ldb_modify
with LDB_WAIT_ALL: No such object (32)]
(Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sysdb_set_entry_attr]
(0x0080): Cannot set attrs for name=Wireless
Access(a)ad.nwra.com,cn=groups,cn=ad.nwra.com,cn=sysdb, 2 [No such file or
directory]
(Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sysdb_store_group] (0x0040):
Cache update failed: 2
(Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sdap_store_group_with_gid]
(0x0040): Could not store group Wireless Access(a)ad.nwra.com
(Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sdap_save_group] (0x0080):
Could not store group with GID: [No such file or directory]
(Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sdap_save_group] (0x0080):
Failed to save group [Wireless Access(a)ad.nwra.com]: [No such file or directory]
(Sun Feb 16 03:23:43 2020) [sssd[be[nwra.com]]] [sdap_save_groups] (0x0040):
Failed to store group 1. Ignoring.
ad.nwra.com is a trusted AD domain. Is this problematic?
Thanks.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
10 months, 3 weeks
Some more concerning messages
by Orion Poplawski
On a new EL8 IPA server:
(Tue Feb 25 10:51:49 2020) [sssd[be[nwra.com]]]
[ipa_get_ad_override_connect_done] (0x0040): dp_id_data_to_override_filter failed.
(Tue Feb 25 10:51:49 2020) [sssd[be[nwra.com]]]
[ipa_subdomain_account_got_override] (0x0040): IPA override lookup failed:
1432158283
(Tue Feb 25 10:51:49 2020) [sssd[nss]] [cache_req_common_process_dp_reply]
(0x0040): CR #285589: Data Provider Error: 3, 1432158283, The internal name
format cannot be parsed
sssd-2.2.0-19.el8.x86_64
ipa-server-4.8.0-13.module+el8.1.0+4923+c6efe041.x86_64
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
10 months, 3 weeks
Encrypted communication to DC
by Jannis Mann
Hi,
I am using sssd with out a domain join.
So I am using a binding account which is working fine.
I use our root CA to encrypt the communication to use ldaps over port 636.
I found this FAQ https://docs.pagure.org/SSSD.sssd/users/faq.html (refering
to the Authentication fails against LDAP section)
Do I understand correctly that the communication is encrypted over TLS when
I dont use ldaps?When this is the case I would not need the root ca
certificate and can avoid the problem in running into an expiring
certificate?
Just for my understanding.. How is the TLS encryption to the DC possible if
I don't have a certificate?
When I dont use ldaps is every communication encrypted or only the
transmission of the users password?
What would speak for a ssl encryption over 636 if ldap over 389 is
encrypted aswell with out certificate?
Thank you and have a nice day!
10 months, 3 weeks
auto-discovering sssd domains in upper case? (one small nit)...
by Spike White
All,
When I was first crafting my sssd.conf file, I very much attempted to make
all my sssd domains upper-case. Because in my (naive) view, an AD domain
is just a Kerberos realm (+ LDAP + nice admin screens).
As you know, Kerberos is very much case-sensitive. (Technically, AD is
not. but the convention in the /etc/krb5.conf file is to always put
Kerberos realms in upper case).
Back to sssd.
When sssd auto-discovered the other parent and child domains, it discovered
them in lower case. I was left with a mix of upper and lower-case sssd
domains. Even worse, the one local AD domain showed up twice. Once in
upper-case (explicitly defined in sssd.conf) and once in lower-case
(auto-discovered).
Eventually, I gave up and went with the (apparently recommended sssd)
convention of lower-case sssd domain names. In the domain definition, I
list the krb5_realm in upper case:
[domain/amer.example.com]
...
krb5_realm = AMER.EXAMPLE.COM
This is extremely unimportant (lower case works). But is there an option
to auto-discover sssd domains in upper case?
Spike
10 months, 4 weeks
session management by sssd (when using LDAP as an authentication and authorization server)
by Hristina Marosevic
Hello,
I installed and configured SSSD with LDAP server OUD (Oracle Unified Directory). Everything works fine so far, except for one thing which I consider as a vulnerability.
I just found out that there is a potential security hole which is the old session of a user who lost his authorization.
Generic example:
User1 has to belong to the LDAP group sshUsers which is configured as an access filter on the SSSD client in order to be authorized (after the successfull authentication) for access to the remote linux machine, where the SSSD client is installed.
User1 is a member of the LDAP group sshUsers and logs in to the remote linux machine.
After the successfull login of the User1 to the remote linux machine, its membership in the LDAP group sshUsers is removed i.e. User1 looses it authorization to access the remote linux machine.
What happens as a result is:
1. The active ssh connection od User1 to the remote linux machine which was established before he lost his authorization is still active!!
2. User1 (after he lost his authorization) can not login to the remote linux machine anymore - this is okay.
Security hole - explained in 1.
Can you please explain to me if there is a possiblity for SSSD to manage the sessions, how to do that? If this is not possible (whn using OUD) should it be proposed as a bug?
Other than that, how is session managed on the OS layer?
Thank you!
BR,
Hristina
11 months
Restricted access to MemberOf attribute in AD
by Eugene Vilensky
Greetings,
My company restricts which AD entities have access to a Domain User's
MemberOf attribute. This is done precisely as described by this
institution here:
https://itconnect.uw.edu/wares/msinf/design/arch/group-member-privacy/
Self can read own MemberOf.
We've never seen an impact on Windows clients.
However for SSSD the effect is obvious: "Domain Users" is the only Group
returned. It appears to be that SSSD uses the permissions of the Computer
account for this operation.
Is there any configurable alternative to use the User's own permissions to
resolve MemberOf on a user?
Regards,
Eugene
11 months