On Thu, 2017-04-20 at 22:54 +0200, Simon Pichugin wrote:
Hello William,
I think my question is for you in the first place.
It regards the default attributes for cn=config feature.
Version tested: 389-ds-base-1.3.6.1-9.el7.x86_64
During TET troubleshooting I've faced two issues:
1. By default, we have:
[root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D "cn=Directory
manager"
-w Secret123 -b "cn=config" "objectclass=*" | grep
nsslapd-allowed-sasl-mechanisms
nsslapd-allowed-sasl-mechanisms:
Empty value.
We can modify it and set something. (I'll skip the output, it works as expected.
And after this, the server allows to do like this:
[root@qeos-126 dirsrv-tet-install]# ldapmodify -h localhost -p 389 -D "cn=Directory
manager" -w Secret123
dn: cn=config
changetype: modify
delete: nsslapd-allowed-sasl-mechanisms
modifying entry "cn=config"
[root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D "cn=Directory
manager"
-w Secret123 -b "cn=config" "objectclass=*" | grep
nsslapd-allowed-sasl-mechanisms
nsslapd-allowed-sasl-mechanisms:
Pretty sure the SASL mechs can't be written to: they are returned from
https://pagure.io/389-ds-base/blob/master/f/ldap/servers/slapd/saslbind.c...
And that only allows setting from mechs discovered by cyrus-sasl, and
mechs that are from plugins that register to
slapi_register_supported_saslmechanism() . The allowed mechs parameter
is the list that is checked to see if we'll allow using it, and that's
called from ids_sasl_getopt. During the set in libglobs, it looks like
we check that the mech is a real name supported by SASL, so perhaps test
with values like PLAIN, GSSAPI instead?
> 2. Second one is a known issue, but still I'd like to
clarify the expected behaviour:
> [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D
"cn=Directory manager"
> -w Secret123 -b "cn=config" "objectclass=*" | grep
nsslapd-allowed-sasl-mechanisms
> nsslapd-allowed-sasl-mechanisms: A
> [root@qeos-126 dirsrv-tet-install]# ldapmodify -h localhost -p 389 -D
"cn=Directory manager" -w Secret123
> dn: cn=config
> changetype: modify
> add: nsslapd-allowed-sasl-mechanisms
> nsslapd-allowed-sasl-mechanisms: B
> [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D
"cn=Directory manager"
> -w Secret123 -b "cn=config" "objectclass=*" | grep
nsslapd-allowed-sasl-mechanisms
> nsslapd-allowed-sasl-mechanisms: B
> So it wouldn't be a multivalued attribute? if
we'll do the 'add' operation, it would replace the existing value with a new.
> Please, comment of a both cases. First looks more like a
bug to me though, and I will file it if you'll confirm it.
Anyway, it looks like in libglobs.c, that it expects a comma seperated
list, it's not multivalued. The reason is that this single attribute is
returned in config_get_allowed_sasl_mechs(); during the ids_sasl_getopt
call, which SASL_CB_GETOPT expects a specific format.
I imagine this is because it's easier to store it as one line in the
config, and requires less parsing each SASL request to go from
multivalue to one line, so it's an efficiency thing.
Does that help explain the answer to your problems?
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane