389-ds-base

Clone
Source Code
GIT

#51094 Container 389ds not supporting GSSAPI authentication method
Closed: wontfix 3 years ago by firstyear. Opened 3 years ago by robinr1.

Closed: wontfix
Reopen Issue

Issue Description

When trying to authenticate to the dirsrv running in a container 389ds/dirsrv pulled from docker.io using GSSAPI it fails with the error 

ldap_sasl_interactive_bind_s: Authentication method not supported (7)
    additional info: sasl mechanism not supported

supportedSASLMechanisms shows:

dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: ANONYMOUS

So I assume GSSAPI is not supported?

Package Version and Platform

  • os: openSUSE MicroOS
  • container runtime: podman 1.9.1
  • container image: docker.io/389ds/dirsrv:latest
  • 389 Directory Server Version: 1.4.4.1

Steps to reproduce

  1. Configure a kdc instance for use with ldap
  2. Add ldap/hostname@REALM principal and export to keytab in /data/config/krb5.keytab of container
  3. add a user principal
  4. run container with -e KRB5_KTNAME=/data/config/krb5.keytab and mount a configured /etc/krb5.conf
  5. try to authenticate with the user principal to the dirsrv:
ldapwhoami -Y GSSAPI -H ldaps://hostname:3636

Actual results

Authentication fails with:

SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Authentication method not supported (7)
    additional info: sasl mechanism not supported

Expected results

Authentication succeeds and dn of user is returned

Correct - in the container we do not install the gssapi libraries. This is because container networking is difficult to make work with krb/gssapi due to hostname/dns issues.

Metadata Update from @firstyear:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
3 years ago

Metadata Update from @firstyear:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)
3 years ago

Closed wontfix because I won't invest time into this, but feel free to re-open if you want to submit a PR.

Ok.. I will try..
But could you still assist a little with that?

I currently have :
- the cyrus-sasl-gssapi library included.
- set the nsslapd-localhost,
- the ldap/servername@REALM in a local keytab and
- the env var KRB5_KTNAMEcorrectly set to that keytab file.

When I now try 

kinit user
ldapwhoami -H ldaps://server:3636 -Y GSSAPI

I get

ldap_sasl_interactive_bind_s: Invalid credentials (49)
    additional info: SASL(-14): authorization failure:

I see no errors in the kdc logging.
In de the 389ds logging I see:

[15/May/2020:20:25:53.611577147 +0000] conn=20 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
[15/May/2020:20:25:53.612569890 +0000] conn=20 op=1 RESULT err=14 tag=97 nentries=0 etime=0.001098451, SASL bind in progress
[15/May/2020:20:25:53.612937310 +0000] conn=20 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
[15/May/2020:20:25:53.613070480 +0000] conn=20 op=2 RESULT err=14 tag=97 nentries=0 etime=0.000184366, SASL bind in progress
[15/May/2020:20:25:53.613279802 +0000] conn=20 op=3 BIND dn="" method=sasl version=3 mech=GSSAPI
[15/May/2020:20:25:53.613523630 +0000] conn=20 op=3 RESULT err=49 tag=97 nentries=0 etime=0.000288903 - SASL(-14): authorization failure: 
[15/May/2020:20:25:53.616733444 +0000] conn=20 op=4 UNBIND

After the kinit and before the ldapwhoami, klist displays 

05/15/20 20:25:44  05/16/20 20:25:44  krbtgt/REALM@REALM

and after ldapwhoami, klist displays

05/15/20 20:25:44  05/16/20 20:25:44  krbtgt/REALM@REALM
05/15/20 20:25:52  05/16/20 20:25:44  ldap/servername@REALM

So the server principal seems to be working correctly..

The user I authenticated with using kinit has a uid=user,cn=people,dc=realm-entry in the server. If i search the server (using plain auth) with filter (uid=<user>) in base cn=realm I get the correct user entry back. (just noticed the cn=realm is in lower case. Does that matter?)

So I have no clue as to what is going wrong now.

Ok.. I will try..
But could you still assist a little with that?

I can assist but I try to avoid krb at all costs :)

I currently have :
- the cyrus-sasl-gssapi library included.
- set the nsslapd-localhost,
- the ldap/servername@REALM in a local keytab and
- the env var KRB5_KTNAMEcorrectly set to that keytab file.
When I now try
kinit user
ldapwhoami -H ldaps://server:3636 -Y GSSAPI

I get
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-14): authorization failure:

There are two things you can do here. ldapwhoami -d <int> to get a log level, I use -d 1 as it's extremely verbose.

There is also an "undocumentd" krb client trace env var. You would do:

KRB5_TRACE=/dev/stderr ldapwhoami ...

And that will give you output for the krb logs. IIRC you can set a similar env for the ns-slapd side. to see what the server is processing.

I see no errors in the kdc logging.
In de the 389ds logging I see:
[15/May/2020:20:25:53.611577147 +0000] conn=20 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
[15/May/2020:20:25:53.612569890 +0000] conn=20 op=1 RESULT err=14 tag=97 nentries=0 etime=0.001098451, SASL bind in progress
[15/May/2020:20:25:53.612937310 +0000] conn=20 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
[15/May/2020:20:25:53.613070480 +0000] conn=20 op=2 RESULT err=14 tag=97 nentries=0 etime=0.000184366, SASL bind in progress
[15/May/2020:20:25:53.613279802 +0000] conn=20 op=3 BIND dn="" method=sasl version=3 mech=GSSAPI
[15/May/2020:20:25:53.613523630 +0000] conn=20 op=3 RESULT err=49 tag=97 nentries=0 etime=0.000288903 - SASL(-14): authorization failure:
[15/May/2020:20:25:53.616733444 +0000] conn=20 op=4 UNBIND

After the kinit and before the ldapwhoami, klist displays
05/15/20 20:25:44 05/16/20 20:25:44 krbtgt/REALM@REALM

and after ldapwhoami, klist displays
05/15/20 20:25:44 05/16/20 20:25:44 krbtgt/REALM@REALM
05/15/20 20:25:52 05/16/20 20:25:44 ldap/servername@REALM

So the server principal seems to be working correctly..
The user I authenticated with using kinit has a uid=user,cn=people,dc=realm-entry in the server. If i search the server (using plain auth) with filter (uid=<user>) in base cn=realm I get the correct user entry back. (just noticed the cn=realm is in lower case. Does that matter?)
So I have no clue as to what is going wrong now.

It's probably also worth checking the sasl mappings, as these often need adjustment for GSSAPI to work correctly. 

I0> dsconf instance sasl --help
usage: dsconf instance sasl [-h] {list,get-mechs,get,create,delete} ...

positional arguments:
  {list,get-mechs,get,create,delete}
                        sasl
    list                List available SASL mappings
    get-mechs           List available SASL mechanisms
    get                 get
    create              create
    delete              deletes the object
  • set the nsslapd-localhost,
  • the ldap/servername@REALM in a local keytab and

Also make sure these are the servername/hostname of the external interface of the container host/loadbalancer, not thehostname in the container.

Edited 3 years ago by firstyear

Thanks for the suggestions!

The hostname i set in nsslapd-localhost is indeed the one of the container-host, not the container itself.

I tried both -d 1 and the KRB5_TRACE but also there no errors other than

res_errno: 49, res_error: <SASL(-14): authorization failure: >, res_matched: <>

In the kbr5_traces of both server and client I only see successful ticket verification.

For the sasl mappings I only have the default 

Kerberos uid mapping
rfc 2829 dn syntax

of which Kerberos uid mapping seems to fit the job.
the user uid exists in the formuid=user,cn=people,dc=realm,dc=com which should be found by that one, if I understand it correctly. The principal for that user has the form of user@REALM.COM where the realm is in capitals and the ldap entry is in lowercase. Does that matter ?

If I recall propery, the default mappings don'tn actually work for gssapi, so you need to delete them and recreate them with a hardcoded realm.

I was already suspecting the sasl uid mappings, but according to https://doc.opensuse.org/documentation/leap/security/html/book.security/cha-security-kerberos.html#sec-security-kerberos-admin-ldap-sasl it should work with the default "Kerberos uid mapping".
Anyway, by your suggestion, I deleted that one and created a new one:

dn: cn=gssapi,cn=mapping,cn=sasl,cn=config
cn: gssapi
nsSaslMapBaseDNTemplate: dc=realm,dc=com
nsSaslMapFilterTemplate: (uid=\1)
nsSaslMapPriority: 100
nsSaslMapRegexString: \(.*\)@REALM.COM
objectClass: top
objectClass: nsSaslMapping

which has, as you can see, the realm 'hardcoded' in the DNTemplate
And then restarted the dirsrv to be sure.

But the problem remains exactly the same..
I have no clue as to where to search the problem now..

The only thing I can currently think of as possible cause is that the uid entry of the user I try to authenticate with, has a password set. And the krb principal entry also has a password set. Both passwords are the same, but that even shouldn't matter, as the uid entry should only serve as information about the user, in this case..?

No that shouldn't matter. The authentication comes from the GSSAPI channel, so we bypass the userPassword and all that jazz during that path in the sasl bind.

Honestly, this is exactly the kind of impossible to debug level of fun I expect from KRB, and is exactly why I don't like supporting it.

Regardless, the next step may be to run the ns-slapd with KRB5_TRACE=/dev/stderr. You could do this with the container by:

docker run --rm -i -t -v <your volume here>:/data <image> /bin/sh
then run:

KRB5_TRACE=/dev/stderr /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-localhost -d 266354688

Then try again.

For even more insane logs, you could try:

-d 266354689

As well,

With the insane logs turned on, I finally see that indeed the mapping is not working.
But for as far as I understand the logs, dirsrv seems to lose the realm somewhere and tries to map the string "username" instead of "username@REALM.COM":

First I see the ticket being receives without errors:

[210] 1590003476.439132: Decrypted AP-REQ with server principal ldap/server.realm.com@REALM.COM: aes256-cts/BC78
[210] 1590003476.439133: AP-REQ ticket: username@REALM.COM -> ldap/server.realm.com@REALM.COM, session key aes256-cts/50EA
[210] 1590003476.439134: Negotiated enctype based on authenticator: aes256-cts
[210] 1590003476.439135: Authenticator contains subkey: aes256-cts/6406
[210] 1590003476.439137: Creating AP-REP, time 1590003476.383772, subkey aes256-cts/8D4A, seqnum 348313821

Next I see it trying to do a bind:

[20/May/2020:19:37:56.440528189 +0000] - DEBUG - plugin_call_func - Calling plugin 'Multimaster replication preoperation plugin' #4 type 401
[20/May/2020:19:37:56.443125162 +0000] - DEBUG - send_ldap_result_ext - => 14::
[20/May/2020:19:37:56.446062492 +0000] - DEBUG - add_work_q - =>
[20/May/2020:19:37:56.448640479 +0000] - DEBUG - get_work_q - =>
[20/May/2020:19:37:56.451272757 +0000] - DEBUG - do_bind - =>
[20/May/2020:19:37:56.453859941 +0000] - DEBUG - do_bind - BIND dn="" method=163 version=3
[20/May/2020:19:37:56.456435243 +0000] - DEBUG - get_ldapmessage_controls_ext - => get_ldapmessage_controls
[20/May/2020:19:37:56.459159553 +0000] - DEBUG - get_ldapmessage_controls_ext - <= no controls
[20/May/2020:19:37:56.462207312 +0000] - DEBUG - slapi_control_present - => (looking for 2.16.840.1.113730.3.4.16)
[20/May/2020:19:37:56.465251452 +0000] - DEBUG - pagedresults_is_timedout - =>
[20/May/2020:19:37:56.468150331 +0000] - DEBUG - pagedresults_is_timedout - <= false 1
[20/May/2020:19:37:56.470716436 +0000] - DEBUG - slapi_control_present - <= 0 (NO CONTROLS)
[20/May/2020:19:37:56.473301105 +0000] - DEBUG - do_bind - version 3 method 163 dn 
[20/May/2020:19:37:56.475915449 +0000] - DEBUG - ids_sasl_check_bind - =>
[20/May/2020:19:37:56.478494818 +0000] - DEBUG - ids_sasl_mech_supported - =>
[20/May/2020:19:37:56.481061604 +0000] - DEBUG - ids_sasl_listmech - =>
[20/May/2020:19:37:56.483657344 +0000] - DEBUG - ids_sasl_listmech - sasl library mechs: GSS-SPNEGO,GSSAPI,LOGIN,PLAIN,ANONYMOUS
[20/May/2020:19:37:56.486238927 +0000] - DEBUG - ids_sasl_listmech - <=
[20/May/2020:19:37:56.488792919 +0000] - DEBUG - ids_sasl_mech_supported - <=
[20/May/2020:19:37:56.491397055 +0000] - DEBUG - ids_sasl_log - (5): GSSAPI server step 2
[20/May/2020:19:37:56.494237213 +0000] - DEBUG - plugin_call_func - Calling plugin 'Multimaster replication preoperation plugin' #4 type 401
[20/May/2020:19:37:56.497345755 +0000] - DEBUG - send_ldap_result_ext - <= 14
[20/May/2020:19:37:56.500425593 +0000] - DEBUG - ids_sasl_check_bind - <=
[20/May/2020:19:37:56.503329101 +0000] - DEBUG - plugin_call_func - Calling plugin 'Multimaster replication postoperation plugin' #1 type 501
[20/May/2020:19:37:56.505913008 +0000] - DEBUG - send_ldap_result_ext - => 14::
[20/May/2020:19:37:56.508716016 +0000] - DEBUG - add_work_q - =>
[20/May/2020:19:37:56.511331033 +0000] - DEBUG - get_work_q - =>
[20/May/2020:19:37:56.513932133 +0000] - DEBUG - do_bind - =>
[20/May/2020:19:37:56.516520639 +0000] - DEBUG - do_bind - BIND dn="" method=163 version=3
[20/May/2020:19:37:56.519257173 +0000] - DEBUG - get_ldapmessage_controls_ext - => get_ldapmessage_controls
[20/May/2020:19:37:56.521991741 +0000] - DEBUG - get_ldapmessage_controls_ext - <= no controls
[20/May/2020:19:37:56.525167469 +0000] - DEBUG - slapi_control_present - => (looking for 2.16.840.1.113730.3.4.16)
[20/May/2020:19:37:56.528341063 +0000] - DEBUG - pagedresults_is_timedout - =>
[20/May/2020:19:37:56.531404820 +0000] - DEBUG - pagedresults_is_timedout - <= false 1
[20/May/2020:19:37:56.534241917 +0000] - DEBUG - slapi_control_present - <= 0 (NO CONTROLS)
[20/May/2020:19:37:56.537340440 +0000] - DEBUG - do_bind - version 3 method 163 dn 
[20/May/2020:19:37:56.540291978 +0000] - DEBUG - ids_sasl_check_bind - =>
[20/May/2020:19:37:56.542876828 +0000] - DEBUG - ids_sasl_mech_supported - =>
[20/May/2020:19:37:56.545461787 +0000] - DEBUG - ids_sasl_listmech - =>
[20/May/2020:19:37:56.548047248 +0000] - DEBUG - ids_sasl_listmech - sasl library mechs: GSS-SPNEGO,GSSAPI,LOGIN,PLAIN,ANONYMOUS
[20/May/2020:19:37:56.550636325 +0000] - DEBUG - ids_sasl_listmech - <=
[20/May/2020:19:37:56.553185817 +0000] - DEBUG - ids_sasl_mech_supported - <=
[20/May/2020:19:37:56.555767792 +0000] - DEBUG - ids_sasl_log - (5): GSSAPI server step 3
[20/May/2020:19:37:56.558351870 +0000] - DEBUG - ids_sasl_canon_user - (user=username, realm=)
[20/May/2020:19:37:56.560916080 +0000] - DEBUG - send_ldap_result_ext - <= 14
[20/May/2020:19:37:56.563523984 +0000] - DEBUG - ids_sasl_check_bind - <=

where this line catches my attention:

[20/May/2020:19:37:56.558351870 +0000] - DEBUG - ids_sasl_canon_user - (user=username, realm=)

claiming that "realm" is empty. But I don't see how it loses the realm as it is clearly known at the point the ticket was received.

Then it tries to map the user:

[20/May/2020:19:37:56.566337672 +0000] - DEBUG - plugin_call_func - Calling plugin 'Multimaster replication postoperation plugin' #1 type 501
[20/May/2020:19:37:56.569562282 +0000] - DEBUG - sasl_map_domap - =>
[20/May/2020:19:37:56.572664902 +0000] - DEBUG - sasl_map_domap - Trying map [gssapi]
[20/May/2020:19:37:56.575589821 +0000] - DEBUG - sasl_map_check - =>
[20/May/2020:19:37:56.578204166 +0000] - DEBUG - sasl_map_check - regex: (.*)@REALM.COM, id: username didn't match
[20/May/2020:19:37:56.580841482 +0000] - DEBUG - sasl_map_check - <= 0
[20/May/2020:19:37:56.583437252 +0000] - DEBUG - sasl_map_domap - Trying map [rfc 2829 dn syntax]
[20/May/2020:19:37:56.586013786 +0000] - DEBUG - sasl_map_check - =>
[20/May/2020:19:37:56.588586984 +0000] - DEBUG - sasl_map_check - regex: ^dn:(.*), id: username, didn't match
[20/May/2020:19:37:56.591300285 +0000] - DEBUG - sasl_map_check - <= 0
[20/May/2020:19:37:56.594340759 +0000] - DEBUG - sasl_map_domap - <= (not mapped)

and fails as it looks to me that it tries to map "username" to (.*)@REAL.COM where it should try to map "username@REALM.COM".

as a result it now returns error 49:

[20/May/2020:19:37:56.597793637 +0000] - DEBUG - send_ldap_result_ext - => 49::
[20/May/2020:19:37:56.602608610 +0000] - DEBUG - add_work_q - =>
[20/May/2020:19:37:56.605317462 +0000] - DEBUG - get_work_q - =>
[20/May/2020:19:37:56.607936326 +0000] - DEBUG - do_unbind - =>
[20/May/2020:19:37:56.610672359 +0000] - DEBUG - get_ldapmessage_controls_ext - => get_ldapmessage_controls
[20/May/2020:19:37:56.613318103 +0000] - DEBUG - get_ldapmessage_controls_ext - <= no controls
[20/May/2020:19:37:56.615957384 +0000] - DEBUG - defbackend_noop - <==
[20/May/2020:19:37:56.618575566 +0000] - DEBUG - pagedresults_reset_timedout - =>
[20/May/2020:19:37:56.621156398 +0000] - DEBUG - pagedresults_reset_timedout - <=
[20/May/2020:19:37:56.623741888 +0000] - DEBUG - send_ldap_result_ext - <= 49
[20/May/2020:19:37:56.626331257 +0000] - DEBUG - ids_sasl_check_bind - <=
[20/May/2020:19:37:56.628972301 +0000] - DEBUG - plugin_call_func - Calling plugin 'Multimaster replication postoperation plugin' #1 type 501
[20/May/2020:19:37:56.855855767 +0000] - DEBUG - pagedresults_cleanup - =>
[20/May/2020:19:37:56.859526162 +0000] - DEBUG - pagedresults_cleanup - <= 0

Any idea why dirsrv "forgets" the realm ? if that is indeed what is happening..

I'm starting to see why you try to avoid krb :-)

When I delete the previous gssapi mapping and create a new one:

dn: cn=gssapi,cn=mapping,cn=sasl,cn=config
cn: gssapi
nsSaslMapBaseDNTemplate: dc=realm,dc=com
nsSaslMapFilterTemplate: (uid=\1)
nsSaslMapPriority: 100
nsSaslMapRegexString: \(.*\)
objectClass: top
objectClass: nsSaslMapping

authentication indeed succeeds:

ldapwhoami -H ldaps://server.realm.com:3636 -Y GSSAPI
SASL/GSSAPI authentication started
SASL username: username@REALM.COM
SASL SSF: 256
SASL data security layer installed.
dn: uid=username,ou=people,dc=realm,dc=com

which seems to confirm to me that dirsrv indeed loses the "@REALM.COM" part somewhere before it tries to map the user.
And suppose that should not happen.
I would also not like to keep this "(.*)" mapregexstring as it looks a bit broad to me and may pose a security risk somehow ?

Wow, that's pretty wild. Must be some deep issue in sasl or gssapi somewhere :|

Anyway, the .* map is fine because remember, the map doesn't authenticate you, it just relates you from the SASL auth to the ldap account. so you still need to pass whatever SASL auth requirements would exist, so either GSSAPI or PLAIN etc.

So as a map, it's fine. The only concern would be if you have a KRB trust relationship somewhere, and seperate realms, but that's a rare config, so I wouldn't worry to much about it.

I'm starting to see why you try to avoid krb :-)

Just wait until a user "can't login" and then can't diagnose why, and there are no logs available without command line magic .... :)

Since ids_sasl_canon_user() prints that message with empty realm at the very beginning of the function, the realm comes from CyrusSASL code that calls this callback. Since we do not see any successful bind completion in ids_sasl_bind_check(), it means canonicalization was called as a part of stepping through the server authentication process.

In gssapi SASL module there is a check in authentication negotiation step that whatever name is negotiated between client and server, should be valid from GSSAPI perspective. It is done by first canonicalizing the name with gss_canonicalize_name() and then importing the name-without-realm with gss_import_name(). If the names obtained by these two methods end up being the same, canonicalization callback will only work on the name without realm.

So, the behavior is effectively driven by GSSAPI configuration. For Kerberos mechanism, gss_import_name() for a name without realm the final call is krb5_parse_name_flags() with 0 flags. In this case the parsed name will have the default realm added, as defined by the hostrealm modules set in krb5.conf or in compile time defaults. This boils down to use of one of three methods in Linux: profile, dns, and domain, out of which only profile and dns do define a way to find a default realm.

profile method is the one that looks default_realm value:

[libdefaults]
default_realm = MY.REALM

dns method converts local hostname to a fully-qualified one. If that was successful, it then performs TXT record lookup for the _kerberos.$NAME record where name is the FQDN host name.

In the container, I think only default_realm value from [libdefaults] section of krb5.conf would be making any sense.

Finally, if the user is from the same realm, then indeed canonicalization function will not have realm explicitly provided and a mapping method that assumes default realm should be added. You might also want to enable falling back to other mapping methods (nsslapd-sasl-mapping-fallback is set to off by default) to be able to provide that explicit realm fallback.

In FreeIPA, we do define three mappings and enable SASL mapping fallback to allow all three to work:

  • Full Principal mapping,
dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config
cn: Full Principal
nsSaslMapBaseDNTemplate: dc=ipa,dc=test
nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2)
nsSaslMapPriority: 10
nsSaslMapRegexString: \(.*\)@\(.*\)
objectClass: top
objectClass: nsSaslMapping
  • Name Only mapping:
dn: cn=Name Only,cn=mapping,cn=sasl,cn=config
cn: Name Only
nsSaslMapBaseDNTemplate: dc=ipa,dc=test
nsSaslMapFilterTemplate: (krbPrincipalName=&@IPA.TEST)
nsSaslMapPriority: 10
nsSaslMapRegexString: ^[^:@]+$
objectClass: top
objectClass: nsSaslMapping
  • and 'ID Overridden Principal' mapping. This one is pretty much specific to IPA's support of trusted Active Directory users and is not needed in any other environments:
dn: cn=ID Overridden Principal,cn=mapping,cn=sasl,cn=config
cn: ID Overridden Principal
nsSaslMapBaseDNTemplate: cn=default trust view,cn=views,cn=accounts,dc=ipa,dc=test
nsSaslMapFilterTemplate: (&(ipaoriginaluid=\1@\2)(objectclass=ipaUserOverride) )
nsSaslMapPriority: 20
nsSaslMapRegexString: \(.*\)@\(.*\)
objectClass: top
objectClass: nsSaslMapping

All of these mappings are generated at deployment time. If you have support for aliases in your Kerberos deployment, chances are that you need both 'name only' and 'full principal' mappings.

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

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/4147

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.

Login to comment on this ticket.

Metadata
None
None
None
None
None
None
None
None
None
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.