No netgroup_provider?
by Spike White
All,
Spoiler alert: my configuration is working; I just want verification I
did it right.
BACKGROUND:
I have an LDAP domain that was delivering autofs maps exclusively. Other
(AD) domains were delivering users, groups, authentication and access.
Since this back-end LDAP domain didn’t participate in any user
authentication or access, I configured that backup LDAP domain in sssd.conf
with only an autofs_provder:
[domain/LDAP]
debug_level = 9
id_provider = none
autofs_provider = ldap
ldap_uri= ldap://austgcore17.example.com
ldap_schema = rfc2307bis
ldap_default_bind_dn = cn=ldapadm,dc=itzgeek,dc=local
ldap_default_authtok = ldppassword
ldap_autofs_search_base = ou=automount,ou=admin,dc=itzgeek,dc=local
ldap_autofs_map_object_class = automountMap
ldap_autofs_map_name = automountMapName
ldap_autofs_entry_object_class = automount
ldap_autofs_entry_key = automountKey
ldap_autofs_entry_value = automountInformation
ldap_netgroup_search_base = ou=netgroup,ou=admin,dc=itzgeek,dc=local
Works great! Get all expected automount maps.
CURRENT (ADDED NETGROUPS):
Now I have added NIS netgroups to this backend LDAP server. Thus, it now
successfully delivers automount maps + netgroups.
I still don’t want this LDAP backend domain to even attempt authentication
and access – that’s in my other (AD) domains.
So you’d think all I’d have to do is change this:
[domain/LDAP]
…
id_provider = none
autofs_provider = ldap
to this:
[domain/LDAP]
…
id_provider = none
autofs_provider = ldap
netgroup_provider = ldap
But – point in fact – there is no “netgroup_provider” setting for sssd.conf
file. Netgroup takes whatever the value is of ‘id_provider’.
So I turned on id_provider, then explicitly turned off all providers I
don’t want. Is this correct?
[domain/LDAP]
debug_level = 9
#id_provider = none
id_provider = ldap
auth_provider = none
account_provider = none
chpass_provider = none
sudo_provider = none
subdomains_provider = none
autofs_provider = ldap
Also, any particular reason there’s not a netgroup_provider?
BTW, retrieving netgroups via sssd does not seem explicitly and concretely
documented. That is, I had to consult multiple sources to get the RFC
2307bis setup, another to get the sssd.conf settings. (I’m not faulting
anyone; netgroups are rarely used anymore.)
Is there someone that maintains sssd documentation, I could submit a
concrete example – to help any future intrepid explorer? I have the
specific back-end LDIF files, the specific sssd.conf and nsswitch.conf
file setup.
Spike White
2 days, 18 hours
ldap_id_mapping=True login linux the user UID auto change
by CharlesLee
Hi, everyone
I have a problem with sssd 1.16.0 use in CentOS7 with AD(windows server 2008R2).
I'm use realm join the AD，and sssd config is next:
[domain/default]
autofs_provider = ldap
cache_credentials = True
krb5_realm = ARD.INC
ldap_search_base = dc=BEIJ,dc=inc
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://192.168.201.207/
ldap_id_use_start_tls = False
ldap_tls_cacertdir = /etc/openldap/cacerts
[sssd]
domains = default, ARD.inc
config_file_version = 2
services = nss, pam
[pam]
[autofs]
[domain/ARD.inc]
ad_domain = ARD.inc
krb5_realm = ARD.INC
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_sasl_authid = YW-CLUSTER-LOGI$
ldap_id_mapping = true
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad
ldap_idmap_range_min = 5000
ldap_idmap_range_max = 7000
ldap_idmap_range_size = 10
At the beginning it's running very good.
But the recent we discovery some user's UID have changed , the UID auto +10.
For example, the UID initial is 5333 then user UID auto change to 5343.
Why?
How to solve it?
Thanks.
2 days, 19 hours
Any way to disallow unauthorized users in the pam "authentication" phase instead of "account" phase?
by Spike White
All,
This is not a big deal -- just curious.
We have a commercial Linux AD integration product. In it, the incoming
user's authorization to log in is validated during the PAM "authentication"
phase. So if it's a legal AD user and good password, but that user is not
authorized in -- you're returned to the "login name: / password:" prompt.
In sssd, it appears that validating if you're a legally-authorized user or
in a legally-authorized group occurs in the PAM "account" phase. It's done
by the "simple" access_provider.
Consider again a legal AD user and good password, but again -- that user is
not authorized in.
Now that user name is accepted, that password is accepted, but then the
server closes your putty session. You're not returned to a "login name: /
password:" prompt.
Like I say -- not a big deal. Unauthorized users are intercepted and
disallowed, just in different ways. Just curious if there's a way to make
sssd fail in the former manner, instead of the latter.
Spike White
3 days, 6 hours
SSO works on one server but not the other (reinstall?)
by Hans Schou
Hi
I have two servers "L" & "R" which are connected to the AD.
On server L I can login with SSO and I don't have to type password.
On server R I can't login with SSO and I have to type the AD password.
The user is only defined in the AD not locally.
I have tried "realm leave" + "realm join" and "sss_cache -E".
Removed
/etc/sssd/*
/etc/krb5.keytab
/var/lib/sss/db/*
to make sure no config was leftover.
The /etc/sssd/sssd.conf is equal on both servers.
Both servers are running RHEL 7.6.
/etc/sssd/sssd.conf :
[sssd]
domains = acme.com
config_file_version = 2
services = nss, pam
[domain/acme.com]
ad_domain = acme.com
krb5_realm = ACME.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
fallback_homedir = /home/%u
access_provider = ad
debug_level = 7
Any hint much appreciated.
best regards
Hans
6 days, 1 hour
smartcard cert mapping offline (AD)
by Winberg, Adam
I'm having a hard time understanding how cert mapping is supposed to work
offline. Currently I have the following certmap config (this is on
RHEL8-beta):
[certmap/ad.example.com/smartcard]
maprule =
(|(userPrincipal={subject_principal})(samAccountName={subject_principal.short_name}))
to map the CN on the card to 'samAccountName' in AD. This works as long as
I'm online (access to AD), but when I go offline (disconnect network) the
maprule is not working. I thought that the mapping would then use the sssd
cache but apparantly not - so how is smartcard login supposed to work
offline?
Regards
Adam
1 week
Cant get new TGT after kdestroy on gdm login with smartcard.
by Winberg, Adam
I am having problems consistently getting a TGT after logging in via GDM
with smartcard. On first login it normally works, but if I do a 'kdestroy'
and then logout of my gnome session, I don't get a new TGT when I login to
a new session. Instead, the root user has a TGT for my AD user:
[a001329@c20693 ~]$ klist
klist: Credentials cache 'KCM:60483' not found
[root@c20693 ~]# klist
Ticket cache: KCM:0:63363
Default principal: a001329(a)EXAMPLE.COM
Valid starting Expires Service principal
2019-02-13 15:11:38 2019-02-14 01:11:33 krbtgt/EXAMPLE.com(a)EXAMPLE.com
renew until 2019-02-20 15:11:33
A wild guess is that krb5-pkinit works by letting the root user get a TGT
for my user and then transfer that cache to my user, or something? In my
case that transfer does not happen if I previously performed a kdestroy.
From krb5_child.log:
(Wed Feb 13 14:46:14 2019) [[sssd[krb5_child[12020]]]]
[sss_get_ccache_name_for_principal] (0x4000): Location: [KCM:]
(Wed Feb 13 14:46:14 2019) [[sssd[krb5_child[12020]]]]
[sss_get_ccache_name_for_principal] (0x4000): tmp_ccname: [KCM:0:71555]
(Wed Feb 13 14:46:14 2019) [[sssd[krb5_child[12020]]]] [create_ccache]
(0x4000): Initializing ccache of type [KCM]
(Wed Feb 13 14:46:14 2019) [[sssd[krb5_child[12020]]]] [create_ccache]
(0x4000): CC supports switch
(Wed Feb 13 14:46:14 2019) [[sssd[krb5_child[12020]]]] [create_ccache]
(0x4000): returning: 0
(Wed Feb 13 14:46:14 2019) [[sssd[krb5_child[12020]]]]
[safe_remove_old_ccache_file] (0x0400): New and old ccache file are the
same, none will be deleted.
(Wed Feb 13 14:46:14 2019) [[sssd[krb5_child[12020]]]] [k5c_send_data]
(0x0200): Received error code 0
(Wed Feb 13 14:46:14 2019) [[sssd[krb5_child[12020]]]]
[pack_response_packet] (0x2000): response packet size: [95]
(Wed Feb 13 14:46:14 2019) [[sssd[krb5_child[12020]]]] [k5c_send_data]
(0x4000): Response sent.
(Wed Feb 13 14:46:14 2019) [[sssd[krb5_child[12020]]]] [main] (0x0400):
krb5_child completed successfully
After a while (not sure how long) it works as expected again, presumably
after a timeout of some sort.
If I disable KCM (by removing /etc/krb5.conf.d/kcm_default_ccache) TGT
retrieval works as expected. Am I missing something or is this a bug?
Regards,
Adam
1 week
Password expiration odd behavior with SUDO
by Gabe Pacuilla
Version: sssd-1.16.2-13.el7.x86_64
Hello All,
I've been working with SSSD using FreeIPA directory services, and I've noticed this odd behavior when passwords expire and prompted to change on auth:
---
ipa-user@host:~$ sudo su -
[sudo] password for ipa-user: <Enter password>
Password expired. Change your password now.
sudo: Account or password is expired, reset your password and try again
Current Password: <Hit Ctrl+C here>
sudo: unable to change expired password: Authentication token manipulation error
ipa-user@host:~$ ^C
ipa-user@host:~$ ^C
ipa-user@host:~$ ^C
ipa-user@host:~$ sudo su -
Last login: blah
[root@host ~]#
---
I don't believe we should be able to cancel out of expired password change and subsequently be able to authenticate without any prompt? It appears the sudo ticket is generated before the password expiration prompt is shown.
This seems like breaking behavior since the password expiration is not really being enforced, and in our environment we'll only use passwords for sudo (ssh keys for remote login).
For what it's worth, here's the contents of pam system-auth config:
---
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet
auth [default=1 ignore=ignore success=ok] pam_localuser.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session optional pam_oddjob_mkhomedir.so umask=0077
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
---
Thanks in advance for any insight,
-Gabe
1 week, 3 days
AD 2016 integration GPO weirdness
by Emil Petersson
Hi,
I am trying to configure Active Directory integration with SSSD. AD is running on 2016, and my clients are CentOS 7.6, running SSSD 1.16.2-13.el7.
I want to control client access using AD GPO.
The issue I'm seeing is that any user is allowed to log on to the client, regardless if they are allowed by a GPO or not.
The clients were successfully joined to AD by running:
realm join --user=username --computer-ou='OU=Linux,OU=Servers,OU=XXX,DC=XXX,DC=XXX,DC=net' xxx.xxx.net
The client sssd.conf looks like this:
[sssd]
domains = xxx.xxx.net
config_file_version = 2
services = nss, pam
full_name_format = %1$s
default_domain_suffix = xxx.xxx.net
[domain/xxx.xxx.net]
debug_level = 9
ad_domain = xxx.xxx.net
krb5_realm = XXX.XXX.NET
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 = True
fallback_homedir = /home/%u@%d
access_provider = ad
ad_gpo_access_control = enforcing
dyndns_update = false
When trying to log in with an unauthorized user, I get the following output from SSSD debug:
[ad_gpo_perform_hbac_processing] (0x4000): allow_key: SeRemoteInteractiveLogonRight
[ad_gpo_perform_hbac_processing] (0x4000): deny_key: SeDenyRemoteInteractiveLogonRight
[parse_policy_setting_value] (0x0400): No value for key [SeRemoteInteractiveLogonRight] found in gpo result
[ad_gpo_access_check] (0x0400): RESULTANT POLICY:
[ad_gpo_access_check] (0x0400): gpo_map_type: Remote Interactive
[ad_gpo_access_check] (0x0400): allowed_size = 0
[ad_gpo_access_check] (0x0400): denied_size = 3
[ad_gpo_access_check] (0x0400): denied_sids[0] = S-1-5-21-1107582786-1995068826-2594897426-4406
[ad_gpo_access_check] (0x0400): denied_sids[1] = S-1-5-21-1107582786-1995068826-2594897426-4281
[ad_gpo_access_check] (0x0400): denied_sids[2] = S-1-5-21-1107582786-1995068826-2594897426-4021
[ad_gpo_access_check] (0x0400): CURRENT USER:
[ad_gpo_access_check] (0x0400): user_sid = S-1-5-21-1107582786-1995068826-2594897426-5609
[ad_gpo_access_check] (0x0400): group_sids[0] = S-1-5-21-1107582786-1995068826-2594897426-5611
[ad_gpo_access_check] (0x0400): group_sids[1] = S-1-5-21-1107582786-1995068826-2594897426-513
[ad_gpo_access_check] (0x0400): group_sids[2] = S-1-5-21-1107582786-1995068826-2594897426-5612
[ad_gpo_access_check] (0x0400): group_sids[3] = S-1-5-11
[ad_gpo_access_check] (0x0400): POLICY DECISION:
[ad_gpo_access_check] (0x0400): access_granted = 1
[ad_gpo_access_check] (0x0400): access_denied = 0
[ad_gpo_access_done] (0x0400): GPO-based access control successful.
I'm not understanding what's happening here. It's as if my test user is allowed by default. Could this be due to a PAM config?
I was expecting to be denied login until I've explicitly setup a GPO to allow login :)
Any help is much appreciated!
1 week, 3 days
password not complex enough error for AD users
by robert wild
hi all,
i have got sssd on a centos 7 vm and i have got it working
https://www.linuxtechi.com/integrate-rhel7-centos7-windows-active-directory/
as when i do
id AD_user
it comes up with the uid, gid and all the group members that user belongs to also they can login on the logon page using there AD accounts
but when they open up a terminal window i want it so they can change there passwords
i have added to my "/etc/sssd/sssd.conf" file these two lines from this link
https://linux.die.net/man/5/sssd.conf
pwd_expiration_warning = 7
chpass_provider = ad
but they get this error when they try to change there passwords
[robert.wild@lon-p-xrdp01 ~]$ passwd
Changing password for user robert.wild.
Current Password:
New password:
Retype new password:
Password change failed. Server message: Please make sure the password meets the complexity constraints.
passwd: Authentication token manipulation error
[robert.wild@lon-p-xrdp01 ~]$
but i know i do meet the password requirements as i have added 13 characters including upper/lower/numbers/special characters
has anyone got sssd to change user passwords
thanks,
rob
1 week, 3 days