Connection to ad via ldap failing
by Nordgren, Bryce L -FS
Well, I guess the title is a little misleading. The ldap connection is working like a champ. I configured sssd to bind using my own credentials, and that's working. The searches are successful and return the correct result.
Things I don't understand:
* Sssd performs two ldap searches for my username, not one.
* Using wireshark, I don't even see it trying to bind to AD using the account it finds (twice).
* sssd fails to authenticate me, but the logs seems to indicate to me that everything it tried succeeded.
This is on a VM with a minimal install of Fedora 19. The setup roughly follows https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate... with local modifications to enable id mapping. I'm attaching edited versions of sssd.conf, sssd_pam.log, sssd_nss.log, and the output of wireshark (stupidly named sssd.log.) pam and nss are both at debug level 9.
Does anyone have any suggestions as to what I should try?
Bryce
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
10 years, 2 months
SSSD 1.8.x with samba4 DC
by Richard Connon
Hi,
I'm using sssd 1.8.4 (debian package) as a client for a samba4 domain,
currently with one DC. The domain has unix UIDs and GIDs stored so no
idmapping is required.
The config I have (so far) is this:
[sssd]
config_file_version = 2
services = nss, pam
domains = DOMAIN
[nss]
[pam]
[domain/DOMAIN]
auth_provider = krb5
chgpass_provider = krb5
dns_search_domain = ads.domain.tld
id_provider = ldap
krb5_realm = ADS.DOMAIN.TLD
ldap_sasl_authid = HOST$(a)ADS.DOMAIN.TLD
ldap_sasl_mech = GSSAPI
ldap_schema = rfc2307bis
ldap_user_name = sAMAccountName
So far NSS seems to be working (kind of) but is very slow to retrieve
each user/group the first time and is very slow for queries where the
user/group does not exist.
The only messages appearing in any relevant logs are the following 2:
In sssd_DOMAIN.log:
(Fri Feb 14 18:07:37 2014) [sssd[be[DOMAIN]]] [load_backend_module]
(0x0010): Error (2) in module (ldap) initialization (sssm_ldap_autofs_init)!
In syslog file auth.log:
Feb 14 19:20:06 unifi sssd_be: GSSAPI Error: Miscellaneous failure (see
text) (Matching credential (ldap/ads.domain.tld(a)DOMAIN.TLD) not found)
The former seems to be quite harmless but the latter repeats quite
frequently and seems to suggest SSSD is trying to use an invalid
kerberos ticket for the LDAP connection.
This principal name is invalid for two reasons, first there is no LDAP
service on "ads.domain.tld" it is on "dc02.ads.domain.tld", second
"DOMAIN.TLD" is not the name of my realm, it is "ADS.DOMAIN.TLD"
Does anyone have any idea what causes the latency in responding to NSS
queries and whether I need to worry about the GSSAPI errors?
Finally I have not yet succeeded in getting this setup to work for PAM.
I haven't been able to try very easily due to the NSS latency issues.
Thanks in advance,
Richard
10 years, 2 months
Auth not working with OpenDJ backend LDAP server
by Ganesh Hariharan
I configured the centos client with system-config-auth, essentially I need
to login from terminal or over ssh with the username and credentials of my
ldap server.... please help
and below is the configuration
[domain/default]
ldap_id_use_start_tls = True
cache_credentials = True
ldap_search_base = dc=sysopminds,dc=com
krb5_realm = EXAMPLE.COM
krb5_server = kerberos.example.com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldaps://10.0.0.6
ldap_tls_cacertdir = /etc/openldap/cacerts
[sssd]
services = nss, pam
config_file_version = 2
domains = default
[nss]
[pam]
[sudo]
[autofs]
[ssh]
[pac]
10 years, 2 months
SSSD slow to start, slow to work
by Erinn Looney-Triggs
I have a RHEL 5.10 system running sssd version sssd-1.5.1-70.el5, SSSD
is configured as a client of two IPA servers, config will be at the bottom.
This thing has been chugging along for years at this point without
issue, but performance hit the wall this morning and SSSD appears to be
the issue.
logins using kerberos are taking an extremely long time, I expect
because of user data enumeration, sudo passwords are taking an extremely
long time, su passwords etc.
Cranking up debugging is not revealing anything glaring to my untrained
eye.
Running an anonymous ldapsearch against the IPA servers (suggested in
debug documentation) is not possible as anonymous binds are disabled on
the server end. Though the connection does go through enough to indicate
that such is the case.
As well restarting SSSD takes a very long time, ~1-2 minutes when
compared with other systems on the same platform/hardware (seconds).
Any folks have ideas?
Please CC me as I am subscribed to the digest.
Thanks,
-Erinn
Config:
[sssd]
config_file_version = 2
# Number of times services should attempt to reconnect in the
# event of a crash or restart before they give up
reconnection_retries = 3
debug_level = 10
# If a back end is particularly slow you can raise this timeout here
sbus_timeout = 30
services = nss, pam
domains = example.com
[nss]
# The following prevents SSSD from searching for the root user/group in
# all domains (you can add here a comma-separated list of system
accounts that
# are always going to be /etc/passwd users, or that you want to filter out).
filter_groups = root,apache
filter_users = root,apache
reconnection_retries = 3
[pam]
reconnection_retries = 3
[domain/example.com]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
chpass_provider = ipa
ipa_server = _srv_, ipa.example.com
ldap_tls_cacert = /etc/ipa/ca.crt
enumeration = true
10 years, 2 months