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.
4 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
5 months
Is there an RFC or detailed design document describing SSSD's ID Mapping algorithm?
by Jeff Thornsen
The reason I ask is because I use a bunch of storage appliances that offer Secure-NFS (NETAPP, EMC UNITY, etc.), but they only support NIS, IDMU, RFC2307, and RFC2307bis style Identity Mapping, all of which require manual assignment of UID/GID numbers to objects in LDAP, which is untenable for large environments. Microsoft even removed Unix Attribute editor from their LDAP GUI for the RFC2307 attributes in Windows Server 2016 to push people away from using rfc2307.
I would like to be able to provide a link to an RFC or design document describing the SSSD ID Mapping algorithm so that these 3rd party vendors can incorporate an identical identity mapping algorithm into their products, so that I can use their Secure-NFS product in conjunction with sssd and have the uid and gid numbers match up with the other Linux hosts in our environment.
1 year, 3 months
Unreadable GPOs should not be logged as a critical failure
by Gordon Messmer
We've recently started receiving a lot of complaints from users about
broadcast messages of the form:
Message from syslogd@hostname at Dec 4 09:08:35 ...
sssd[be[domain.lan]]:Group Policy Container with DN
[cn={66062A26-FA18-4C56-A7E1-B22209856319},cn=policies,cn=system,DC=domain,DC=lan]
is unreadable or has unreadable or missing attributes. In order to fix
this make sure that this AD object has following attributes readable:
nTSecurityDescriptor, cn, gPCFileSysPath, gPCMachineExtensionNames,
gPCFunctionalityVersion, flags. Alternatively if you do not have access
to the server or can not change permissions on this object, you can use
option ad_gpo_ignore_unreadable = True which will skip this GPO.See 'man
ad_gpo_ignore_unreadable for details.'
We've reviewed the AD object with that DN and determined that they are
scoped to specific sets of workstations using AD groups, such as "Domain
Laptops". As far as we can tell, this is entirely normal, and there's
no reason to log an error, much less broadcast a message to every open
terminal every time GPOs are processed.
I'm aware of the ad_gpo_ignore_unreadable setting, but the default seems
to be the wrong behavior, and I'd like to suggest changing that.
1 year, 3 months
Re: How do new LDAP security recommendations from MS affect sssd clients?
by Chris P.
Just wondering if there is any more news regarding the patch for sssd to
work with the new MS requirements?
Curerrently I'm being notified that ALL linux servers are reporting this in
the AD logs:
"...client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind
without requesting signing (integrity verification), or performed a simple
bind over a clear text (non-SSL/TLS-encrypted) LDAP connection..."
We are planning to test a sssd client with a patched AD server to see if
this will break AD auth on our sssd clients, but wanted to see if a patch
for sssd has been made available anywhere to use ldaps or ldap with sssd.
Thanks,
Chris
1 year, 4 months
Pros/cons of access_provider=ad + access.conf file vs access_provider=simple?
by Spike White
Sssd experts,
We have an AD-based sssd configuration that is working. For RHEL6, 7 and 8.
We've done thorough lab testing + pilot projects. All good (with certain
RHEL6 restrictions).
Currently, we're using access_provider = simple, with the appropriate
simple_allow_groups and simple_allow_users lines in /etc/sssd/sssd.conf.
Works fine.
A reviewer mentioned we should be using access_provider = ad +
/etc/security/access.conf file to restrict access. (We have pam_access.so
in our pam stack already, to disallow direct root login and other limited
uses.)
Obviously that second approach would work too.
The claim is the first approach would allow in AD accounts with expired
passwords and locked accounts. Whereas the second approach would not.
I'm attempting to test this claim -- I have an account I can lock easily.
But does anyone have any best practices for access_provider?
The advantage of this first approach is that it's already coded and
thoroughly tested. The pilot projects use this.
The one advantage of the second approach that I'm certain of is that RHEL6
does not have a realm permit command. So to permit a user or group in
RHEL6 using the first approach is different between RHEL6 and 7/8. (To me,
that's not huge.)
Spike
1 year, 4 months
Re: How do new LDAP security recommendations from MS affect sssd clients?
by Gary Molenkamp
> I'm currently working on patches to allow LDAPS as well and make sure
> that SASL/GSSAPI/GSS-SPNEGO are set up so that it can be used together
> with TLS. HTH
Good morning, Is there an expected eta for the patches to be available?
Pending that,
Is it possible to have two "ldap" providers in the same domain with
different ldap settings?
For example, if using ad for auth_provider and ldap for id/access providers
[domain/example.com]
auth_provider = ldap
auth_provider ldap server x.example.com
id_provider = ldap
id_provider ldap server y.example.com
Such that the ad auth provider can now use ldap TLS/SSL to the password
server, but identity can still be managed by another server?
This may seen to be a weird setup, but it allows separation of
roles/responsibilities.
Thanks
Gary
--
Gary Molenkamp Computer Science/Science Technology Services
Systems Administrator University of Western Ontario
molenkam(a)uwo.ca http://www.csd.uwo.ca
(519) 661-2111 x86882 (519) 661-3566
1 year, 4 months
Can SSSD sort the autofs map
by Oguzhan Eris
Hi everyone.
First off, thanks to everyone who's ever worked on SSSD. It's easily in my top 5 favorite FOSS projects out there.
I am not sure if this is the right way to ask for an enhancement, or whether I should file an issue on GitHub, but I am running into an issue that's described in this Red Hat page https://access.redhat.com/solutions/3673501 (login required)
Basically for an automount map where I need nested top level paths:
/mnt/foo
/mnt/foo/bar
each defined by their own map objects. SSSD does not handle this (neither does LDAP directly from autofs) because the return map from LDAP is unsorted, and if the maps are provided to autofs ordered as:
/mnt/foo/bar
/mnt/foo
the /mnt/foo map masks the previous /mnt/foo/bar map and you'll only get the entries from /mnt/foo
Using file based mount maps, one can easily sort the top level maps, and get around this issue.
Would it be possible to have SSSD return the maps from LDAP query in a sorted way? There is an LDAP control that most LDAP servers support to return a sorted output, (
https://ldapwiki.com/wiki/Server%20Side%20Sort%20Control ) but with so many clients and a large list, this might be better left to the client to do instead.
I'm happy to help out if someone can point me in the right direction in the code.
Thanks again
1 year, 4 months
Re: [Freeipa-users] Re: FreeIPA and IPV6
by TomK
On 12/4/2019 11:16 AM, Alexander Bokovoy via FreeIPA-users wrote:
> On ke, 04 joulu 2019, Stephen John Smoogen via FreeIPA-users wrote:
>> On Tue, 3 Dec 2019 at 21:43, TomK via FreeIPA-users
>> <freeipa-users(a)lists.fedorahosted.org> wrote:
>>>
>>> Hey All,
>>>
>>> Does FreeIPA fully support IPV6 or are there corner cases and
>>> limitations that could make it a show stopper?
>>>
>>
>> Can you define 'fully support' IPV6? I say this from seeing various IT
>> groups still having to deal with major network hardware vendors saying
>> they 'fully support IPV6' but still needing weekly firmware updates
>> because of switch crashes due to IPv6 options. And the problem seems
>> to be that the IPV6 spec is complex and spread out over multiple
>> documents with parts implemented from draft documents that never got
>> out of committee. At times I doubt anything fully supports IPv6 so it
>> is better to come up with what you mean by what you need IPv6 support
>> to do and work from there.
>
> Yep. On the other hand, FreeIPA does have few open IPv6-related problems
> at the moment. It is known to work in the most IPv6 environments we have
> seen so far but there are management issues in DNS handling, for
> example.
>
> https://pagure.io/freeipa/issue/5658
> https://pagure.io/freeipa/issue/4674
>
> Whether these issues prevent you to deploy FreeIPA in IPv6-only
> environment is up to you.
>
Thanks everyone. What I mean by 'fully supported' is just as the
subject says, the FreeIPA piece.
To clarify a bit further I'll break this down into two parts:
1) FreeIPA Core Project: Let's assume for the sake of this discussion
that the OS, Hardware and what not fully supports IPv6. So in other
words, anything outside the realm of what you control or code within the
FreeIPA project is out of scope of this question.
2) Integration: FreeIPA / SSSD will integrate with a host of
technologies including SSSD, 389 Directory Server etc. If any of those
components aren't ready and impact FreeIPA components, I would be
interested to know.
--
Thx,
TK.
1 year, 4 months