SSSD / sssd

#2536 sssd issues STARTTLS even with GSSAPI in use
Closed: Duplicate Opened by steuer.

Closed: Duplicate
Reopen Issue

We are using GSSAPI with sssd on the client side with Heimdal/OpenLDAP on the server side. The problem is that SSSD issues a STARTTLS command to the ldap server when trying to change the password using "passwd" (which of course is passed to sssd through pam).
The ldap server is also used as the id_provider and access_provider which all works well. So there does not seem to be a general problem with the GSSAPI-secured channel between sssd and the server.

As it was suggested on the sssd irc channel, I have set minssf in the ldap.conf without any success. (If it were such a problem, the id_provider and access_provider should not work as well, I guess).

Below, you find the output of the ldap server:

Dec 18 19:32:40 ipa1 slapd[76060]: conn=1502 op=8 SRCH base="ou=ldap,dc=lipa,dc=de" scope=2 deref=0 filter="(&(uid=steuer)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))"
Dec 18 19:32:40 ipa1 slapd[76060]: conn=1502 op=8 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell userPrincipalName cn memberOf modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap
Dec 18 19:32:40 ipa1 slapd[76060]: <= bdb_equality_candidates: (uid) not indexed
Dec 18 19:32:40 ipa1 slapd[76060]: conn=1502 op=8 SEARCH RESULT tag=101 err=0 nentries=1 text=
Dec 18 19:32:40 ipa1 slapd[76060]: conn=1502 op=9 SRCH base="ou=ldap,dc=lipa,dc=de" scope=2 deref=0 filter="(&(member=uid=steuer,ou=users,ou=ldap,dc=lipa,dc=de)(objectClass=posixGroup)(cn=*))"
Dec 18 19:32:40 ipa1 slapd[76060]: conn=1502 op=9 SRCH attr=objectClass cn userPassword gidNumber modifyTimestamp modifyTimestamp
Dec 18 19:32:40 ipa1 slapd[76060]: <= bdb_equality_candidates: (member) not indexed
Dec 18 19:32:40 ipa1 slapd[76060]: conn=1502 op=9 SEARCH RESULT tag=101 err=0 nentries=0 text=
Dec 18 19:32:40 ipa1 slapd[76060]: conn=1502 op=10 SRCH base="ou=ldap,dc=lipa,dc=de" scope=2 deref=0 filter="(&(gidNumber=10000)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))"
Dec 18 19:32:40 ipa1 slapd[76060]: conn=1502 op=10 SRCH attr=objectClass cn userPassword gidNumber member modifyTimestamp modifyTimestamp
Dec 18 19:32:40 ipa1 slapd[76060]: <= bdb_equality_candidates: (gidNumber) not indexed
Dec 18 19:32:40 ipa1 slapd[76060]: conn=1502 op=10 SEARCH RESULT tag=101 err=0 nentries=1 text=
Dec 18 19:32:40 ipa1 slapd[76060]: conn=1511 fd=30 ACCEPT from IP=185.10.36.9:42676 (IP=0.0.0.0:389)
Dec 18 19:32:40 ipa1 slapd[76060]: conn=1511 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Dec 18 19:32:40 ipa1 slapd[76060]: conn=1511 op=0 STARTTLS
Dec 18 19:32:40 ipa1 slapd[76060]: conn=1511 op=0 RESULT oid= err=0 text=
Dec 18 19:32:40 ipa1 slapd[76060]: conn=1511 fd=30 closed (TLS negotiation failure)

The important parts of the sssd conf are:

ldap_sasl_mech = gssapi
ldap_sasl_authid = host/sr1ff1.lipa.de
ldap_user_principal = userPrincipalName
ldap_krb5_keytab = /etc/krb5.keytab
ldap_krb5_init_creds = true
ldap_krb5_ticket_lifetime = 86400
sudo_provider = ldap
access_provider = ldap
ldap_access_order = host
chpass_provider = ldap
id_provider = ldap
auth_provider = krb5

Things like ldapwhoami etc. work well, I even can successfully change the ldap password with ldappasswd and GSSAPI.

SASL/GSSAPI authentication started
SASL username: steuer@LIPA.DE
SASL SSF: 56
SASL data security layer installed.
dn:uid=steuer,ou=users,ou=ldap,dc=lipa,dc=de

I therefore assume that the problem lies within sssd.

Thanks alot for your help!

First, sorry for the delayed response. The bug report came just before the Christmas break.

I can confirm this bug, although I think it's a bit of an edge case -- why do use auth_provider=krb5 and chpass_provider=krb5? Wouldn't it be more natural to also use chpass_provider=ldap?

btw when authenticating or changing password, the sssd always creates a new connection, the identity connection is not reused.

_comment0: First, sorry for the delayed response. The bug report came just before the Christmas break.

I can confirm this bug, although I think it's a bit of an edge case -- why do use auth_provider=krb5 and chpass_provider=krb5? Wouldn't it be more natural to also use chpass_provider=krb5?

btw when authenticating or changing password, the sssd always creates a new connection, the identity connection is not reused. => 1423575765224898

Hello,

reason for us having ldap as the chpass provider is that we have LDAP as a backend for kerberos and the tools (smb5krb, etc) sychronize the ldap password to kerberos, not vice versa. Therefore, if the users use "passwd" the ldap password is changed and the overlay changes the kerberos password as well.

It is a common usecase to use both passwords as you use Kerberos for logging in etc, but tools like graylog2 use the plain LDAP password for authentication. Therefore you cannot rely only on the Kerberos password.

Thanks,
Heri

Thanks.

Sounds like dupe of https://fedorahosted.org/sssd/ticket/489 btw

Needs to be triaged and potentially fixed along with #489, so moving to the same bucket for now.

We'll triage 1.13 beta during devconf.cz

milestone: NEEDS_TRIAGE => SSSD 1.13 beta

Fields changed

milestone: SSSD 1.13 beta => SSSD 1.13 backlog

Mass-moving tickets not planned for the 1.13 release to 1.14

milestone: SSSD 1.13 backlog => SSSD 1.14 beta

Fields changed

rhbz: => todo

We haven't seen any more complains about this issue and unfortunately our milestones are already getting quite full.

Unless there would be an external patch submitted, this won't make 1.14.

milestone: SSSD 1.14 beta => SSSD 1.15 beta
sensitive: => 0

This is a duplicate of #489

resolution: => duplicate
status: new => closed

Metadata Update from @steuer:
- Issue set to the milestone: SSSD Future releases (no date set yet)

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3578

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.
Metadata
None
None
None
None
Normal
defect
SSSD
1.11.6
0
0
todo
0
0
0
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.