Need help with debugging curious SSSD/LDAP problem that only affects certain users.

[Mark London]

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

(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

[Jakub Hrozek]

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

[Mark London]

No, sorry.  Can't be incorrect passwords.  The people aren't even typing in their
passwords.  These are connections being made by email clients constantly running. 
Different platforms and email clients. 🙁

Sent from my iPhone

>  On Aug 18, 2017, at 4:05 AM, Jakub Hrozek <jhrozek(a)redhat.com&gt;
> wrote:
>  
> > 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
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org

[Jakub Hrozek]

Hmm, but I'm really not sure how to debug this. You said you only see
this with a new server. When you look at the logs from the working and
the non-working server, are there any differences?

For example, I see that the user's DN contains a space and a comma. Does
the issue only happen with these users on the affected server?

To rule out the password issue, it would be trivial to build a sssd test
build that dumps the password into the logs. This could be used to rule
out e.g. PAM stack issues and make sure the correct password is passed
on to the sssd.

On Fri, Aug 18, 2017 at 09:53:46AM -0400, Mark London wrote:
> No, sorry.  Can't be incorrect passwords.  The people aren't even typing in
their passwords.  These are connections being made by email clients constantly running. 
Different platforms and email clients. 🙁
> 
> Sent from my iPhone
> 
> > On Aug 18, 2017, at 4:05 AM, Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote:
> > 
> >> 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
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org

[Mark London]

Hi - The old server is gone, so I can't test it.  Yes, the DN contains a 
space and comma for everybody, i.e. last name, first name.

I might consider building SSSD from the source, to have it print out the 
password.   Strangely, the problem has at least temporarily abated.    
That could be simply because people having taken Friday off!    Go 
figure.   So I will go back to doing my own work for a while, and try 
over the weekend to add more debugging output. - Mark

On 8/18/2017 10:23 AM, Jakub Hrozek wrote:
>  Hmm, but I'm really not sure how to debug this. You said you only
> see
>  this with a new server. When you look at the logs from the working and
>  the non-working server, are there any differences?
>
>  For example, I see that the user's DN contains a space and a comma. Does
>  the issue only happen with these users on the affected server?
>
>  To rule out the password issue, it would be trivial to build a sssd test
>  build that dumps the password into the logs. This could be used to rule
>  out e.g. PAM stack issues and make sure the correct password is passed
>  on to the sssd.
>
>  On Fri, Aug 18, 2017 at 09:53:46AM -0400, Mark London wrote:
> > No, sorry.  Can't be incorrect passwords.  The people aren't even typing in
> their passwords.  These are connections being made by email clients constantly running. 
> Different platforms and email clients. 🙁
> >
> > Sent from my iPhone
> >
> >> On Aug 18, 2017, at 4:05 AM, Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote:
> >>
> >>> 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
> >> _______________________________________________
> >> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> >> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org

[Jakub Hrozek]

On Fri, Aug 18, 2017 at 01:04:37PM -0400, Mark London wrote:
>  Hi - The old server is gone, so I can't test it.  Yes, the DN
> contains a
>  space and comma for everybody, i.e. last name, first name. 
Right, but then it doesn't constitute a pattern of failing users vs.
passing users right?

>  
>  I might consider building SSSD from the source, to have it print out the
>  password.   Strangely, the problem has at least temporarily abated.    That
>  could be simply because people having taken Friday off!    Go figure.   So I
>  will go back to doing my own work for a while, and try over the weekend to
>  add more debugging output. - Mark 
Good luck, I think adding a line to sss_authtok_set_password() would be
the simplest way to go.

Let us know if you need any help instrumenting the build!