logins fail after socket activated responders implemented.
by Lawrence Kearney
SSSD team,
A curious issue after walking through the implementation of the socket
activated responders.
System is a new RHEL 7.7 host with SSSD v1.16.4-21 using the AD providers.
Essentially user resolution (NSS), user login (PAM) and sssctl (IFP) worked
when specifying the responders in the SSSD.conf file.
[root@darkvixen241 ~]# id msteele
uid=1727401116(msteele) gid=1727401151(primary_unix_g)
groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain
users)
[root@darkvixen241 ~]# sssctl user-checks msteele
user: msteele
action: acct
service: system-auth
SSSD nss user lookup result:
- user name: msteele
- user id: 1727401116
- group id: 1727401151
- gecos: Ming Steele
- home directory: /home/dvc.darkvixen.com/msteele
- shell: /bin/bash
SSSD InfoPipe user lookup result:
- name: msteele
- uidNumber: 1727401116
- gidNumber: 1727400513
- gecos: Ming Steele
- homeDirectory: /home/msteele
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Success
PAM Environment:
- no env -
After implementing the desired socket activated responders I cannot login
as users via SSH, but can su as them from a root session. User resolution
and sssctl still work.
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd-
sssd-autofs.socket loaded active listening SSSD AutoFS Service
responder socket
sssd-kcm.socket loaded active listening SSSD Kerberos Cache
Manager responder socket
sssd-nss.socket loaded active running SSSD NSS Service
responder socket
sssd-pac.socket loaded active listening SSSD PAC Service
responder socket
sssd-pam-priv.socket loaded active listening SSSD PAM Service
responder private socket
sssd-pam.socket loaded active listening SSSD PAM Service
responder socket
sssd-secrets.socket loaded active listening SSSD Secrets Service
responder socket
sssd-ssh.socket loaded active listening SSSD SSH Service
responder socket
sssd-sudo.socket loaded active listening SSSD Sudo Service
responder socket
[root@darkvixen241 ~]# id msteele
uid=1727401116(msteele) gid=1727401151(primary_unix_g)
groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain
users)
[root@darkvixen241 ~]# sssctl user-checks msteele
user: msteele
action: acct
service: system-auth
SSSD nss user lookup result:
- user name: msteele
- user id: 1727401116
- group id: 1727401151
- gecos: Ming Steele
- home directory: /home/dvc.darkvixen.com/msteele
- shell: /bin/bash
SSSD InfoPipe user lookup result:
- name: msteele
- uidNumber: 1727401116
- gidNumber: 1727400513
- gecos: Ming Steele
- homeDirectory: /home/msteele
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Authentication service cannot retrieve authentication info
PAM Environment:
- no env -
My sssd.conf is provided below:
[sssd]
config_file_version = 2
# services = nss,pam,pac,ssh,autofs,sudo
domains = dvc.darkvixen.com
[nss]
filter_users =
root,bin,daemon,adm,lp,sync,shutdown,halt,mail,operator,games,ftp,nobody,systemd-network,dbus,polkitd,sshd,postfix,chrony,sssd,apache,rpc,rpcuser,nfsnobody
filter_groups =
root,bin,daemon,sys,adm,tty,disk,lp,mem,kmem,wheel,cdrom,mail,man,dialout,floppy,games,tape,video,ftp,lock,audio,nobody,users,utmp,utempter,input,systemd-journal,systemd-network,dbus,polkitd,ssh_keys,sshd,postdrop,postfix,chrony,printadmin,cgred,sssd,apache,rpc,rpcuser,nfsnobody
[pam]
pam_account_expired_message = "Account expired, please contact help desk."
pam_account_locked_message = "Account locked, please contact help desk."
pam_verbosity = 3
[pac]
[ssh]
[autofs]
[sudo]
[ifp]
[domain/dvc.darkvixen.com]
id_provider = ad
access_provider = ad
cache_credentials = true
override_homedir = /home/%d/%u
override_shell = /bin/bash
override_gid = 1727401151
ad_access_filter = DOM:DVC.DARKVIXEN.COM:
(|(memberOf=CN=DARKVIXEN241_G,OU=LDAP,OU=SVS,DC=dvc,DC=darkvixen,DC=com)(memberOf=CN=DARKVIXEN_HPC_ADMIN_G,OU=CLUSTERS,OU=SVS,DC=dvc,DC=darkvixen,DC=com))
Nothing remarkable shows up in the logs after issuing "sssctl debug-level
7" and curiously there are no sssd_pam or sssd_pac log files created.
Any assistance would be appreciated,
-- lawrence
--
Lawrence Kearney
w: www.lawrencekearney.com
l: www.linkedin.com/in/lawrencekearney
4 years, 4 months
Group disappears from users / no group name gets resolved
by Jamal Mahmoud
We've been experiencing an intermittent issue relating to SSSD v1.15.2, we are running CentOS7.4 on our workstations. We use SSSD to communicate with our Active Directory to pull users for auth. The majority of users have a certain group set as their primary group and some departments have it as an additional group. Most of the time this group works fine on all workstations but sometimes we will run into an issue where a user can no longer access the privileges attained from the group. For users who have it set as primary, the id command returns a gid without the name and for users who have it as an additional group, it doesn't appear at all. I've managed to capture output from sssd services and there are a few interesting lines that I thought I should share with you as I don't understand what they mean. I should add that when this error occurs, restarting the sssd.service usually works, if not, sss_cache -E works, and if that doesn't work, removing the workstation from the realm, de
leting the sssd db and rejoining seems to be the final trick that works.
Regarding the logs, the symptoms I noted are below:
1. getent group *mygroup* returns nothing
2. id user returns a gid without a resolved group name (if it is a primary group)
3. I had to leave the realm, delete the db and rejoin to get sssd to work properly again.
in sssd_nss.log i found this entry:
(Wed Aug 21 16:22:45 2019) [sssd[nss]] [nss_get_grent] (0x0040): Incomplete group object for group(a)domain.com[0]! Skipping
and in the sssd_domain.com.log:
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_split_members] (0x4000): [CN=USER,OU=IT Privileged accounts,DC=domain,DC=com] is unknown object
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_process_send] (0x0400): More members were missing than the deref threshold
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_process_send] (0x2000): Looking up 11/224 members of group [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com]
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_nested_group_process_send] (0x2000): Dereferencing members of group [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com]
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_deref_search_send] (0x2000): Server supports ASQ
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_asq_search_send] (0x0400): Dereferencing entry [CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com] using ASQ
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_print_server] (0x2000): Searching XXX.XXX.XXX.XXX:389
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_get_generic_ext_send] (0x0400): WARNING: Disabling paging because scope is set to base.
(Wed Aug 21 16:22:43 2019) [sssd[be[domain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [no filter][CN=GROUP,OU=Security,OU=Groups,OU=Place St,OU=Offices,DC=domain,DC=com].
I've redacted the entries but I'm sure you can get the jist of whats happening here hopefully. If there is anything else you need, please do not hesitate to ask! If these logs don't point to anything could you maybe provide some advice on what to look for when parsing?
Thanks,
Jamal
4 years, 4 months
sssd issues on upgrade to EL 8.1
by John Beranek
So, I've started testing upgrading EL 8.0 to 8.1, in my case with Oracle
Linux 8.
I spotted 2 issues during/after upgrade, both seem related to sssd.
The first is that during the upgrade, sssd is updated and therefore
restarted, but sssd fails to restart successfully.
Nov 15 22:33:31 devzitsol8 systemd[1]: Stopping System Security Services
Daemon...
Nov 15 22:33:31 devzitsol8 sssd[nss][11571]: Shutting down
Nov 15 22:33:31 devzitsol8 sssd[autofs][11574]: Shutting down
Nov 15 22:33:31 devzitsol8 sssd[be[AD]][11570]: Shutting down
Nov 15 22:33:31 devzitsol8 sssd[sudo][11573]: Shutting down
Nov 15 22:33:31 devzitsol8 sssd[pam][11572]: Shutting down
Nov 15 22:33:31 devzitsol8 sssd[be[implicit_files]][11569]: Shutting down
Nov 15 22:33:31 devzitsol8 systemd[1]: Stopped System Security Services
Daemon.
Nov 15 22:33:31 devzitsol8 systemd[1]: Starting System Security Services
Daemon...
Nov 15 22:33:31 devzitsol8 sssd[33205]: Starting up
Nov 15 22:33:31 devzitsol8 sssd[be[AD]][33207]: Starting up
Nov 15 22:33:31 devzitsol8 sssd[be[implicit_files]][33206]: Starting up
Nov 15 22:33:31 devzitsol8 sssd[be[AD]][33208]: Starting up
Nov 15 22:33:33 devzitsol8 sssd[be[AD]][33209]: Starting up
Nov 15 22:33:36 devzitsol8 sssd[nss][33211]: Starting up
Nov 15 22:33:36 devzitsol8 sssd[autofs][33214]: Starting up
Nov 15 22:33:36 devzitsol8 sssd[sudo][33213]: Starting up
Nov 15 22:33:36 devzitsol8 sssd[pam][33212]: Starting up
Nov 15 22:33:36 devzitsol8 sssd[nss][33215]: Starting up
Nov 15 22:33:36 devzitsol8 sssd[autofs][33216]: Starting up
Nov 15 22:33:36 devzitsol8 sssd[sudo][33217]: Starting up
Nov 15 22:33:36 devzitsol8 sssd[pam][33218]: Starting up
Nov 15 22:33:37 devzitsol8 sssd[be[AD]][33219]: Starting up
Nov 15 22:33:37 devzitsol8 sssd[33205]: Exiting the SSSD. Could not restart
critical service [AD].
Nov 15 22:33:37 devzitsol8 sssd[be[implicit_files]][33206]: Shutting down
Nov 15 22:33:37 devzitsol8 systemd[1]: sssd.service: Main process exited,
code=exited, status=1/FAILURE
Nov 15 22:33:37 devzitsol8 systemd[1]: sssd.service: Failed with result
'exit-code'.
Nov 15 22:33:37 devzitsol8 systemd[1]: Failed to start System Security
Services Daemon.
This appears to be due to this:
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [be_res_get_opts] (0x0100):
Lookup order: ipv4_first
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [recreate_ares_channel] (0x0100):
Initializing new c-ares channel
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [sss_names_init_from_args]
(0x0100): Using re
[(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))].
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [sss_fqnames_init] (0x0100):
Using fq format [%1$s@%2$s].
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [sbus_signal_handler] (0x0020):
We do not listen to this signal!
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [sbus_signal_handler] (0x0020):
We do not listen to this signal!
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100):
Using [ad] provider for [id]
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100):
Using [ad] provider for [auth]
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100):
Using [ad] provider for [access]
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100):
Using [ad] provider for [chpass]
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100):
Using [ad] provider for [sudo]
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100):
Using [ad] provider for [autofs]
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100):
Using [ad] provider for [selinux]
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100):
Using [ad] provider for [hostid]
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100):
Using [ad] provider for [subdomains]
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_configuration] (0x0100):
Using [ad] provider for [session]
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_module_open_lib] (0x0010):
Unable to load module [ad] with path [/usr/lib64/sssd/libsss_ad.so]:
libwbclient.so.0: cannot open shared object file: No such file or directory
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_module] (0x0020): Unable
to create DP module.
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_target_init] (0x0010): Unable
to load module ad
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_load_targets] (0x0020):
Unable to load target [id] [80]: Accessing a corrupted shared library.
(Fri Nov 15 22:33:37 2019) [sssd[be[AD]]] [dp_init_done] (0x0020): Unable
to initialize DP targets [1432158209]: Internal Error
After the 8.1 update completed though, I could happily start sssd.
The second issue is more subtle, and comes due to our use of the autofs
provider, using Active Directory for the map location. On bootup autofs
takes a long time to start, which means that autofs-provided mounts are
unavailable when the system first boots. This looks a lot like this Fedora
bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1648521
Nov 16 10:27:46 devzitsol8 oddjob-mkhomedir[1513]: error creating /nethome:
Permission denied
Nov 16 10:29:04 devzitsol8 automount[1124]: lookup_read_master:
lookup(sss): getautomntent_r: Invalid argument
Nov 16 10:29:04 devzitsol8 automount[1124]: lookup(file): failed to read
included master map auto.master
Nov 16 10:29:04 devzitsol8 automount[1124]: lookup(file): failed to read
included master map auto.master
Nov 16 10:29:04 devzitsol8 automount[1124]: mounted indirect on /misc with
timeout 300, freq 75 seconds
Nov 16 10:29:04 devzitsol8 automount[1124]: mounted indirect on /net with
timeout 300, freq 75 seconds
Nov 16 10:29:04 devzitsol8 automount[1124]: mounted indirect on /nethome
with timeout 300, freq 75 seconds
Nov 16 10:29:04 devzitsol8 systemd[1]: Started Automounts filesystems on
demand.
Nov 16 10:29:04 devzitsol8 systemd[1]: Reached target Multi-User System.
Nov 16 10:29:04 devzitsol8 systemd[1]: Starting Update UTMP about System
Runlevel Changes...
Nov 16 10:29:04 devzitsol8 systemd[1]: Started Update UTMP about System
Runlevel Changes.
Nov 16 10:29:04 devzitsol8 systemd[1]: Startup finished in 1.207s (kernel)
+ 5.624s (initrd) + 1min 37.318s (userspace) = 1min 44.150s.
Nov 16 10:30:18 devzitsol8 systemd[1503]: Starting Mark boot as
successful...
Happy to provide more logs if it helps diagnose these issues.
Cheers,
John
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
4 years, 4 months
how to say name of daemon? "S-S-S-D" or "TRIPLE-S-D"?
by Spike White
All,
S-S-S-D does not seem to roll off the tongue. When I say that, co-workers
think I'm discussing solid-state drives (SSD). When I call it triple-S-D,
someone invariably corrects me.
Which is correct? Are both pronunciations correct?
Spike
4 years, 4 months
managing authorization without AD/LDAP
by JOULAUD François
Hello,
I have a use case of ssh authentication to some server which for
various reasons (one of them being network isolation) cannot access to
Directory.
With ssh I can use ssh certificates to do the authentication part
"offline" without the need for the server to access any centralized
service.
But I still need LDAP connexion to get directory information (numeric
uid, groups, etc.)
I would like a mechanic which allows to transmit this information
along with the connexion initiation.
For example the ssh certificate could have some extension options like
uid(a)example.com=1234 and groups(a)example.com=wheel,admin,mygroup and
this certificate would create the corresponding entries in SSSD in
passwd and groups databases which would be valid for the duration of
the certificate.
Do anyone knows of such a setup or have any pointer to similar ideas ?
Do you think it would be possible for SSSD to be extended to support
this use case ? Would it be easy to implement ? (a bunch of
AuthorizedKeyCommand shell scripts interacting with SSSD D-Bus
interface would suit me)
François
4 years, 4 months
GID numbers showing up rather than group names using groups command.
by Abhisheyk Deb
Hi,
This issue might have been already fixed. And my configuration might not be
right.
So we have a Active directory domain which has two domain controllers, and
a linux system which is joined to that domain.
For some users, when we use the groups <username> command, we are getting
all the proper information, but for some users, groups command gives error
like "cannot find name for group ID XXXXXXXX"
The /etc/sssd/sssd.conf file is as follows:
[sssd]
domains = ad.example.com
config_file_version = 2
services = nss, pam
[pam]
offline_credentials_expiration = 1
[domain/ad.example.com]
ad_domain = ad.example.com
krb5_realm = ad.example.com
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
access_provider = ad
override_homedir = /user/%u
account_cache_expiration = 1
entry_cache_timeout = 180
Can somebody help me with this issue?
Thank you
Abhishek Deb
4 years, 4 months
Any way to get sssd to ignore gidNumber (Posix attribute) when auto_private_group set to true?
by Spike White
All,
We're replacing a commercial product that ignores whatever GID is used in
gidNumber posix attribute, when auto_private_groups is set to true.
However, we find in sssd that even when we set auto_private_groups = True,
that in additional to all the supplemental groups defined by memberOf, it
also appends as the supplemental group the group whose GID is in gidNumber.
Is that any way to disable this? To have sssd list only "memberOf" groups
as supplemental groups when auto_private_groups == True?
Spike White
4 years, 4 months
SSSD strangeness
by simonc99@hotmail.com
Hi All
We've got SSSD 1.13.0 installed as part of a Centos 7.2.1511 installation.
We've used realmd to join the host concerned to our 2008R2 AD system. This went really well, and consequently we've been using SSSD to provide login services and kerberos integration for our fairly large hadoop system.
The authconfig that's implicitly run as part of realmd produces the following sssd.conf:
[sssd]
domains = <joined domain>
config_file_version = 2
services = nss, pam
[pam]
debug_level = 0x0080
[nss]
timeout = 20
force_timeout = 600
debug_level = 0x0080
[domain/<joined domain>]
ad_domain = <joined domain>
krb5_realm = <JOINED DOMAIN>
realmd_tags = manages-system joined-with-samba
cache_credentials = true
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/%u@%d
access_provider = simple
simple_allow_groups = <AD group allowing logins>
krb5_use_kdc_info = False
entry_cache_timeout = 300
debug_level = 0x0080
ad_server = <active directory server>
As I've said - this works really well. We did have some stability issues initially, but they've been fixed by defining the 'ad_server' rather than using autodiscovery.
Logins work fine, kerberos TGTs are issued on login, and password changes are honoured correctly.
However, in general day to day use, we have noticed a few anomalies, that we just can't track down.
Firstly (this has happened a few times), a user will change their AD password (via a Windows PC).
Subsequent logins - sometimes with specific client software - fail with
pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<remote PC name> user=<username>
pam_sss(sshd:auth): received for user <username>: 17 (failure setting user credentials)
So in this example, the person concerned has changed their AD password. Further attempts to access this system via SSH work fine. However, using SFTP doesn't work (the above is output into /var/log/secure).
There are no local controls on sftp logins, and the user concerned was working fine (using both sftp and ssh) until they updated their password.
There is no separate sftp daemon running, and it only affects one individual currently (but we have seen some very similar instances before)
The second issue we have is around phantom groups in AD.
Hadoop uses an id -Gn command to see group membership for authorisation.
With some users - we've seen 6 currently - we see certain groups failing to be looked up:
id -Gn <username>
id: cannot find name for group ID xxxxyyyyy
<group name> <group name> <group name> <group name> <etc...>
The xxxxyyyyy indicates:
xxxx = hashed realm name
yyyyy = RID from group in AD
We can't find any group with that number on the AD side!
We can work around this by adding a local group (into /etc/group) for the GIDs affected. This means the id -Gn runs correctly, and the hadoop namenode can function correctly - but this is a workaround and we'd like to get to the bottom of the issue.
Rather than flooding this post now with logfiles, just thought I'd see if this looked familiar to anyone. Happy to upload any logs, amend logging levels, etc.
Many thanks
Simon
4 years, 4 months
sssd PKINIT smartcard auth on RHEL7?
by James Ralston
I am struggling to get smartcard authentication working on RHEL7,
using sssd-1.16.4-21.el7 and krb5 PKINIT against Microsoft Active
Directory KDCs.
Has anyone actually gotten this working? If so, what behavior
differences do you see from various login mechanisms (gdm, login,
et. al.)?
Because I see *no* visual differences in any login mechanism. gdm,
login, et. al. prompt for a username/password, exactly as before.
Both after I enter the username, and after I enter the PIN (at the
"password" prompt), there is a delay while sssd pokes at the card. I
can also tell this from watching the light on the card reader blink.
But then the login fails.
I mean, these documents:
https://docs.pagure.org/SSSD.sssd/design_pages/smartcard_authentication_p...
https://docs.pagure.org/SSSD.sssd/design_pages/smartcard_multiple_certifi...
…make it sound like the gdm login screen should prompt me to insert a
smartcard, or least differentiate *somehow* that smartcard
authentication is in play. Both features claim to be implemented in
sssd-1.16.4-21.el7. But I see nothing that indicates these features
are working.
If it's really the case that we have to train our users to type their
username into the "username" prompt and enter their smartcard PIN into
the "password" prompt, we can do that, but that doesn't seem to be how
it's supposed to work based on the above documents. And that's going
to seem completely horrible to users in contrast to how Windows works,
where you walk up, insert your smartcard, and the login screen
identifies you and then prompts for your PIN.
I mean, I get it that /usr/bin/login running on a virtual console
can't engage in a nifty interactive dialog like Windows does. But is
really the case that gdm is that dumb with smartcards as well?
Or am I misunderstanding how gdm+sssd+smartcard+PKINIT is supposed to
work?
I can supply (somewhat redacted) configuration files if need be, but I
have everything set correctly that I know to set:
* krb5.conf is configured correctly; I can kinit using the
smartcard+PIN.
* We use pam_sss.so in all of (password-auth, system-auth,
smartcard-auth), so no matter how a program enters the PAM stack, it
should get pam_sss.so and PKINIT.
* I touched /var/lib/sss/pubconf/pam_preauth_available into existence
and restarted sssd.
* I set enable-smartcard-authentication to true in dconf (for
org.gnome.login-screen).
* I set "pam_cert_auth = true" in the [domain/example.org] section of
/etc/sssd/sssd.conf.
* I extracted the correct certificate from my smartcard (the one that
krb5.conf is configured to find) and added it to my userCertificate
attribute in Active Directory.
* I even populated /etc/pki/nssdb with all of the same certificates
that update-ca-trust maintains, even though I'm not sure that's
necessary, as I think krb5 pkinit.so should handle that.
* I increased various sssd timeouts to work around this bug in sssd
that was derailing the nss responder:
#4103 slow smartcard interactions break sssd when PKINIT is configured
https://pagure.io/SSSD/sssd/issue/4103
I'm open to suggestions for anything that I missed.
4 years, 4 months
Re: sssd - ssh and ticket renewal
by Sumit Bose
On Mon, Nov 04, 2019 at 04:01:20PM +0000, Jay McCanta wrote:
> I've been working with SSSD for a good while and I could have sworn I knew how to get this working, but....
>
> Login on workstations via GDM and my Kerberos tickets get renewed automatically. As I type this, I realize that I do lock/unlock my screen at least once a day. My tickets never seem to expire on my workstation.
> From my workstation, I ssh to a server with sssd enabled authentication (Ubuntu bionic on both ends). I use a different account on the remote server and am asked for a password. Ssh is configured to use PAM and has it's own password authentication disabled. (PasswordAuthentication no; UsePAM yes; ChallengeResponseAuthentication yes). Home folders are kerberized NFS and upon initial login, all is well. However the ticket for this session never renews on its own. sudo will refresh the ticket. It's about the only other thing we have sssd enable for besides ssh. Without any sudo activity, the Kerberos ticket expires and we lose access to home folders. Current workaround is a user cron job that tries to refresh the key every hour. I have to sudo on this server several times a day so my tickets were being renewed. CO-workers don't have sudo access and they are the ones losing their tickets.
>
> Is my assumption that one should be able to ssh to a server and have that server refresh tickets (like on a workstation) a valid one? If so, where should I concentrate my efforts to get this working?
Hi,
please have a look at the krb5_renew_interval option explained in the
sssd-krb5 man page.
HTH
bye,
Sumit
>
> Thanks to all in this group.
>
> [cid:image001.jpg@01D592E5.F6CEED20]<https://f5.com/>
> Jay McCanta | Principal Systems Administrator
> D +1 (206) 272-7998 M +1-206-434-1080
>
>
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
4 years, 4 months