ldap_sasl_mech EXTERNAL and SSL client authc
by Michael Ströder
HI!
Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with
StartTLS or LDAPS using client certs?
In a project they have certs in all systems anyway (because of using puppet)
and I'd like to let the sssd instances on all the systems authenticate to the
LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid
having to set/configure passwords for each system's sssd.
Ciao, Michael.
9 years
Startup segfault loop of domain_be on Ubuntu 14.04
by Chris Hartman
Hi guys,
Ubuntu 14.04 x86_64
SSSD 1.11.5
Active Directory backend
I've been experiencing this problem for a few weeks with no luck in
troubleshooting it. During boot, the sssd_be process will continually spawn
and crash due to a segfault. When it gets stuck in this loop, domain
account login is almost impossible (local accounts still work).
I've attached sanitized logs and my sssd.conf file. Please have a look and
let me know what you think. Thanks!
-Chris
9 years, 7 months
SSSD with AD provider - can't obtain group information in subdomain
by 杉山昌治
Hello
I'm struggle with configuration of sssd to retrieve group information
defined in a subdomain.
I would have your support to solve my issue.
Here is my AD configuration. There are 3 AD servers.
Root Domain labroot.example.com (just for top AD management)
Sub Domain labsso.labroot.example.com (user, global group and universal
group are defined here)
Subsub Domain labbu.labsso.labroot.example.com (local domain group is
defined here)
I created a user and groups in those AD servers as below.
User/Groups in Domain sso.example.com
========================
User test_user (MemberOf=G-Group-Server)
Group G-Role-ISOps-Server (Type: Global Group, Members=test_user,
MemberOf=U-Role-ISOps-Server)
Group U-Role-ISOps-Server (Type: Universal Group,
Members=G-Role-ISOps-Server)
User/Groups in Domain sso.example.com
========================
Group D-Role-Server (Type: Domain Local Group,
Members=U-Role-ISOps-Server)
As for SSSD, I tried to use both "1.11.6" and "1.12.1" with "AD provider"
as backend.
I expected to get all groups (G-Role-ISOps-Server, U-Role-ISOps-Server and
D-ISOps-Server) as a result of
"id test_user" command.
But I could not find domain local group (D-Role-ISOps-Server) in groups of
the user "test_user".
as the result of "id test_user" command.
I also could not find any members as the result of "getent group
D-Role-ISOps-Server" command.
I tried to use single domain (sso-ad-ad) and multiple domains (sso-ad-ad
and bu-ad-ad) in sssd configuration, but the result is the almost same.
(when I use sso-ad-ad domain only, I could not get anything as result of
"getent group d-role-isops-server").
# id test_user
uid=638201126(test_user) gid=638200513(domain users)
groups=638200513(domain
users),638201113(g-role-server),638201118(u-role-server),638200512(domain
admins)
# getent group d-role-isops-server
d-role-isops-server:*:927601110:
I'm not sure how SSSD AD provider searches group information based on
members/memberOf attributes, I suspect missing "memberOf" in universal
group (U-Role-*) and "member of domain local group" (U-Role-ISOps-Server)
is out of scope of LABBU domain might be clue of my issue.
Please advise me what's wrong on my configuration and resolution of my
issue.
Thanks in advance.
Shoji
*** Configurations and LDAP search results ***
sssd.conf file
==========
[sssd]
config_file_version = 2
services = nss, pam
domains = sso-ad-ad, bu-ad-ad
# domains = sso-ad-ad
[nss]
fallback_homedir = /home/SSO/%u
default_shell = /bin/bash
[pam]
[domain/sso-ad-ad]
id_provider = ad
auth_provider = ad
access_provider = ad
ad_server = jpbw0-in00-is82.labsso.labroot.isops.example.com
ad_hostname = jpbw0-in00-is82.labsso.labroot.isops.example.com
ldap_schema = ad
ad_enable_gc = true
ldap_id_mapping = true
debug_level = 1
[domain/bu-ad-ad]
id_provider = ad
auth_provider = ad
chpass_provider = ad
ad_server = jpbw0-in00-is81.labbu.labsso.labroot.isops.example.com
ad_hostname = jpbw0-in00-is81.labbu.labsso.labroot.isops.example.com
ldap_id_mapping = true
debug_level = 1
LDAP Search in Global Catalog of LABSSO
==================================
I can search the domain local group in the global catalog.
[root@jpbl0-in00-is11 providers]# ldapsearch -Y GSSAPI -LLL -H "ldap://
jpbw0-in00-is82.labsso.labroot.isops.example.com:3268" -b
"DC=labsso,DC=labroot,DC=isops,DC=example,DC=com"
"(&(name=d-role-isops-server)(objectclass=group)(name=*))"
SASL/GSSAPI authentication started
SASL username: host/
jpbl0-in00-is11.lab.isops.ibm.com(a)LABSSO.LABROOT.ISOPS.EXAMPLE.COM
SASL SSF: 56
SASL data security layer installed.
dn:
CN=D-Role-ISOps-Server,OU=BU0-ISOps,OU=Roles,DC=labbu,DC=labsso,DC=labroot,DC=isops,DC=example,DC=com
objectClass: top
objectClass: group
cn: D-Role-ISOps-Server
description: Server Team
distinguishedName:
CN=D-Role-ISOps-Server,OU=BU0-ISOps,OU=Roles,DC=labbu,DC=labsso,DC=labroot,DC=isops,DC=example,DC=com
instanceType: 0
whenCreated: 20131029185150.0Z
whenChanged: 20131029185448.0Z
uSNCreated: 17964
uSNChanged: 18034
name: D-Role-ISOps-Server
objectGUID:: YflnJQk4IUK4YUAHO43J6w==
objectSid:: AQUAAAAAAAUVAAAAml0mRju+InNXWri7VgQAAA==
sAMAccountName: D-Role-ISOps-Server
sAMAccountType: 536870912
groupType: -2147483644
objectCategory:
CN=Group,CN=Schema,CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com
dSCorePropagationData: 16010101000000.0Z
LDAP Search in LABSSO
====================
I can not search the domain local group in normal domain.
[root@jpbl0-in00-is11]# ldapsearch -Y GSSAPI -LLL -H "ldap://
jpbw0-in00-is82.labsso.labroot.isops.example.com" -b
"DC=labsso,DC=labroot,DC=isops,DC=example,DC=com"
"(&(name=d-role-isops-server)(objectclass=group)(name=*))"
SASL/GSSAPI authentication started
SASL username: host/
jpbl0-in00-is11.lab.isops.example.com(a)LABSSO.LABROOT.ISOPS.EXAMPLE.COM
SASL SSF: 56
SASL data security layer installed.
# refldap://
labbu.labsso.labroot.isops.example.com/DC=labbu,DC=labsso,DC=labroot,
DC=isops,DC=example,DC=com
# refldap://
DomainDnsZones.labsso.labroot.isops.example.com/DC=DomainDnsZones,DC=
labsso,DC=labroot,DC=isops,DC=example,DC=com
9 years, 7 months
Problems with High RIDs in large Active Directory environment
by Thomas Moore
I work in an Active Directory environment where new SIDs have RIDs over
280,000 when attempting to set ldap_idmap_range_size in sssd.conf anything
larger that 268204 causes the following errors in the log file
(Wed Jul 30 10:38:44 2014) [sssd[be[DOMAIN.EDU]]] [load_backend_module]
(0x0010): Error (5) in module (ad) initialization (sssm_ad_id_init)!
(Wed Jul 30 10:38:44 2014) [sssd[be[DOMAIN.EDU]]] [be_process_init]
(0x0010): fatal error initializing data providers
(Wed Jul 30 10:38:44 2014) [sssd[be[DOMAIN.EDU]]] [main] (0x0010): Could
not initialize backend [5]
I have tested in both Ubuntu 14.04 and CentOS 7.0 with the same results.
Any help is greatly appreciated!
9 years, 7 months
sssd services terminated
by Daniel Jung
Hi,
Running centos 6 with sssd-1.8.0-32.el6.x86_64 and
sssd-client-1.8.0-32.el6.x86_64.
This particular problem seems to pop now and then. I looked thru the
maillist/googled and there seems to be number of posts with similar
symptoms, but didnt see exact bug number or recommended actions to resolve
this issue.
Could you advise please? The problem resolved after restarting sssd.
sssd.log
(Tue Jul 29 16:46:06 2014) [sssd] [mt_svc_sigkill] (0x0010): [LDAP][22259]
is not responding to SIGTERM. Sending SIGKILL.
(Tue Jul 29 16:48:18 2014) [sssd] [mt_svc_sigkill] (0x0010): [nss][22262]
is not responding to SIGTERM. Sending SIGKILL.
(Tue Jul 29 16:48:18 2014) [sssd] [mt_svc_exit_handler] (0x0010): Process
[nss], definitely stopped!
(Tue Jul 29 19:01:17 2014) [sssd] [monitor_quit] (0x0010): Monitor received
Terminated: terminating children
sssd_nss.log
(Tue Jul 29 16:48:18 2014) [sssd[nss]] [sss_dp_init] (0x0010): Failed to
connect to monitor services.
(Tue Jul 29 16:48:18 2014) [sssd[nss]] [sss_process_init] (0x0010): fatal
error setting up backend connector
(Tue Jul 29 16:48:18 2014) [sssd[nss]] [sss_dp_init] (0x0010): Failed to
connect to monitor services.
(Tue Jul 29 16:48:18 2014) [sssd[nss]] [sss_process_init] (0x0010): fatal
error setting up backend connector
(Tue Jul 29 16:48:18 2014) [sssd[nss]] [sss_dp_init] (0x0010): Failed to
connect to monitor services.
(Tue Jul 29 16:48:18 2014) [sssd[nss]] [sss_process_init] (0x0010): fatal
error setting up backend connector
sssd_LDAP.log
(Tue Jul 29 16:48:18:940606 2014) [sssd[be[LDAP]]]
[confdb_get_domain_internal] (0x0020): No enumeration for [LDAP]!
(Tue Jul 29 16:48:19:181330 2014) [sssd[be[LDAP]]] [be_process_init]
(0x0020): No Session module provided for [LDAP] !!
(Tue Jul 29 16:48:19:181468 2014) [sssd[be[LDAP]]] [be_process_init]
(0x0020): No host info module provided for [LDAP] !!
(Tue Jul 29 16:48:19:181550 2014) [sssd[be[LDAP]]] [main] (0x0020): Backend
provider (LDAP) started!
(Tue Jul 29 19:01:17:891413 2014) [sssd[be[LDAP]]]
[confdb_get_domain_internal] (0x0020): No enumeration for [LDAP]!
(Tue Jul 29 19:01:17:934694 2014) [sssd[be[LDAP]]] [be_process_init]
(0x0020): No Session module provided for [LDAP] !!
(Tue Jul 29 19:01:17:934781 2014) [sssd[be[LDAP]]] [be_process_init]
(0x0020): No host info module provided for [LDAP] !!
(Tue Jul 29 19:01:17:934831 2014) [sssd[be[LDAP]]] [main] (0x0020): Backend
provider (LDAP) started!
9 years, 7 months
rpc.gssd vs gssproxy
by Ondrej Valousek
Hi List,
Sorry for the bit OT question.
How do I enable gssproxy on F20? When I enable USE_GSSPROXY in /etc/sysconfig/nfs and
systemctl start nfs-secure, rpc.gssd is started instead :(
Same story in CentOS 7
Thanks,
Ondrej
9 years, 8 months
SSSD current config dump
by Felipe Pereira
Is there a way to dump all config settings?
I'd like to know the defaults configured for everything I didn't set in the
sssd.conf.
tia
--
Felipe
9 years, 8 months
sssd_sudo receives 0 rules but ldap search returns 5, what is wrong?
by Teemu Keinonen
Hello,
I’m configuring CentOS 6.5 server to authenticate users and sudo rights against local Samba 4.1.8 (compiled from source). Sssd is 1.9.2 from package repository. User authentication works OK, I can log in with user that exists only in Samba but sudoing with the same user fails. After hours of trying I still can’t get it right, sssd_sudo receives 0 rules from samba. Doing ldapsearch with criteria from logs do return sudoer entries as below. Am I missing something obvious?
Below are (in order) ldapsearch, ssssd.conf and sssd_default.log (part which I think relevant).
[root@dc1 sssd]# ldapsearch -h dc1 -Y GSSAPI -b OU=SUDOers,DC=teemu,DC=local '(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=Host01)(sudoHost=Host01.example.com)(sudoHost=192.168.0.21)(sudoHost=192.168.0.0/24)(sudoHost=fe80::786b:f4ff:fe87:3314)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*))))'
SASL/GSSAPI authentication started
SASL username: administrator(a)TEEMU.LOCAL
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <OU=SUDOers,DC=teemu,DC=local> with scope subtree
# filter: (&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=Host01)(sudoHost=Host01.example.com)(sudoHost=192.168.0.21)(sudoHost=192.168.0.0/24)(sudoHost=fe80::786b:f4ff:fe87:3314)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*))))
# requesting: ALL
#
# defaults, SUDOers, teemu.local
dn: CN=defaults,OU=SUDOers,DC=teemu,DC=local
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here
instanceType: 4
whenCreated: 20140625194645.0Z
whenChanged: 20140625194645.0Z
uSNCreated: 3798
uSNChanged: 3798
name: defaults
objectGUID:: vrCxbL/QkUGFyZWvELWj/w==
objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=teemu,DC=local
sudoOption: env_keep+=SSH_AUTH_SOCK
distinguishedName: CN=defaults,OU=SUDOers,DC=teemu,DC=local
# %wheel, SUDOers, teemu.local
dn: CN=%wheel,OU=SUDOers,DC=teemu,DC=local
objectClass: top
objectClass: sudoRole
cn: %wheel
instanceType: 4
whenCreated: 20140626094147.0Z
whenChanged: 20140626094147.0Z
uSNCreated: 3800
uSNChanged: 3800
name: %wheel
objectGUID:: jpGX5AmGUkimPw1yl+oZkA==
objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=teemu,DC=local
sudoUser: %wheel
sudoHost: ALL
sudoCommand: ALL
distinguishedName: CN=%wheel,OU=SUDOers,DC=teemu,DC=local
# reima, SUDOers, teemu.local
dn: CN=reima,OU=SUDOers,DC=teemu,DC=local
objectClass: top
objectClass: sudoRole
cn: reima
instanceType: 4
whenCreated: 20140625194650.0Z
whenChanged: 20140625194650.0Z
uSNCreated: 3799
uSNChanged: 3799
name: reima
objectGUID:: U1paZdVOSke2zmInSenFTg==
objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=teemu,DC=local
sudoUser: reima
sudoHost: ALL
sudoCommand: ALL
distinguishedName: CN=reima,OU=SUDOers,DC=teemu,DC=local
# search result
search: 4
result: 0 Success
# numResponses: 4
# numEntries: 3
Sssd.conf:
[sssd]
services = nss, pam, sudo
config_file_version = 2
domains = default
debug_level = 10
[nss]
[pam]
[sudo]
debug_level = 10
[domain/default]
debug_level = 10
id_provider = ldap
sudo_provider = ldap
ldap_schema = rfc2307bis
ldap_referrals = false
ldap_uri = ldap://dc1.teemu.local
ldap_search_base = cn=Users,dc=teemu,dc=local
ldap_sudo_search_base = ou=sudoers,dc=teemu,dc=local
ldap_force_upper_case_realm = true
# See man sssd-simple
access_provider = simple
# Uncomment to check for account expiration in DC
# access_provider = ldap
# ldap_access_order = expire
# ldap_account_expire_policy = ad
# Enumeration is discouraged for performance reasons.
# enumerate = true
ldap_default_bind_dn = cn=Administrator,cn=Users,dc=teemu,dc=local
ldap_default_authtok = XXXXXX
auth_provider = krb5
chpass_provider = krb5
ldap_sasl_mech = gssapi
ldap_sasl_authid = dc1$(a)TEEMU.LOCAL
krb5_realm = TEEMU.LOCAL
krb5_server = dc1.teemu.local
krb5_kpasswd = dc1.teemu.local
ldap_krb5_keytab = /etc/krb5.sssd.keytab
ldap_user_object_class = user
ldap_user_name = samAccountName
ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName
ldap_user_shell = loginShell
ldap_group_object_class = group
sssd_default.log:
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_sudo_refresh_connect_done] (0x0400): SUDO LDAP connection successful
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_sudo_load_sudoers_next_base] (0x0400): Searching for sudo rules with base [ou=sudoers,dc=teemu,dc=local]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)\
(sudoHost=dc1)(sudoHost=dc1)(sudoHost=10.0.2.15)(sudoHost=10.0.2.0/24)(sudoHost=192.168.1.1)(sudoHost=192.168.1.0/24)(sudoHost=fe80::a00:27ff:fede:ba44)(sudoHost=fe80::/6\
4)(sudoHost=fe80::a00:27ff:fef3:dc1)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*))))][ou=sudoers,dc=teemu,dc=local].
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoCommand]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoHost]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoUser]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOption]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsUser]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsGroup]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotBefore]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotAfter]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOrder]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 12
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0xfed4e0], connected[1], ops[0xff7c20], ldap[0xfedba0]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_get_generic_ext_done] (0x1000): Total count [0]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_sudo_load_sudoers_process] (0x0400): Receiving sudo rules with base [ou=sudoers,dc=teemu,dc=local]
(Fri Jun 27 14:56:27 2014) [sssd[be[default]]] [sdap_sudo_load_sudoers_done] (0x0400): Received 0 rules
9 years, 8 months
(no subject)
by Lance Reed
I am having a problem with sssd (1.9.2) and passwords expiration
against IPA v.3.0.0-37.
I have setup sssd to use IPA with LDAP not Kerberos since this is in
EC2 and I don’t want to deal with assigning tickets to each ephemeral
host. So far things are working great, with the one exception that
due to IPA using “krbPasswordExpiration” instead of “shadowExpire”
breaks the usage of expired passwords. I tried setting
“ldap_pwd_policy = mit_kerberos”, which does allow expired passwords
to be recognized, but then breaks the users ability to change
passwords. I suspect it causes sssd to use al Kerberos code paths,
which won’t work in this case. If anyone has any ideas on this I
would appreciate and feedback. Thanks in advance.
example conf
[domain/LDAP]
enumerate = true
cache_credentials = True
debug_level = 9
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_schema = IPA
ldap_uri = ldaps://ipa-use-1b.ec2.example.net
ldap_user_search_base = dc=example,dc=net
ldap_id_use_start_tls = true
tls_reqcert = demand
ldap_tls_cacert = /etc/ipa/ca.crt
ldap_user_ssh_public_key = ipaSshPubKey
#ldap_pwd_policy = shadow
#ldap_user_shadow_expire = krbPasswordExpiration
#ldap_pwd_policy = mit_kerberos
[sssd]
services = nss, pam, ssh
config_file_version = 2
domains = LDAP
[nss]
[pam]
[sudo]
[autofs]
[ssh]
[pac]
9 years, 8 months
Using sssd on HPC cluster without direct ldap access
by Jean-Baptiste Denis
Hello everybody,
I've got an HPC cluster on a private network without access to our LDAP servers
for reasons I don't have any influence on at the moment. Users connect to
special nodes called submit nodes to submit (eh!) jobs on the cluster. Those
nodes have access to the public facing network (hence our LDAP servers) and the
cluster private network.
At the moment, /etc/passwd /etc/group and /etc/shadow are simply dumped on all
cluster nodes. I'd like to move away from this setup.
How to update the submit nodes to use sssd with an ldap auth_provider should not
cause any trouble. I'm concerned about the nodes accessible on the private network.
I could configure submit nodes as ldap slaves, but there are security aspects in
that setup I'd like to avoid. My question is quite simple : is there a way to
leverage the "sssdified" submit nodes on other nodes using some kind of
relay/proxy ?
Any suggestion is welcome !
Jean-Baptiste
9 years, 8 months