not getting cached ticket from PuTTY login
by Pieter Voet
Hi all,
I have the same issue as was already reported here in 2016 : https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
however there was no reply given.
Running sssd on RedHat linux 7 using 'ad' as the 'auth_provider' I succesfully get logged in using Putty from a Windows laptop.
However, running 'klist' returns :
klist: Credentials cache keyring 'persistent:808521:krb_ccache_x2hJGE1' not found
I found articles like 'https://ubuntu.com/server/docs/service-sssd-ad' where it said to install 'krb5-user'
if you want your AD users to also get a kerberos ticket upon logging in. But that is valid for Ubuntu, and there's no
'krb5-user' package for Redhat. Next I found the RH equivalent should be 'krb5-auth-dialog' , but that's not available
for RedHat 7.
Can anybody help me on getting a kerberos ticket if logged on by sssd ?
Thanks !
2 months
Guidance on setting ideal enctypes?
by Kodiak Firesmith
Hi Folks,
I'm nominally aware that the ability for adcli joins to honor custom enctypes became a thing around 2018, but I'm having a heck of a time finding guidance online for setting permitted enctypes so that keytabs don't create keys for DES and RC4.
Our environment uses a mixture of SSSD 2.2.3, and 2.6.3, joining to MS Active Directory, which my Windows admins have said run MS Server 2019 with Active Directory 2016.
I've been digging around on search engines and picking through various krb5 docs, and I think SSSD will refer to krb5.conf, and might be reading supported_enctypes or permitted_enctypes, but I'm not sure how to put it all together.
Thanks very much!
- Kodiak Firesmith
Sent with [Proton Mail](https://proton.me/) secure email.
2 months
SSSD and TLS version
by Nicolas Martin
Hi,
I use sssd together with 389 directory server to manage id and credentials.
My Directory Server is configured to allow only TLSv1.3 (sslVersionMin ==
sslVersionMax == 1.3).
However, whenever I start a ssh session to a machine using a directory
user, I get the following message sequence between the sssd client and the
directory server(exchange generated when the password is entered at prompt):
client -> DS TLSv1.2 message
DS-> client TLSv1.2 message
client closes connections (RST)
client establishes new connection
TLS handshake
Change Cipher Spec
TLSv1.3 exchange
(see detailed exchange below)
I don't understand why there is this initial TLSv1.2 exchange.
Is there a possibility to enforce TLSv1.3 on sssd side ?
I tried to set:
ldap_tls_cipher_suite = TLSv1.3!EXPORT:!NULL
in /etc/sssd.conf, but the behavior is the same.
23 49.553616751 client → DS *TLSv1.2* 95 Application Data
24 49.553632077 client → DS *TLSv1.2* 90 Application Data
25 49.554509324 DS → client *TLSv1.2* 90 Application Data
26 49.554526401 client → DS TCP 54 44625 → 636 *[RST]* Seq=56 Win=0 Len=0
27 49.554534690 DS → client TCP 66 636 → 44625 *[RST, ACK]* Seq=25 Ack=56
Win=286 Len=0 TSval=1278977543 TSecr=3489465836
28 52.843158542 client → DS TCP 74 44627 → 636 *[SYN]* Seq=0 Win=29200
Len=0 MSS=1460 SACK_PERM=1 TSval=3489469126 TSecr=0 WS=128
29 52.843547010 DS → Client TCP 74 636 → 44627 *[SYN, ACK]* Seq=0 Ack=1
Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=1278980832 TSecr=3489469126
WS=128
30 52.843572758 client → DS TCP 66 44627 → 636 *[ACK]* Seq=1 Ack=1
Win=29312 Len=0 TSval=3489469126 TSecr=1278980832
31 52.84471237 client → DS TLSv1 355 *Client Hello*
32 52.845104921 DS → client TCP 66 636 → 44627 [ACK] Seq=1 Ack=290
Win=30080 Len=0 TSval=1278980833 TSecr=3489469127
33 52.866829425 DS → client TLSv1.3 4029 Server Hello, Change Cipher
Spec, Application Data
34 52.866846844 client → DS TCP 66 44627 → 636 [ACK] Seq=290 Ack=3964
Win=37248 Len=0 TSval=3489469150 TSecr=1278980855
35 52.867532757 client → DS TLSv1.3 160 Change Cipher Spec, Application
Data, Application Data
36 52.867591615 client → DS TLSv1.3 348 Application Data
37 52.868097985 DS → client TCP 66 636 → 44627 [ACK] Seq=3964 Ack=666
Win=31104 Len=0 TSval=1278980856 TSecr=3489469150
38 52.868929089 DS → client TLSv1.3 1471 Application Data
39 52.868942962 DS → client TLSv1.3 102 Application Data
40 52.869048855 client → DS TCP 66 44627 → 636 [ACK] Seq=666 Ack=5
2 months, 1 week
authentication failure when one domain controller is down
by Craig Martin
Hi,
I have a problem I have been unable to solve and I'm at a loss. We use sssd on Debian 11 clients with active directory backend. We have 4 domain controllers running Windows Server 2022 in our environment. If any one of those domain controllers goes offline we experience intermittent authentication failures on the linux clients running sssd. It happens on some (but not all) clients and even on an affected client it can be intermittent (meaning sometimes authentication will work, sometimes it will not).
I have tried using the ad_server directive in sssd.conf to restrict the domain controllers the client will try to contact but it seems to have no effect. I have upped the verbosity level in the logs but I am bombarded with messages that I struggle to interpret. Is there someone here who can take a look and help me troubleshoot? I can provide any additional logs / config info upon request.
Here is some preliminary info:
Client OS: Debian 11
SSSD version: 2.4.1
sssd.conf
[sssd]
services = nss, pam
config_file_version = 2
domains = AD.FINRCVGRP.COM
[domain/AD.FINRCVGRP.COM]
debug_level=6
ad_server = frgdc2.ad.finrcvgrp.com,frgdc3.ad.finrcvgrp.com
id_provider = ad
cache_credentials = true
access_provider = ad
#access_provider = simple
#simple_allow_groups = sasdev, dbdev
# Use this if users are being logged in at /.
# This example specifies /home/DOMAIN-FQDN/user as $HOME. Use with pam_mkhomedir.so
override_homedir = /home/%u
override_shell = /bin/bash
# Uncomment if the client machine hostname doesn't match the computer object on the DC.
# ad_hostnamemymachine.myubuntu.example.com
# Uncomment if DNS SRV resolution is not working
# ad_server = dc.mydomain.example.com
# Uncomment if the AD domain is named differently than the Samba domain
# ad_domain = MYUBUNTU.EXAMPLE.COM
# Enumeration is discouraged for performance reasons.
# enumerate = true
2 months, 1 week
sss allows extraneous @ characters prefixed to username?
by Paul B. Henson
We are running the latest RHEL 8.7 which includes sss version
2.7.3-4.el8_7.3 and noticed some odd behavior. sss seems to ignore
leading @ characters when looking up a username. For example:
# getent passwd '@cpp.a'
cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash
The username is 'cpp.a', not '@cpp.a'. It doesn't seem to matter how
many @ signs there are:
# getent passwd '@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@(a)cpp.a'
cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash
This is a local account on the system, with the default sssd
configuration, there is nothing explicitly set:
# find /etc/sssd
/etc/sssd
/etc/sssd/conf.d
/etc/sssd/pki
If I update nsswitch.conf to remove sss from the passwd line this
behavior goes away.
The same behavior occurs on other systems that are integrated with our
LDAP and kerberos systems. When logging in, not only is this invalid
username successfully authenticated, it is passed to other pam modules:
Mar 16 12:35:46 login-dev-01 sshd[3782209]: Skipped Duo login for
'@@@@@@@henson' from 10.104.223.249: Allowing unknown user
This is allowing a bypass of our security policies, in this case, a user
who should have been forced to do MFA was able to login without it
because the name passed to the other modules by the login stack was not
the real username which ended up being logged in.
Is this a bug? A configuration issue? I opened a support ticket with Red
Hat but as have not as yet received a resolution. I wouldn't think this
would be intended behavior out-of-the-box.
Thanks…
2 months, 1 week
SSSD 2.8 supported/working OS
by Roman Annenko
Hi,
I couldn't find any information about which OSes can run sssd 2.x package.
The only mention about "platform" I found in sssd-2.0.0 release notes: "Starting with SSSD 2.0, upstream no longer supports RHEL-6 and its derivatives".
I have Oracle Linux 7 so I think this note implies that at least RHEL7 (and OL7) would be supported platform for sssd2.x
But OL7 repository has only sssd-1.16.5 package included.
So I tried to build sssd2.8 on my own from sources directly on OL7 machine, but compilation fails (after resolving all dependencies) because of missing struct members in declarations in krb5/clpreauth_plugin.h. Those declarations come from "krb5-devel" package on OL7 repo and appear to be incompatible with sssd2.x sources.
Does this mean that sssd2 is incompatible with OL7 and there is no way to make it work on this platform?
2 months, 2 weeks
SSSD conf - ldap_default_authtok and ldap_backup_uri
by Hristina Marosevic
Hello,
Since I can not find relevant information on web about this I would like to ask you about my current issue.
Im my SSSD configuration I have two LDAP URIs, one defines as value of ldap_uri and other defined as value of ldap_backup_uri. These LDAP instances have different password and same LDAP admin DN.
LDAP password for binding to the first LDAP instance is defined as value of the SSSD conf attribute: ldap_default_authtok but I can not find attribute that will store LDAP password for the second LDAP instance.
Are there options for defining LDAP bind password to connect to LDAP server defined as value of ldap_backup_uri in the SSSD configuration or I must change the password of the second instance to match the one defined and used on the first LDAP instance?
Thank you in advance!
BR,
Hristina
2 months, 3 weeks
What are adcli testjoin and sssd doing for us? How do we equivalently kinit -k?
by Spike White
All,
We are surveying our ecosystem of Linux servers, trying to slowly eradicate
the weak rc4 encryption from AD. (Our AD team has done all the legwork;
plus we’ve tested and we’re certain that rc4 is not required for OS-level
AD integration.)
We’re focusing on eliminating rc4 from our sssd-based OS-level logins
now. What we want to do is determine which servers are currently relying
on rc4 for their Kerberos OS-level creds.
A simple way to do this (usually) is to acquire a Kerberos host credential
and see what encryption it negotiated.
kinit -k
klist -e | grep Etype
renew until 03/09/2023 12:41:32, Etype (skey, tkt):
aes256-cts-hmac-sha1-96,
aes256-cts-hmac-sha1-96
Normally, it’ll get aes256 or aes128; either of which are good.
But we’ve hit on some old builds (RHEL7) where we don’t understand what’s
going on. We frankly don’t understand how sssd is working on them. (48
servers in total). We want to audit these, but we’re unclear how.
Sssd is starting and running fine on them. Adcli testjoin is working. But
we don’t know why!
We think because the server names are in upper-case on these builds, that’s
part of our problem.
ldap_sasl_authid is set as so in /etc/sssd/sssd.conf file:
ldap_sasl_authid = SRSPLS3BWCOF104.us.example.com(a)AMER.EXAMPLE.COM
<SRSPLS3BWCOF104.us.dell.com(a)AMER.DELL.COM>
default_realm and mapping from DNS domain to AD domain isn’t set in
/etc/krb5.conf file. (Yes, we know this is bad.)
adcli testjoin succeeds.
[root@SRSPLS3BWCOF104 etc]# adcli testjoin -D AMER.EXAMPLE.COM -v
* Found realm in keytab: AMER.EXAMPLE.COM
* Found computer name in keytab: SRSPLS3BWCOF104
* Found service principal in keytab: host/srspls3bwcof104.us.example.com
* Found host qualified name in keytab: srspls3bwcof104.us.example.com
* Found service principal in keytab: host/SRSPLS3BWCOF104
* Found service principal in keytab: RestrictedKrbHost/SRSPLS3BWCOF104
* Found service principal in keytab: RestrictedKrbHost/
srspls3bwcof104.us.example.com
* Using domain name: AMER.EXAMPLE.COM
* Calculated computer account name from fqdn: SRSPLS3BWCOF104
* Using domain realm: AMER.EXAMPLE.COM
* Discovering domain controllers: _ldap._tcp.AMER.EXAMPLE.COM
* Sending NetLogon ping to domain controller:
AUSDC16AMER41.amer.example.com
* Received NetLogon info from: AUSDC16AMER41.amer.example.com
* Discovering site domain controllers: _ldap._tcp.AMERAustin._sites.dc._
msdcs.amer.example.com
* Sending NetLogon ping to domain controller:
AUSDC16AMER14.amer.example.com
* Received NetLogon info from: AUSDC16AMER14.amer.example.com
* Wrote out krb5.conf snippet to
/tmp/adcli-krb5-62UEmj/krb5.d/adcli-krb5-conf-EvFdQ4
* Authenticated as default/reset computer account: SRSPLS3BWCOF104
* Using GSS-SPNEGO for SASL bind
* Looked up short domain name: AMERICAS
* Looked up domain SID: S-1-5-21-1802859667-647903414-1863928812
Sucessfully validated join to domain AMER.EXAMPLE.COM
[root@SRSPLS3BWCOF104 etc]#
Sssd service is fat and happy.
[root@SRSPLS3BWCOF104 etc]# systemctl status sssd
● sssd.service - System Security Services Daemon
Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor
preset: disabled)
Active: active (running) since Thu 2023-03-02 11:30:25 EST; 2h 25min ago
Main PID: 28053 (sssd)
CGroup: /system.slice/sssd.service
├─28053 /usr/sbin/sssd -i --logger=files
├─28054 /usr/libexec/sssd/sssd_be --domain amer.example.com
--uid 0 --gid 0 --logger=files
├─28055 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
├─28056 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files
├─28057 /usr/libexec/sssd/sssd_ifp --uid 0 --gid 0 --logger=files
└─28058 /usr/libexec/sssd/sssd_autofs --uid 0 --gid 0
--logger=files
Mar 02 13:15:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 1
Mar 02 13:15:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 2
Mar 02 13:30:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 1
Mar 02 13:30:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 1
Mar 02 13:30:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 1
Mar 02 13:30:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 2
Mar 02 13:45:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 1
Mar 02 13:45:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 1
Mar 02 13:45:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 1
Mar 02 13:45:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 2
[root@SRSPLS3BWCOF104 etc]#
/etc/krb5.keytab file has new updated entries in the last 30 days.
[root@SRSPLS3BWCOF104 etc]# klist -kte
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
---- -------------------
------------------------------------------------------
28 02/09/2023 16:14:59 SRSPLS3BWCOF104$(a)AMER.EXAMPLE.COM (arcfour-hmac)
28 02/09/2023 16:14:59 SRSPLS3BWCOF104$(a)AMER.EXAMPLE.COM
(aes128-cts-hmac-sha1-96)
28 02/09/2023 16:14:59 SRSPLS3BWCOF104$(a)AMER.EXAMPLE.COM
(aes256-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 host/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (arcfour-hmac)
28 02/09/2023 16:15:00 host/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 host/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 host/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(arcfour-hmac)
28 02/09/2023 16:15:00 host/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes128-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 host/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes256-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 RestrictedKrbHost/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(arcfour-hmac)
28 02/09/2023 16:15:00 RestrictedKrbHost/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes128-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 RestrictedKrbHost/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes256-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 RestrictedKrbHost/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (arcfour-hmac)
28 02/09/2023 16:15:00 RestrictedKrbHost/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
28 02/09/2023 16:15:00 RestrictedKrbHost/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
27 01/10/2023 06:14:22 SRSPLS3BWCOF104$(a)AMER.EXAMPLE.COM (arcfour-hmac)
27 01/10/2023 06:14:22 SRSPLS3BWCOF104$(a)AMER.EXAMPLE.COM
(aes128-cts-hmac-sha1-96)
27 01/10/2023 06:14:22 SRSPLS3BWCOF104$(a)AMER.EXAMPLE.COM
(aes256-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 host/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (arcfour-hmac)
27 01/10/2023 06:14:23 host/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 host/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 host/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(arcfour-hmac)
27 01/10/2023 06:14:23 host/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes128-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 host/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes256-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 RestrictedKrbHost/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(arcfour-hmac)
27 01/10/2023 06:14:23 RestrictedKrbHost/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes128-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 RestrictedKrbHost/SRSPLS3BWCOF104(a)AMER.EXAMPLE.COM
(aes256-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 RestrictedKrbHost/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (arcfour-hmac)
27 01/10/2023 06:14:23 RestrictedKrbHost/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
27 01/10/2023 06:14:23 RestrictedKrbHost/
srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
[root@SRSPLS3BWCOF104 etc]#
But when we kinit it fails.
[root@SRSPLS3BWCOF104 etc]# hostname --fqdn
SRSPLS3BWCOF104.us.example.com
[root@SRSPLS3BWCOF104 etc]# kinit -k
kinit: Client 'host/srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM' not
found in Kerberos database while getting initial credentials
[root@SRSPLS3BWCOF104 etc]# kinit -k 'host/
SRSPLS3BWCOF104.us.example.com(a)AMER.EXAMPLE.COM'
kinit: Keytab contains no suitable keys for host/
SRSPLS3BWCOF104.us.example.com(a)AMER.EXAMPLE.COM while getting initial
credentials
[root@SRSPLS3BWCOF104 etc]# grep sasl /etc/sssd/sssd.conf
ldap_sasl_authid = SRSPLS3BWCOF104.us.example.com(a)AMER.EXAMPLE.COM
[root@SRSPLS3BWCOF104 etc]# kinit -k '
SRSPLS3BWCOF104.us.example.com(a)AMER.EXAMPLE.COM'
kinit: Keytab contains no suitable keys for
SRSPLS3BWCOF104.us.example.com(a)AMER.EXAMPLE.COM while getting initial
credentials
[root@SRSPLS3BWCOF104 etc]#
If we grab the very first entry out of /etc/krb5.keytab file, kinit -k
works.
[root@SRSPLS3BWCOF104 etc]# klist -kte | head -4
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
---- -------------------
------------------------------------------------------
28 02/09/2023 16:14:59 SRSPLS3BWCOF104$(a)AMER.EXAMPLE.COM (arcfour-hmac)
[root@SRSPLS3BWCOF104 etc]# kinit -k 'SRSPLS3BWCOF104$(a)AMER.EXAMPLE.COM'
[root@SRSPLS3BWCOF104 etc]# klist -e | grep Etype
renew until 03/09/2023 14:03:20, Etype (skey, tkt):
aes256-cts-hmac-sha1-96,
aes256-cts-hmac-sha1-96
This might be what ‘adcli testjoin’ is doing (grabbing first entry from
/etc/krb5.keytab as the service principal to use). But it’s surely not
what sssd is doing, as we explicitly set ldap_sasl_authid.
I know sssd will prepend ‘host/’ to ldap_sasl_authid if it’s missing. But
I don’t think it does anything else if ldap_sasl_authid is explicitly
defined.
What is sssd doing for us under the covers and how can we replicate this
with kinit -k to verify we don’t have rc4 encryption in use?
BTW, here is how the server is known in AD:
cn: SRSPLS3BWCOF104
distinguishedName:
CN=SRSPLS3BWCOF104,OU=Servers,OU=UNIX,DC=amer,DC=example,DC=com
name: SRSPLS3BWCOF104
sAMAccountName: SRSPLS3BWCOF104$
dNSHostName: srspls3bwcof104.us.example.com
userPrincipalName: host/srspls3bwcof104.us.example.com(a)AMER.EXAMPLE.COM
servicePrincipalName: RestrictedKrbHost/srspls3bwcof104.us.example.com
servicePrincipalName: RestrictedKrbHost/SRSPLS3BWCOF104
servicePrincipalName: host/srspls3bwcof104.us.example.com
servicePrincipalName: host/SRSPLS3BWCOF104
Spike
3 months