[SSSD-users] Re: sssd failing due to self-signed certificates--but that's not what openssl says

[Gordon Messmer]

On 2024-02-21 09:45, Johnnie W Adams wrote:
     So I've got a very puzzling situation. Just today, when I look at 
sssd with systemctl status, I get this error:*Could not start TLS 
encryption. error:1416F086:SSL 
routines:tls_process_server_certificate:certificate verify failed 
(self signed certificate in certificate chain)*


   However, when I run openssl s_client -showcerts 
-connectldap.example.com:636 , it shows 
a completely valid, not-self-signed certificate chain.




Technically, all TLS chains terminate in a self-signed cert.  The only 
question is whether or not any of those certs appear in your trust DB.


To be clear, if you run "openssl s_client -showcerts -connect 
ldap.example.com:636 < /dev/null | grep ^Verify", you get "Verify return 
code: 0 (ok)"?


If the CA is in your trust DB, then it's possible that the trust DB is 
mis-labeled, since sssd runs in a confined domain, while openssl does 
not.  So, if you run "restorecon -rv /etc/pki", does that print any 
output that indicates that it changed labels?  If so, does that fix the 
problem with sssd?
--
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: sshkey use allows expired account user to access system

[Gordon Messmer]

On 6/2/22 13:36, Jim Kinney wrote:

It seems if valid ssh keys exist, the expired account status doesn't
block login with ssh keys.



I believe that's because *users* don't expire.  *Passwords* do. If you 
aren't authenticating with passwords, then password expiration doesn't 
affect the account.


This is one of the reasons that users should consider using Kerberos, or 
SSH certificate systems, rather than SSH keys.


https://smallstep.com/blog/use-ssh-certificates/
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….

[Gordon Messmer]

On 8/25/21 8:32 AM, Spike White wrote:


Because we are researching an ongoing problem reported by L1 server 
ops.  About 70 – 80 sssd-enabled Linux servers / month drop off the 
domain.  Out of our current sssd-enabled population of ~20K server, 
that’s not horrible.  But still it should be better.  (Our former 
commercial product did better.)


It’s not limited to one particular OS, OS version, build location or 
region.  We have surveyed; it seems to occur randomly among all OS 
versions, regions and locations.

...

We are taking sssd’s default settings for 
ad_maximum_machine_account_password_age and 
ad_machine_account_password_renewal_opts. ... So when we find servers 
that have dropped off the domain, it’s because they have not renewed 
their AD machine accounts in 40 days.




We had similar symptoms on CentOS systems at my previous employer, 
however, I'm mostly sure that they were resolved by an sssd update 
sometime in the last year or two.  Are all of your systems fully patched?


If you're seeing the same issue that we saw, one indication would be 
that running "klist -kt /etc/krb5.keytab" would print a list including 
two KVNOs on systems after they'd dropped off the domain.


I'd also look up machines in AD to find systems that haven't changed 
their password in > 40 days, and compare the PasswordLastSet date for a 
system you're examining to the dates in the klist output:


https://pipe2text.com/?page_id=121

Import-Module ActiveDirectory
$date = [DateTime]::Today.AddDays(-40)
Get-ADComputer -Filter  ‘PasswordLastSet -le $date’ -SearchBase 
“OU=WhereIStoreComputers,DC=pipe2,DC=Text,DC=com” -properties 
PasswordLastSet




But packet captures proved that adcli update is using TCP on RHEL7/8.



I *think* that our problems went away after an update changed machine 
password renewal to TCP only.  You might have a different problem, but 
I'd still start with the keytab, and I'd increase the logging level for 
sssd because the default logging level didn't give us a lot of 
information to go on when we were troubleshooting password renewal.  It 
doesn't need to be 9, but should be increased to a level that won't 
cause you operational difficulty.

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Unreadable GPOs should not be logged as a critical failure

[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.

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Could not convert objectSID ... to a UNIX ID

[Gordon Messmer]

On Tuesday, July 30, 2019 22:35 PDT, Sumit Bose  wrote:


the version of SSSD you are using should automatically pick a new range
if the RID is too large. Can you send your sssd.conf for a start to
better understand your setup and see what might preventing SSSD from
picking a new range?



The configuration file is generated by "realm join".  Are there any 
specific patterns you'd like to see from the logs that might provide 
more information?



[sssd]
domains = business.com
config_file_version = 2
services = nss, pam

[domain/business.com]
debug = 6
ad_domain = business.com
krb5_realm = BUSINESS.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 = False
fallback_homedir = /home/business/%u
access_provider = ad

___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org