issue with sssd
by Antonio Peña Díaz
Hi community!
I integrate sssd with Windows Active Directoy using ldaps and certificates without entering the linux servers into domain... and I can login sucessully on my linux servers
using correct groups and everythings going well.... but in the logs i'm still watching this kind of issues... what could be ?
[simple_check_get_groups_primary] (0x0040): Could not look up primary group [948600513]: [2][No such file or directory] uid=948609251(emper0r) gid=948600513 groups=948600513,948602187(vcenterfulladmin),948610184(linuxadmin)
this group numbers are from active directory...
the other thing is .. in that linux we have on /etc/resolv.conf the ip address of DNS where all records point ok but we receive this errors too.
(2021-03-12 14:13:10): [be[mydomain.local]] [resolv_gethostbyname_done] (0x0040): querying hosts database failed [5]: Input/output error
(2021-03-12 14:13:10): [be[mydomain.local]] [sdap_sudo_get_hostnames_done] (0x0040): Could not resolve fqdn for this machine, error [5]: Input/output error, resolver returned: [11]: Could not contact DNS servers
(2021-03-12 14:13:10): [be[mydomain.local]] [sdap_sudo_get_hostinfo_done] (0x0020): Unable to retrieve hostnames [5]: Input/output error
(2021-03-12 14:13:10): [be[mydomain.local]] [sdap_sudo_refresh_hostinfo_done] (0x0040): Unable to retrieve host information, host filter will be disabled [5]: Input/output error
Apart of this I can login into linux server with my user from AD specified on linuxadmin group, so works good!
OS: CentOS 8
Sssd versions
sssd-dbus-2.3.0-9.el8.x86_64
sssd-krb5-common-2.3.0-9.el8.x86_64
sssd-ldap-2.3.0-9.el8.x86_64
sssd-client-2.3.0-9.el8.x86_64
sssd-nfs-idmap-2.3.0-9.el8.x86_64
sssd-krb5-2.3.0-9.el8.x86_64
sssd-proxy-2.3.0-9.el8.x86_64
sssd-ipa-2.3.0-9.el8.x86_64
sssd-ad-2.3.0-9.el8.x86_64
sssd-tools-2.3.0-9.el8.x86_64
sssd-common-2.3.0-9.el8.x86_64
python3-sssdconfig-2.3.0-9.el8.noarch
sssd-kcm-2.3.0-9.el8.x86_64
sssd-common-pac-2.3.0-9.el8.x86_64
sssd-2.3.0-9.el8.x86_64
kernel: 4.18.0-240.1.1.el8_3.x86_64
[APK]
Antonio Peña Díaz
Sistemisti e Sistemi Informativi Interni
Area Tecnica
APKAPPA S.r.l. sede legale Via F. Albani, 21 20149 Milano | p.iva/vat no. IT-08543640158
sede amministrativa e operativa Reggio Emilia (RE) via M. K. Gandhi, 24/ A 42123 - sede operativa Magenta (MI) via Milano, 89/91 20013
tel. 02 94454 000 | fax 02 94454 339 www.apkappa.it
Seguici su:
[Facebook]<https://www.facebook.com/apkappasrl> [LinkedIn] <https://www.linkedin.com/company/apkappasrl> [Twitter] <https://www.utilitiespress.it/apkappa/>
Questo messaggio elettronico ed i suoi allegati sono riservati e tutelati dal segreto professionale. Sono rivolti esclusivamente al/ai destinatario/i identificato/i. Pertanto ne è proibita la lettura, copiatura, divulgazione e utilizzazione da parte di chiunque altro non sia autorizzato. Se non siete il destinatario o avete ricevuto questo messaggio per errore, vi invitiamo a cancellare il messaggio ed eventuali allegati dandone immediatamente comunicazione scritta a mezzo posta elettronica al mittente. I dati dell’interessato sono trattati da APKAPPA S.r.l. nel pieno rispetto del Regolamento (UE) 679/2016 e del D.Lgs. 196/2003 s.m.i. Informazioni dettagliate, anche in ordine al diritto di accesso e agli altri diritti, sono disponibili sul sito www.apkappa.it nella sezione PRIVACY.
This message and its attachments are confidential and protected by professional secrecy. They are addressed exclusively to the identified recipient (s). Therefore reading, copying, disclosure and use by anyone else who is not authorized is prohibited. If you are not the recipient or have received this message by mistake, we invite you to delete the message and any attachments by immediately sending written notice to the sender by e-mail. The data of the interested party are processed by APKAPPA Srl in full compliance with the Regulation (EU) 679/2016 and the Legislative Decree 196/2003 s.m.i. Detailed information, including on the right of access and other rights, is available on the website www.apkappa.it in the PRIVACY section
2 years, 9 months
sssd crashing on aarch64
by Matthew Bettinger
Hello,
We are deploying a new cluster centos 8.2.2004 architecture is aarch64.
We are trying to integrate it with our freeipa system but having an issue where the sssd daemon on the nodes are core dumping. Looking for some guidance in tracking down the issue.
CentOS Linux release 8.2.2004 (Core)
[root@cedar-cn01 ~]# uname -a
Linux cedar-cn01.cedar.cluster 4.18.0-193.28.1.el8_2.aarch64 #1 SMP Thu Oct 22 00:42:58 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
[root@cedar-cn01 ~]# uname -r
4.18.0-193.28.1.el8_2.aarch64
/var/log/sssd shows
(Mon Mar 8 17:45:15 2021) [sssd] [sysdb_domain_cache_connect] (0x0010): DB version too new [0.22], expected [0.21] for domain implicit_files!
(Mon Mar 8 17:45:15 2021) [sssd] [sysdb_domain_cache_connect] (0x0010): DB version too new [0.22], expected [0.21] for domain implicit_files!
Unit sssd.service has finished shutting down.
Mar 09 21:28:10 cedar-cn01.cedar.cluster systemd[1]: sssd.service: Start request repeated too quickly.
Mar 09 21:28:10 cedar-cn01.cedar.cluster systemd[1]: sssd.service: Failed with result 'core-dump'.
Mar 09 21:28:10 cedar-cn01.cedar.cluster systemd[1]: Failed to start System Security Services Daemon.
-- Subject: Unit sssd.service has failed
-- Defined-By: systemd
-- Support: https://access.redhat.com/support
--
-- Unit sssd.service has failed.
--
-- The result is failed.
2 years, 9 months
Password expiration in AD with SSSD
by Paweł Szafer
Hi,
I want to warn users when password expiration days are less than 14 days.
I have GPO Default domain policy with this number of days.
I have sssd.conf as:
[sssd]
domains = internal.domain.tld
config_file_version = 2
services = nss, pam
[domain/internal.domain.tld]
cache_credentials = True
debug_level = 6
id_provider = ad
auth_provider = ad
access_provider = ad
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
ldap_id_mapping = True
ldap_schema = ad
enumerate = True
ad_site=internal1
ad_gpo_access_control = permissive
ad_gpo_ignore_unreadable = True
And pam.d as follow:
#%PAM-1.0
auth sufficient pam_sss.so forward_pass
auth required pam_unix.so try_first_pass nullok
auth optional pam_permit.so
auth required pam_env.so
#auth requisite pam_deny.so
account required pam_unix.so
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account optional pam_permit.so
account required pam_time.so
password required pam_unix.so try_first_pass nullok sha512 shadow
password sufficient pam_sss.so
use_authok
password optional pam_permit.so
session required pam_mkhomedir.so
skel=/etc/skel/ umask=0022
session required pam_limits.so
session required pam_unix.so
session optional pam_sss.so
session optional pam_permit.so
User has password valid till 20.02.2020 and yet I don't have any warning.
I had to add ad_gpo_ignore_unreadable = True and ad_gpo_access_control =
permissive to my config because without it I end up with "System error"
during login and unsuccessful login.
In gpo_cache I see Machine gpo with lines:
[Registry Values]
MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon\PasswordExpiryWarning=4,14
Any idea how to turn on this warning?
Thanks for your help!
-----
Best regards,
Pawel
2 years, 9 months
[hs@schlittermann.de: sssd nss: issues with applications not using endpwent()]
by Heiko Schlittermann
Hi,
I sent this to sssd-devel already, but probably it was the wrong
channel, so I'm trying it here.
I'm using Dovecot with its "passwd" userdb, which effectivly uses NSS.
NSS services are provided by the files and by the sss "plugins".
The `doveadm user *` command enumerates the list of users. Repeating the
command doesn't enumerate the users provided by sssd again.
Analyzing this issue reveals:
Dovecot uses a long living process talking to NSS. For user
enumeration it uses
setpwent()
while (…) { getpwent(); }
and then misses the call to endpwent(). This bug is already confirmed by
the Dovecot developers.
I'm not sure about the semantics of setpwent()/endpwend(), especially
about calling sequences like
setpwent()
while (…) { getpwent(); }
setpwent()
while (…) { getpwent(); }
According to setpwent(3) it should rewind to the beginning. Calling
endpwent() seems to be for curtesy only (to have resources freed)
I suggest calling a preventive endpwent() before using setpwent() again
in nss_cmd.c.
Attached you'll find my patch. I'd be happy about review and integration into
upstream.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
2 years, 9 months