11:16 a.m.
Hi,
I am attempting to have SSSD do logins to my OpenLDAP 2.6.3 installation, however, I get
"permission denied" when trying to log in because SSSD is asking for a password
policy, which the server does not appear to have by default. Notably, we don't really
care what "policy" the server will claim to have, because password
authentication is delegated via SASL to another server which ensures strong passwords. So
I just need something that will "get past" whatever checks SSSD is doing. What
LDIF config can I add to my configuration to allow SSSD to let users log in properly?
The error from `journalctl -u slapd` is shown below:
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 fd=11 ACCEPT from
IP=10.8.8.202:41516 (IP=0.0.0.0:389)
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=0 SRCH base="" scope=0
deref=0 filter="(objectClass=*)"
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=0 SRCH attr=* altServer
namingContexts supportedControl supportedExtension supportedFeatures
supportedLDAPVersion>
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=0 SEARCH RESULT tag=101 err=0
qtime=0.000020 etime=0.000271 nentries=1 text=
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=1 BIND
dn="cn=admin,dc=clab,dc=lab" method=128
Nov 01 18:16:58 ldapserver00 slapd[105481]: slap_global_control: unrecognized control:
1.3.6.1.4.1.42.2.27.8.5.1
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=1 BIND
dn="cn=admin,dc=clab,dc=lab" mech=SIMPLE bind_ssf=0 ssf=0
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=1 RESULT tag=97 err=0
qtime=0.000028 etime=0.000136 text=
Nov 01 18:16:58 ldapserver00 slapd[105481]: get_filter: conn 2239 unknown attribute
type=sudoHost (17)
Nov 01 18:16:58 ldapserver00 slapd[105481]: get_ssa: conn 2239 unknown attribute
type=sudoHost (17)
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SRCH
base="ou=users,dc=clab,dc=lab" scope=2 deref=0
filter="(&(?objectClass=sudoRole)(|(&(!(?sudoHost=*))(cn=de>
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SRCH attr=objectClass
objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs sudoRunAsUser
sudoRunAs>
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SEARCH RESULT tag=101 err=0
qtime=0.000016 etime=0.000326 nentries=0 text=
TIA!
12:54 p.m.
--On Tuesday, November 1, 2022 7:16 PM +0000 jarett(a)bioteam.net wrote:
Hi,
I am attempting to have SSSD do logins to my OpenLDAP 2.6.3 installation,
however, I get "permission denied" when trying to log in because SSSD is
asking for a password policy, which the server does not appear to have by
default. Notably, we don't really care what "policy" the server will
claim to have, because password authentication is delegated via SASL to
another server which ensures strong passwords. So I just need something
that will "get past" whatever checks SSSD is doing. What LDIF config can
I add to my configuration to allow SSSD to let users log in properly?
You could simply load the ppolicy overlay in you configuration so that the
control is available, regardless of whether you intend to use it.
However nothing in the log you provided shows there was any issue due to
SSSD requesting it.
The BIND operation was successful:
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=1 RESULT tag=97
err=0 qtime=0.000028 etime=0.000136 text=
The SEARCH operation was successful:
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SEARCH RESULT
tag=101 err=0 qtime=0.000016 etime=0.000326 nentries=0 text=
The biggest issue seems to be that it is configured to send invalid search
filters, causing ZERO results to be returned (nentries=0 above):
ov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SRCH
base="ou=users,dc=clab,dc=lab" scope=2 deref=0
filter="(&(?objectClass=sudoRole)(|(&(!(?sudoHost=*))(cn=de>
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SRCH
attr=objectClass objectClass cn sudoCommand sudoHost sudoUser sudoOption
sudoRunAs sudoRunAsUser sudoRunAs>
Note that "sudoRole" objectClass, "sudoHost" attribute is not found.
Note
that "cn=de>" is not a valid filter.
Regards,
Quanah
11:41 p.m.
On Nov 1, 2022, at 2:54 PM, Quanah Gibson-Mount
<quanah(a)fast-mail.org> wrote:
--On Tuesday, November 1, 2022 7:16 PM +0000 jarett(a)bioteam.net wrote:
> Hi,
>
> I am attempting to have SSSD do logins to my OpenLDAP 2.6.3 installation,
> however, I get "permission denied" when trying to log in because SSSD is
> asking for a password policy, which the server does not appear to have by
> default. Notably, we don't really care what "policy" the server will
> claim to have, because password authentication is delegated via SASL to
> another server which ensures strong passwords. So I just need something
> that will "get past" whatever checks SSSD is doing. What LDIF config can
> I add to my configuration to allow SSSD to let users log in properly?
You could simply load the ppolicy overlay in you configuration so that the control is
available, regardless of whether you intend to use it.
How is this done? In the LTB distribution there is a ppolicy ldif in the schema directory
of openldap/etc; no such file exists for "vanilla" OpenLDAP and I'm not even
sure if it would be compatible.
The documentation describes the password policy overlay, but appears to be in conf format
rather than the ldifs we use now and there's no indication as to what sort of
"default" options would normally be associated with permitting a client to bind,
check passwords for login and allow or reject the login.
https://www.openldap.org/doc/admin26/overlays.html (section 12.10.2) I imagine there must
be a reference for this somewhere as it has to be one of the most common LDAP use cases?
However nothing in the log you provided shows there was any issue due to SSSD requesting
it.
The BIND operation was successful:
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=1 RESULT tag=97 err=0
qtime=0.000028 etime=0.000136 text=
The SEARCH operation was successful:
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SEARCH RESULT tag=101 err=0
qtime=0.000016 etime=0.000326 nentries=0 text=
The biggest issue seems to be that it is configured to send invalid search filters,
causing ZERO results to be returned (nentries=0 above):
ov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SRCH
base="ou=users,dc=clab,dc=lab" scope=2 deref=0
filter="(&(?objectClass=sudoRole)(|(&(!(?sudoHost=*))(cn=de>
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SRCH attr=objectClass
objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs sudoRunAsUser
sudoRunAs>
Note that "sudoRole" objectClass, "sudoHost" attribute is not found.
Note that "cn=de>" is not a valid filter.
Those were just truncated lines. Here is another example without the truncation:
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 fd=14 ACCEPT from
IP=10.8.8.202:35250 (IP=0.0.0.0:389)
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 op=0 SRCH base="" scope=0
deref=0 filter="(objectClass=*)"
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 op=0 SRCH attr=* altServer
namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion
supportedSASLMechanisms domainControllerFunctionality defaultNamingContext lastUSN
highestCommittedUSN
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 op=0 SEARCH RESULT tag=101 err=0
qtime=0.000018 etime=0.000221 nentries=1 text=
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 op=1 BIND
dn="cn=admin,dc=clab,dc=lab" method=128
Nov 02 06:40:46 ldapserver00 slapd[109046]: slap_global_control: unrecognized control:
1.3.6.1.4.1.42.2.27.8.5.1
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 op=1 BIND
dn="cn=admin,dc=clab,dc=lab" mech=SIMPLE bind_ssf=0 ssf=0
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 op=1 RESULT tag=97 err=0
qtime=0.000018 etime=0.000106 text=
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 op=2 UNBIND
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1005 fd=14 closed
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 fd=14 ACCEPT from
IP=10.8.8.202:35260 (IP=0.0.0.0:389)
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=0 SRCH base="" scope=0
deref=0 filter="(objectClass=*)"
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=0 SRCH attr=* altServer
namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion
supportedSASLMechanisms domainControllerFunctionality defaultNamingContext lastUSN
highestCommittedUSN
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=0 SEARCH RESULT tag=101 err=0
qtime=0.000016 etime=0.000145 nentries=1 text=
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=1 BIND
dn="cn=admin,dc=clab,dc=lab" method=128
Nov 02 06:40:46 ldapserver00 slapd[109046]: slap_global_control: unrecognized control:
1.3.6.1.4.1.42.2.27.8.5.1
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=1 BIND
dn="cn=admin,dc=clab,dc=lab" mech=SIMPLE bind_ssf=0 ssf=0
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=1 RESULT tag=97 err=0
qtime=0.000018 etime=0.000092 text=
Nov 02 06:40:46 ldapserver00 slapd[109046]: get_filter: conn 1006 unknown attribute
type=sudoHost (17)
Nov 02 06:40:46 ldapserver00 slapd[109046]: get_ssa: conn 1006 unknown attribute
type=sudoHost (17)
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=2 SRCH
base="ou=users,dc=clab,dc=lab" scope=2 deref=0
filter="(&(?objectClass=sudoRole)(|(&(!(?sudoHost=*))(cn=defaults))(?sudoHost=ALL)(?sudoHost=ldapclient)(?sudoHost=ldapclient)(?sudoHost=10.8.8.202)(?sudoHost=10.8.8.0/24)(?sudoHost=fe80::f9:c8ff:fe92:990d)(?sudoHost=fe80::/64)(?sudoHost=+*)))"
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=2 SRCH attr=objectClass
objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs sudoRunAsUser
sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp
Nov 02 06:40:46 ldapserver00 slapd[109046]: conn=1006 op=2 SEARCH RESULT tag=101 err=0
qtime=0.000018 etime=0.000227 nentries=0 text=
Nov 02 06:42:03 ldapserver00 slapd[109046]: conn=1006 op=3 UNBIND
Nov 02 06:42:03 ldapserver00 slapd[109046]: conn=1006 fd=14 closed
root@ldapserver00:/tmp#
I note in the SSSD documentation it says it will not perform authentication binds in
cleartext. I think(?) I am running the server with SSL but not START-TLS.
Jarett T. DeAngelis, MS
Scientific Systems Engineer
Email: jarett(a)bioteam.net <mailto:jarett@bioteam.net>
M: +1.646.417.2165
bioteam.net <https://www.bioteam.net/>
7:15 a.m.
--On Wednesday, November 2, 2022 2:41 AM -0500 Jarett DeAngelis
<jarett(a)bioteam.net> wrote:
> You could simply load the ppolicy overlay in you configuration so
that
> the control is available, regardless of whether you intend to use it.
How is this done? In the LTB distribution there is a ppolicy ldif in the
schema directory of openldap/etc; no such file exists for "vanilla"
OpenLDAP and I'm not even sure if it would be compatible.
<https://www.openldap.org/doc/admin25/appendix-upgrading.html>
"B.2. ppolicy overlay
The overlay now implements version 10 of the ppolicy draft in full. This
includes the notion of a password administrator where applicable (as
determined by having a manage permission to the userPassword attribute) and
skips certain processing when there is no valid policy in effect or where
the operation is initiated by a password administrator. Many attributes are
now tagged with NO-USER-MODIFICATION in the schema, requiring the use of
relax control to modify them.
In OpenLDAP 2.4 the slapo-ppolicy(5) overlay relied on a separate schema
file to be included for it to function. This schema is now implemented
internally in the slapo-ppolicy module. When upgrading slapd.conf(5)
deployments the include statement for the schema must be removed. For
slapd-config(5) deployments, the config database must be exported via
slapcat and the old ppolicy schema removed from the export. The resulting
config database can then be imported."
No idea why the LTB project would ship a retired schema file, you'd need to
ask them.
The documentation describes the password policy overlay, but appears
to
be in conf format rather than the ldifs we use now and there's no
indication as to what sort of "default" options would normally be
associated with permitting a client to bind, check passwords for login
and allow or reject the login.
https://www.openldap.org/doc/admin26/overlays.html (section 12.10.2) I
imagine there must be a reference for this somewhere as it has to be one
of the most common LDAP use cases?
I would note again that nothing in your log indicates that the lack of the
ppolicy overlay is the source of any problems. There is simply a warning
thrown and then the operation proceeds and completes normally with no
issues reported.
Since ppolicy is a database specific module, you would first add it to the
module load section of the global configuration (assuming it was built as a
module) and then instantiate it as an overlay on top of the backend, as
demonstrated in the code for test022-ppolicy:
dn: olcOverlay=ppolicy,olcDatabase={#}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
I don't know which database number your MDB database is, so you'd need to
fill that in above. There's no need to specify anything for the
configuration past that unless you intend to actually make use of the
overlay.
But again, nothing indicates the lack of it being present as the source of
any issues in your deployment.
Those were just truncated lines. Here is another example without the
truncation:
The logs again show that the sudo schema is missing from the system, but
that all operations executed do so correctly. Nothing in your logs
indicates any issues being caused by the lack of the ppolicy overlay being
instantiated.
So, if you want to remove all the reported issues from your logs, you can
instantiate ppolicy, and you can load the sudo schema. That may better
enable you to track down the actual root cause by removing extraneous noise.
Regards,
Quanah
12:48 a.m.
New subject: Antw: [EXT] Re: SSSD looking for password policy: "unrecognized control"
>> Quanah Gibson-Mount <quanah(a)fast-mail.org> schrieb am
01.11.2022 um 20:54
in
Nachricht <AA5643E98105A35D696CE959(a)[192.168.1.15]>:
‑‑On Tuesday, November 1, 2022 7:16 PM +0000 jarett(a)bioteam.net wrote:
> Hi,
>
> I am attempting to have SSSD do logins to my OpenLDAP 2.6.3 installation,
> however, I get "permission denied" when trying to log in because SSSD is
> asking for a password policy, which the server does not appear to have by
> default. Notably, we don't really care what "policy" the server will
> claim to have, because password authentication is delegated via SASL to
> another server which ensures strong passwords. So I just need something
> that will "get past" whatever checks SSSD is doing. What LDIF config can
> I add to my configuration to allow SSSD to let users log in properly?
You could simply load the ppolicy overlay in you configuration so that the
control is available, regardless of whether you intend to use it.
However nothing in the log you provided shows there was any issue due to
SSSD requesting it.
The BIND operation was successful:
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=1 RESULT tag=97
err=0 qtime=0.000028 etime=0.000136 text=
The SEARCH operation was successful:
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SEARCH RESULT
tag=101 err=0 qtime=0.000016 etime=0.000326 nentries=0 text=
The biggest issue seems to be that it is configured to send invalid search
filters, causing ZERO results to be returned (nentries=0 above):
ov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SRCH
base="ou=users,dc=clab,dc=lab" scope=2 deref=0
filter="(&(?objectClass=sudoRole)(|(&(!(?sudoHost=*))(cn=de>
Nov 01 18:16:58 ldapserver00 slapd[105481]: conn=2239 op=2 SRCH
attr=objectClass objectClass cn sudoCommand sudoHost sudoUser sudoOption
sudoRunAs sudoRunAsUser sudoRunAs>
Note that "sudoRole" objectClass, "sudoHost" attribute is not found.
Note
that "cn=de>" is not a valid filter.
For some strange reason sssd starts do query the sudo schema, even if it was
not configured on the server, typically flooding the logs with invalid
requests.
I added the schema here, just to silence the errors...
Regards,
Quanah
11:36 a.m.
New subject: Antw: [EXT] Re: SSSD looking for password policy: "unrecognized control"
On Wed, Nov 02, 2022 at 08:48:39AM +0100, Ulrich Windl wrote:
For some strange reason sssd starts do query the sudo schema, even if
it was
not configured on the server, typically flooding the logs with invalid
That's the default. You need to add "sudo_provider = none" to the sssd
config under the domain section that's using ldap as an id_provider.
220
days inactive
221
days old
openldap-technical@openldap.org
5 comments
5 participants
participants (5)
-
Jarett DeAngelis -
jarett＠bioteam.net
-
Paul B. Henson -
Quanah Gibson-Mount -
Ulrich Windl