3:05 a.m.
On Thu, Aug 17, 2017 at 10:04:08PM -0400, Mark London wrote:
Hi all - Sorry to bother you with this problem that I've been
working all
day to fix. I've been using SSSD on Redhat for many years, using LDAP to
authenticate a Windows domain. With a new server with Redhat 7, I'm seeing
intermittent login failures for only a small set of users. There is
nothing I can find common to these user accounts. The failures happen 24
hours a day (it's authentication for an IMAP mail server, so logins occur
constant). I've flushed all the SSSD caching files and started from scratch,
and that did not help. I turned on SSSD debugging, and here's an example
that shows LDAP authentication failing for a user, but only a small while
afterwards, it works. I googled, the ldap error message, and could only
find it for people who were always constantly not able to to authenticate.
Not an intermittent problem, like mine.
Any recommendations for other ways to debug this problem (domain server LDAP
logging?) would be appreciated. If there is not the proper forum to ask
this question, please advise me on a better place to post it (besides
stackoverflow, which I'll do as a last resort). My sssd.conf file , occurs
after these log entries.
--------------------------------------------------------------------------------
(Thu Aug 17 21:01:30 2017) [sssd[be[PSFC]]] [sdap_ldap_connect_callback_add]
(0x1000): New LDAP connection to [ldaps://psfcd.psfc.mit.edu:636/??base]
with fd[24].
(Thu Aug 17 21:01:30 2017) [sssd[be[PSFC]]] [fo_set_port_status] (0x0100):
Marking port 636 of server 'psfcd.psfc.mit.edu' as 'working'
(Thu Aug 17 21:01:30 2017) [sssd[be[PSFC]]] [set_server_common_status]
(0x0100): Marking server 'psfcd.psfc.mit.edu' as 'working'
(Thu Aug 17 21:01:30 2017) [sssd[be[PSFC]]] [fo_set_port_status] (0x0400):
Marking port 636 of duplicate server 'psfc.psfc.mit.edu' as 'working'
(Thu Aug 17 21:01:30 2017) [sssd[be[PSFC]]] [simple_bind_send] (0x0100):
Executing simple bind as: CN=Smith\, John,OU=Smith Group,OU=PSFC
Users,DC=psfc,DC=mit,DC=edu
(Thu Aug 17 21:01:30 2017) [sssd[be[PSFC]]] [simple_bind_done] (0x1000):
Server returned no controls.
(Thu Aug 17 21:01:30 2017) [sssd[be[PSFC]]] [simple_bind_done] (0x0400):
Bind result: Invalid credentials(49), 80090308: LdapErr: DSID-0C09042F,
comment: AcceptSecurityContext error, data 52e, v2580
I hope this doesn't sound condescending, but are you sure it's not just
a mistyped password?
Because Invalid Credentials is effectively 'can't bind to LDAP', the
'data' field gives an extended error description. In this case it's 52e
which is IIRC really 'wrong credentials'. Other codes include 'can't
login at this time', 'expired credentials' etc..
>
> (Thu Aug 17 21:02:16 2017) [sssd[be[PSFC]]] [fo_set_port_status] (0x0400):
> Marking port 636 of duplicate server 'psfcd.psfc.mit.edu' as
'working'
> (Thu Aug 17 21:02:16 2017) [sssd[be[PSFC]]] [simple_bind_send] (0x0100):
> Executing simple bind as: CN=Smith\, John,OU=Smith Group,OU=PSFC
> Users,DC=psfc,DC=mit,DC=edu
> (Thu Aug 17 21:02:16 2017) [sssd[be[PSFC]]] [simple_bind_done] (0x1000):
> Server returned no controls.
> (Thu Aug 17 21:02:16 2017) [sssd[be[PSFC]]] [simple_bind_done] (0x0400):
> Bind result: Success(0), no errmsg set
> --------------------------------------------------------------------------------
>
> i tried increasing the SSSD debugging level, without anything interesting
> appearing. If it would help, though , I'll post it, with all the complete
> lines.
>
> I should add that i have windows password account locking disabled. I've
> attached my sssd.conf file below. I am aware that sssd can authenticate
> directly to AD. However, the domain server and mail server are on separate
> networks, and I have no idea if ports can't be opened on the firewall, to
> allow this to happen. Opening up the LDAP port on the firewall, seemed to
> be the obviously easier choice. Thanks very much! - Mark
>
> --------------------------------------------------------------------------------
> [sssd]
> config_file_version = 2
> reconnection_retries = 3
> sbus_timeout = 30
> services = nss, pam
>
> domains = PSFC
>
> [nss]
> filter_groups = root
> filter_users = root
> reconnection_retries = 3
> debug_level = 0
>
> ; entry_cache_timeout = 600
> ; entry_cache_nowait_timeout = 300
>
> [pam]
> reconnection_retries = 3
> debug_level = 0
>
> [domain/PSFC]
> description = LDAP domain with AD server
> enumerate = false
> min_id = 501
> cache_credentials = false
> debug_level = 7
> ldap_purge_cache_timeout = 0
> ldap_enumeration_refresh_timeout = 300
> ldap_referrals = false
> id_provider = ldap
> chpass_provider = none
> auth_provider = ldap
> ldap_tls_reqcert = allow
> ldap_uri =
ldaps://psfcd1.psfc.mit.edu,ldaps://psfcd2.psfc.mit.edu,ldaps://psfcd3.ps...
> ldap_schema = rfc2307bis
> ldap_search_base = dc=psfc,dc=mit,dc=edu
> ldap_user_search_base = dc=psfc,dc=mit,dc=edu
> ldap_group_search_base = dc=psfc,dc=mit,dc=edu
> ldap_default_bind_dn = CN=ADldapreadonly,OU=Computer Group,OU=PSFC
> Users,DC=psfc,DC=mit,DC=edu
> ldap_default_authtok_type = password
> ldap_default_authtok = MY_PASSWORD
> ldap_user_object_class = person
> ldap_user_name = sAMAccountName
> ldap_user_uid_number = msSFU30UidNumber
> ldap_user_gid_number = msSFU30GidNumber
> ldap_user_home_directory = msSFU30HomeDirectory
> ldap_user_shell = msSFU30LoginShell
> ldap_user_principal = userPrincipalName
> ldap_group_object_class = group
> ldap_group_member = msSFU30PosixMember
> ldap_user_member_of = msSFU30PosixMemberOf
> ldap_group_name = name
> ldap_group_gid_number = msSFU30GidNumber
> ldap_force_upper_case_realm = True
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org