In some cases it is very useful to allow a plugin to change the target_dn before the bind credentials are checked, this allows to implement things like virtual trees with different based DNs that use the original entry for bind purposes, or allow non standard identifiers to be translated into the proper DN directly by a plugin.
Untested patch to allow pre_bind plugins to alter the DN 0001-Allow-a-pre_bind-plugin-to-map-a-DN-to-another.patch
Unfortunately, it does not work as expected just with the patch: 0001-Allow-a-pre_bind-plugin-to-map-a-DN-to-another.patch...
I assume "AD like binds (where a name instead of a DN is provided)" indicates something like "administrator". The "do_bind" function expects the bind dn is a valid dn. If not, the bind fails immediately. This is based upon RFC 4511. {{{ BindRequest ::= [APPLICATION 0] SEQUENCE { version INTEGER (1 .. 127), name LDAPDN, authentication AuthenticationChoice }
An LDAPDN is defined to be the representation of a Distinguished Name (DN) after encoding according to the specification in [RFC4514].
LDAPDN ::= LDAPString -- Constrained to <distinguishedName> [RFC4514]
}}} It might be doable if you don't mind to send the "name" with some fake DN like "uid=NAME" and your plug-in correctly parse it and build the right DN...
This is not what I saw experimentaly. I used this command: $ ldapsearch -x -D admin -w password -s base -b ""
And I definitely got into do_bind w/o problem, ended up in the freeipa pre-bind plugin and sourced the string "admin" out of the DN by simply calling slapi_pblock_get(pb, SLAPI_BIND_TARGET, dn)
Maybe by default config_get_dn_validate_strict() is false ?
See https://fedorahosted.org/389/browser/ldap/servers/slapd/bind.c?rev=411ed8590f49b2b02ebb68d4f7819d28b6602221#L145
FWIW I do mind setting uid=NAME, because I cannot control the format, if I could I would just send the right DN :-)
Replying to [comment:3 simo]:
What I'm trying to say is this command line breaks the LDAP protocol... -D option takes DN format string only...
Replying to [comment:5 nhosoi]:
Replying to [comment:3 simo]: This is not what I saw experimentaly. I used this command: $ ldapsearch -x -D admin -w password -s base -b "" What I'm trying to say is this command line breaks the LDAP protocol... -D option takes DN format string only...
I know it does, but AD allows that, and I want to be able to emulate that to appease non-standard clients that are tested only against AD :-/
I'm not sure how AD is handling it... For instance, the DS Admin Server takes, e.g., "admin" to login, which is handled in the client (Admin Server) side. It searches the DS with "uid=admin" in o=netscaperoot, and bind the DS with the returned DN...
AD handles it. It allows -D "name" and -D "name@domain".
Simo, do you need to have ldapsearch work with -D "name", or do you just need some way to authenticate without the full DN? We could use a SASL mech like LOGIN that would allow you to pass in just the user name e.g. ldapsearch -Y LOGIN -X u:username -w password . . .
What I want is to allow the same mechanism that works with Ad to work with IPA. So what I need is to get in input arbitrary strings for the DN and pass them on to pre_bind plugins.
After pre_bind plugins have run the DN may have changed, if so use the DN the plugin provided.
Once the plugin is done (and it has, or not, changed the Bind target DN) proper validation of the DN can be done, as you should have a proper DN at this point.
My current implementation attempt is attached to this FreeIPA ticket: https://fedorahosted.org/freeipa/ticket/5289 You can see how I translate the provided "string" into a valid DN. This code may need to be improved to handle other forms but that will not matter from the POV of what is needed from the DS side.
note that I am not asking to implement this in DS, mostly because DS does not have enough information to know where and how it should look up users, as it does not have any canonical domain name or user tree.
It depends on the changes being proposed here.
Replying to [comment:8 rmeggins]:
Thanks, Rich. So, setting non-DN to name in the Bind Request is allowed? If it is allowed, we need to change the behaviour that handles the given name... Currently, we strictly disallows the value that is not a valid DN.
Simo, is this Rich's proposal acceptable for your purpose? I.e., should the method be LDAP_AUTH_SIMPLE? {{{ @@ -1417,7 +1464,13 @@ static int ipapwd_pre_bind(Slapi_PBlock pb) ret = ipapwd_getEntry(dn, &entry, (char ) attrs_list); if (ret) { LOG("failed to retrieve user entry: %s\n", dn); - return 0; + + / Try AD-compat option */ + if (method == LDAP_AUTH_SIMPLE) { + ret = ipapwd_ad_compat_bind(pb, dn, attrs_list, &dn, &entry); + } + + if (ret) return 0; }
/* Check if the principal is not expired */
}}} In addition, I think the current dn in the above code is NULL if it tries to bind with non-DN string since Slapi_DN *sdn usually normalizes as a dn and the dn normalization fails.
So, I think we have to do a little trick to pass it via Slapi_DN by setting it to sdn->udn in do_bind and retrieved by slapi_sdn_get_udn in the ipa plug-in to avoid the dn normalization.
Replying to [comment:10 nhosoi]:
Simo, do you need to have ldapsearch work with -D "name", or do you just need some way to authenticate without the full DN?
I can't choose anything. Ad accepts this:
ldapsearch -x -D FLATNAME\Username -w <password>
So I want to be able to do the same.
We could use a SASL mech like LOGIN that would allow you to pass in just the user name e.g. ldapsearch -Y LOGIN -X u:username -w password . . .
Nope it would be useless.
Simo, is this Rich's proposal acceptable for your purpose? I.e., should the method be LDAP_AUTH_SIMPLE?
I think DS shouldn't impose a method before pre-bind plugins are run, after all they are pre-bind so supposedly they should be able to influence what the bind ends up being, regardless of the mechanism chosen (if possible).
{{{ @@ -1417,7 +1464,13 @@ static int ipapwd_pre_bind(Slapi_PBlock pb) ret = ipapwd_getEntry(dn, &entry, (char ) attrs_list); if (ret) { LOG("failed to retrieve user entry: %s\n", dn); - return 0; + + / Try AD-compat option */ + if (method == LDAP_AUTH_SIMPLE) { + ret = ipapwd_ad_compat_bind(pb, dn, attrs_list, &dn, &entry); + } + + if (ret) return 0; } /* Check if the principal is not expired */ }}} In addition, I think the current dn in the above code is NULL if it tries to bind with non-DN string since Slapi_DN *sdn usually normalizes as a dn and the dn normalization fails.
{{{ @@ -1417,7 +1464,13 @@ static int ipapwd_pre_bind(Slapi_PBlock pb) ret = ipapwd_getEntry(dn, &entry, (char ) attrs_list); if (ret) { LOG("failed to retrieve user entry: %s\n", dn); - return 0; + + / Try AD-compat option */ + if (method == LDAP_AUTH_SIMPLE) { + ret = ipapwd_ad_compat_bind(pb, dn, attrs_list, &dn, &entry); + } + + if (ret) return 0; }
I ran this code in GDB with current DS (as configured by FreeIPA), I definitely get "admin" (or whatever string I put in the -D flag) in dn.
I am also ok if you pass in a NULL DN but add another pb value like BIND_TARGET_RAWDN or similar, as long as I can: 1) get the original value 2) set the DN that the rest of the bind code will use.
HTH.
both Simo and Rich are right, but the DS behaviour is a bit inconsistent. If you try:
{{{
$ ldapsearch -LLL -o ldif-wrap=no -h localhost -p 30522 -x -D "directory manager" -w xxxxx -b "dc=example,dc=com" -s base ldap_bind: Invalid DN syntax (34) additional info: invalid bind dn }}} it returns a syntax error with invalid bind dn, but for
{{{ ldapsearch -LLL -o ldif-wrap=no -h localhost -p 30522 -x -D "directory" -w xxxxxxx -b "dc=example,dc=com" -s base ldap_bind: No such object (32) }}}
it just returns "no such object", which is true, but could be changed by a preop plugin. So dn normalization acceepts an invalid dn "directory", but rejects an invalid dn "directory manager
I think we should interprete the standard as bind requires a dn, but move the point of checking and rejection past the PRE_BIND plugin calls
It turned out this patch by Simo is needed for fixing the ticket #48188. 0001-Allow-a-pre_bind-plugin-to-map-a-DN-to-another.patch​
We still need to modify the do_bind code so that non-dn style "binddn" is allowed to be converted to the valid dn by pre-bind plug-in. So, this ticket keeps open for the enhancement.
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1266206
Hmmm, I think that to really do this properly we should have a clear and distinct boundary. I think that for us to test this effectively the AD style bind plugin should be part of DS, rather than ipa_extop. That way we can test the pre_bind mangle, and we can include this feature as part of our normal testing.
I don't think it would be complex to write, and it would be easy for IPA to consume it if we enabled it. Does that sound like a better way forwards?
attachment 0001-Ticket-48272-ADDN-Sytle-prebind-plugin.patch
A few issues:
[1] Use C-style comments {{{/ ... /}}}, instead of {{{//}}}
http://www.port389.org/docs/389ds/development/coding-style.html
[2] addn_start:
memory leaks: slapi_entry_attr_get_chrptr() already makes a copy, so no need to strdup the result
'''1)''' A typo in the first line in the patch -- Ticket 48272 - ADDN '''Sytle''' prebind plugin ???
'''2)''' May not matter, but coverity would not like these...
line 102 -- since dn is not NULL, dn_bind cannot be NULL. So, the check is not needed.
line 106 -- dn_domain has not assigned by the line 106. Thus, 107 is a dead code. And there is no chance to go to the line 118, which is not implemented yet. That indicates this plugin is not completed??? {{{ 98 dn_bind = dn; 99 dn_bind_len = strlen(dn); 100 101 / Filter escape the name, and the domain parts / 102 if (dn_bind != NULL) { 103 dn_bind_escaped = slapi_escape_filter_value(dn_bind, dn_bind_len); 104 } 105 106 if (dn_domain != NULL) { 107 dn_domain_escaped = slapi_escape_filter_value(dn_domain, dn_domain_len); 108 } 109 110 / How do we manage domain -> backend properly? / 111 112 / If we don't have the @domain. get a default from config / 113 114 if (dn_domain_escaped == NULL) { 115 // This could alternately be domain, then we do the same domain -> suffix conversion .... 116 be_suffix = config->default_suffix; 117 } else { 118 // Parse the domain out to a potential suffix name. 119 } }}} '''3)''' I think this plugin has not implemented "uid@example.com" case yet. That's why do_domain never be set? If "uid@example.com" is not needed for now, you could note that like "not implemented yet"? {{{ 16 * This plugin allows violation of the LDAP v3 standard for binds to occur 17 * as "uid" or "uid@example.com". }}} {{{ 93 / Right, the dn is invalid! This means it could be addn syntax / 94 / Do we have any other validation to run here? / 95 / Split the @domain component (if any) / }}} I noticed this comment in the test case. So, it is known that not supported. {{{ 157 # Test bind as name@domain fails }}} '''4)''' For the question at line 151, you could set 1 to the arg * attrs only /. {{{ 151 // How can I do this search to retrieve NO attributes, only the DN? 152 153 slapi_search_internal_set_pb_ext(search_pblock, be_suffix_dn, LDAP_SCOPE_SUBTREE, 154 filter, NULL, 0 / attrs only /, 155 NULL / controls /, NULL / uniqueid /, 156 plugin_identity, 0 / actions /); }}} '''5)''' The comments at line 221 and 222 are supposed to be above line 232. {{{ 221 // Do we need to free the original SDN? 222 / Free the original SDN / 232 slapi_sdn_free(&pb_sdn_target); }}} '''6)''' config_filter is just pointing config->filter_template. {{{ 133 / Get our filter. From the config */ 134 config_filter = config->filter_template; }}} Is it ok to free it? {{{ 248 slapi_ch_free_string(&config_filter); }}} The same for be_suffix. It is pointing config->default_suffix. And it's freed at line 245... {{{ 116 be_suffix = config->default_suffix; }}} '''7)''' To verify the plugin is behaving ok, could you repeat the ADDN bind a couple of times to see the server does not crash in the plugin? Also, if you could add failure cases such as bind attempts with uid@domain or bogus or uid having multiple entries with the same uid (under the different DIT)?
attachment 0001-Ticket-48272-ADDN-Style-prebind-plugin.patch
Replying to [comment:23 nhosoi]:
'''2)''' May not matter, but coverity would not like these... line 102 -- since dn is not NULL, dn_bind cannot be NULL. So, the check is not needed.
It will be needed in the future, that's why it is there.
line 106 -- dn_domain has not assigned by the line 106. Thus, 107 is a dead code. And there is no chance to go to the line 118, which is not implemented yet. That indicates this plugin is not completed???
Yes, the support for user@domain.com isn't added yet.
'''4)''' For the question at line 151, you could set 1 to the arg * attrs only /. {{{ 151 // How can I do this search to retrieve NO attributes, only the DN? 152 153 slapi_search_internal_set_pb_ext(search_pblock, be_suffix_dn, LDAP_SCOPE_SUBTREE, 154 filter, NULL, 0 / attrs only /, 155 NULL / controls /, NULL / uniqueid /, 156 plugin_identity, 0 / actions */); }}}
Really? Wouldn't that mean I get attributes only in the result? Or does the 1 here mean false an "no attributes" ..... It's a bit confusing as 1 in C means true, and the param is attrs_only, so I read it as "if 1, attributes only in the result"....
'''7)''' To verify the plugin is behaving ok, could you repeat the ADDN bind a couple of times to see the server does not crash in the plugin? Also, if you could add failure cases such as bind attempts with uid@domain or bogus or uid having multiple entries with the same uid (under the different DIT)?
Each test loop runs ten times now.
My address and memory leak checking isn't finding any faults, thanks to your keen eyes!
I have a question, I would really like your comment on line 137 if you please. This is taking a value from cn=config, the format string, and then giving it to smprintf. I feel there is a risk of either not enough strings to replace into the filter, or too many. Is there a way to check this properly?
Once that's checked, I'll remove the other // comments too,
Thanks again!
Replying to [comment:24 firstyear]:
Replying to [comment:23 nhosoi]: '''2)''' May not matter, but coverity would not like these... line 102 -- since dn is not NULL, dn_bind cannot be NULL. So, the check is not needed. It will be needed in the future, that's why it is there.
I understand. In such a case, could please comment the check out with some comment to mention that it will be needed?
line 106 -- dn_domain has not assigned by the line 106. Thus, 107 is a dead code. And there is no chance to go to the line 118, which is not implemented yet. That indicates this plugin is not completed??? Yes, the support for user@domain.com isn't added yet. '''4)''' For the question at line 151, you could set 1 to the arg * attrs only /. {{{ 151 // How can I do this search to retrieve NO attributes, only the DN? 152 153 slapi_search_internal_set_pb_ext(search_pblock, be_suffix_dn, LDAP_SCOPE_SUBTREE, 154 filter, NULL, 0 / attrs only /, 155 NULL / controls /, NULL / uniqueid /, 156 plugin_identity, 0 / actions */); }}} Really? Wouldn't that mean I get attributes only in the result? Or does the 1 here mean false an "no attributes" ..... It's a bit confusing as 1 in C means true, and the param is attrs_only, so I read it as "if 1, attributes only in the result"....
0 means false. non-zero means true.
$ ldapsearch -LLLx [...] -b "dc=example,dc=com" -s base -A dn: dc=example,dc=com objectClass: dc:
In gdb:
Breakpoint 1, do_search (pb=0x7f12e2fecb00) at ldap/servers/slapd/search.c:289 289 if ( slapd_ldap_debug & LDAP_DEBUG_ARGS ) { (gdb) p attrsonly $1 = -1
'''7)''' To verify the plugin is behaving ok, could you repeat the ADDN bind a couple of times to see the server does not crash in the plugin? Also, if you could add failure cases such as bind attempts with uid@domain or bogus or uid having multiple entries with the same uid (under the different DIT)? Each test loop runs ten times now. My address and memory leak checking isn't finding any faults, thanks to your keen eyes! I have a question, I would really like your comment on line 137 if you please. This is taking a value from cn=config, the format string, and then giving it to smprintf. I feel there is a risk of either not enough strings to replace into the filter, or too many. Is there a way to check this properly?
Indeed, it is a risk... If the filter is
"addn_filter": "(&(objectClass=account)(uid=%s)(cn=%s)(sn=%s)(givenname=%s))"
and if you give just one argument like in the line 139, the garbages could be passed and it could crash the server... :( We need to know the intention of the addn_filter...
If we allow just one "%s" in the filter template, then finding multiple of "%s" in the addn_filter line, we should reject it and make the ADDN plugin fail?
Or you could use the trick as in SASL/GSSAPI bind by allowing to have a regular expression to specify the input could be "uid" or "uid@domain" or more comlicated string? Then, we have an idea what the filter is supposed to be? But I think this is an lower priority RFE?
I'd think allowing just one "%S" in addn_filter is what we could do for this release... What do you think?
Per weekly meeting, this ticket has been pushed to 1.3.6.
Fixes from Noriko's comments, and implementation of the @domain.com bind syntax. 0001-Ticket-48272-ADDN-Style-prebind-plugin.2.patch
I have a question, I would really like your comment on line 137 if you please. This is taking a value from cn=config, the format string, and then giving it to smprintf. I feel there is a risk of either not enough strings to replace into the filter, or too many. Is there a way to check this properly? Indeed, it is a risk... If the filter is "addn_filter": "(&(objectClass=account)(uid=%s)(cn=%s)(sn=%s)(givenname=%s))" and if you give just one argument like in the line 139, the garbages could be passed and it could crash the server... :( We need to know the intention of the addn_filter... If we allow just one "%s" in the filter template, then finding multiple of "%s" in the addn_filter line, we should reject it and make the ADDN plugin fail? Or you could use the trick as in SASL/GSSAPI bind by allowing to have a regular expression to specify the input could be "uid" or "uid@domain" or more comlicated string? Then, we have an idea what the filter is supposed to be? But I think this is an lower priority RFE? I'd think allowing just one "%S" in addn_filter is what we could do for this release... What do you think?
I think I need to think about the best way to implement this, but I've updated the patch for now without this check.
Final version with basic filter validation. 0001-Ticket-48272-ADDN-Style-prebind-plugin.3.patch
Includes the filter validation as requested by Noriko.
1.3.6.0? ;) {{{ 117 "nsslapd-pluginVersion": "1.3.4.0", }}}
Replace slapi_log_error with slapi_log_err?
In terms of logging, instead of this call (e.g.) {{{ 341 slapi_log_error(SLAPI_LOG_PLUGIN, "addn_start", "startup complete\n"); }}} you should call it with the PLUGIN NAME like this (I think you have to define ADDN_PLUGIN_SUBSYSTEM, too)? {{{ 341 slapi_log_err(SLAPI_LOG_PLUGIN, ADDN_PLUGIN_SUBSYSTEM, "addn_start: startup complete\n"); }}}
Please avoid using double slashes. {{{ 67 // Slapi_Entry *plugin_entry = NULL; }}}
And these kind of questions make reviewers unconfertable... :) {{{ 188 //!! How does this return errors, like not enough values? Too many? 189 //!! This needs a careful check and review!!! }}}
Need to check onfig_filter == NULL case? {{{ 37 addn_filter_validate(char config_filter) 38 { 39 / Copy the filter */ 40 size_t slen = strlen(config_filter); }}}
No reason not to use PR_strstr? {{{ 44 for (size_t i = 0; i < slen; i++) { 45 if (percent_last == 1 && config_filter[i] == 's') { 46 found += 1; 47 percent_last = 0; 48 } else if (percent_last == 0 && config_filter[i] == '%') { 49 percent_last = 1; 50 } else { 51 percent_last = 0; 52 } 53 } }}}
This plugin only works when the suffix is dc=foo,dc=bar? For instance, if the suffix is o=redhat.com, no hope? {{{ 158 / I think for now, we assume that a.b.c => dc=a,dc=b,dc=c / 168 be_suffix = slapi_ch_realloc(be_suffix, be_suffix_len); 169 / Inject our content at the start. / 170 strncpy(be_suffix + offset, ",dc=", 4); 171 strncpy(be_suffix + offset + 4, token, len); }}}
How about passing attr[2] = {"dn", NULL} to the 5th arg? {{{ 202 // How can I do this search to retrieve NO attributes, only the DN? 203 204 slapi_search_internal_set_pb_ext(search_pblock, be_suffix_dn, LDAP_SCOPE_SUBTREE, 205 filter, NULL, 0 / attrs only /, 206 NULL / controls /, NULL / uniqueid /, 207 plugin_identity, 0 / actions /); }}}
Rewrite of config parsing for this plugin. 0001-Ticket-48272-ADDN-Sytle-prebind-plugin.2.patch
Minor logging issues:
Can you please include slapi-private.h and use "slapi_log_err() for consistency? Also can you please use SLAPI_LOG_ERR instead of SLAPI_LOG_FATAL? I'd like to deprecate SLAPI_LOG_FATAL internally. Thanks!
Hmmmm, this doesn't sit right?
I thought that slapi_log_err() was for internal to DS, and the error() interface was for plugins. This is a plugin, so I think it should stay as slapi_log_error here.
Replying to [comment:31 firstyear]:
Hmmmm, this doesn't sit right? I thought that slapi_log_err() was for internal to DS, and the error() interface was for plugins. This is a plugin, so I think it should stay as slapi_log_error here.
I think Mark means the plugin is internal == checked into the 389-ds-base repository, it should use the same logging code. We don't force the external plugins such as the ones in IPA.
I agree with him. Let's not have 2 different looking logging code. It's similar to the previous state having LDAPDebug and slapi_log_error... :(
Replying to [comment:32 nhosoi]:
Replying to [comment:31 firstyear]: Hmmmm, this doesn't sit right? I thought that slapi_log_err() was for internal to DS, and the error() interface was for plugins. This is a plugin, so I think it should stay as slapi_log_error here. I think Mark means the plugin is internal == checked into the 389-ds-base repository, it should use the same logging code. We don't force the external plugins such as the ones in IPA. I agree with him. Let's not have 2 different looking logging code. It's similar to the previous state having LDAPDebug and slapi_log_error... :(
Throughout "all" of our code we should only use slapi_log_err() for consistency. I don't want two logging functions used in "our" code. IPA, and others can continue to use slapi_log_error().
Update log messages to LOG_ERR and LOG_WARNING. 0001-Ticket-48272-ADDN-Sytle-prebind-plugin.3.patch
Slapi_log_err macro. 0001-Ticket-48272-ADDN-Sytle-prebind-plugin.4.patch
Thanks William!
commit 9d66d3f Writing objects: 100% (19/19), 8.92 KiB | 0 bytes/s, done. Total 19 (delta 13), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 9a83b3a..9d66d3f master -> master
attachment 0001-Ticket-48272-Fix-compiler-warnings-for-addn.patch
ack
commit 3d1c81b Compressing objects: 100% (13/13), done. Writing objects: 100% (13/13), 1.86 KiB | 0 bytes/s, done. Total 13 (delta 9), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 2e494bc..577c4c1 master -> master
I do the test case troubleshooting. And it doesn't work for me on Fedora 25 and my build is from master branch - 389-ds-base-1.3.6.1-20170120git75a1958.fc25.x86_64.
I have run the ticket test case in DEBUGGING. I have:
{{{ dn: uid=user1,ou=People,dc=example,dc=com objectClass: top objectClass: account objectClass: simplesecurityobject uid: user1
dn: cn=addn,cn=plugins,cn=config nsslapd-pluginId: addn cn: addn addn_default_domain: example.com objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject nsslapd-pluginDescription: Allow AD DN style bind names to LDAP nsslapd-pluginEnabled: on nsslapd-pluginPath: libaddn-plugin nsslapd-pluginVersion: 1.3.6.1.20170120git75a1958 nsslapd-pluginVendor: 389 Project nsslapd-pluginType: preoperation nsslapd-pluginInitfunc: addn_init
dn: cn=example.com,cn=addn,cn=plugins,cn=config objectClass: top objectClass: extensibleObject cn: example.com addn_base: ou=People,dc=example,dc=com addn_filter: (&(objectClass=account)(uid=%s)) }}}
After running the next command with accesslog-level == 772 (full) and errorlog-level = 81920 (default + server plug-in):
{{{ [root@qeos-16 ds]# ldapsearch -h localhost -p 38901 -D "user1" -w password -b "dc=example,dc=com" -s base ldap_bind: Invalid credentials (49) }}}
I have logs:
{{{ [root@qeos-16 ds]# tail /var/log/dirsrv/slapd-standalone_1/errors [20/Jan/2017:05:48:55.097147746 -0500] - DEBUG - addn_plugin - addn_prebind: --> begin [20/Jan/2017:05:48:55.098016902 -0500] - DEBUG - addn_plugin - addn_prebind: Recieved user1 [20/Jan/2017:05:48:55.098627853 -0500] - DEBUG - addn_plugin - addn_prebind: Dn validation 1 [20/Jan/2017:05:48:55.100208399 -0500] - DEBUG - addn_plugin - addn_prebind: Dn syntax is incorrect, it may need ADDN mangaling [20/Jan/2017:05:48:55.101033033 -0500] - DEBUG - addn_plugin - addn_prebind: Selected default domain example.com [20/Jan/2017:05:48:55.101717651 -0500] - DEBUG - addn_plugin - addn_get_subconfig: Getting config for cn=addn,cn=plugins,cn=config [20/Jan/2017:05:48:55.102272259 -0500] - DEBUG - addn_plugin - addn_get_subconfig: Searching with filter (cn=example.com) [20/Jan/2017:05:48:55.103427537 -0500] - DEBUG - addn_plugin - addn_prebind: Searching with filter (&(objectClass=account)(uid=user1)) [20/Jan/2017:05:48:55.104995680 -0500] - DEBUG - addn_plugin - addn_prebind: SEARCH entry dn=uid=user1,ou=People,dc=example,dc=com is mapped from addn=user1 [20/Jan/2017:05:48:55.105601797 -0500] - DEBUG - addn_plugin - addn_prebind: <-- complete
[root@qeos-16 ds]# cat /var/log/dirsrv/slapd-standalone_1/errors [20/Jan/2017:05:48:55.097004995 -0500] conn=3 fd=64 slot=64 connection from ::1 to ::1 [20/Jan/2017:05:48:55.097110333 -0500] conn=3 op=0 BIND dn="user1" method=128 version=3 [20/Jan/2017:05:48:55.106709095 -0500] conn=3 op=0 RESULT err=49 tag=97 nentries=0 etime=0 - No such suffix (user1) [20/Jan/2017:05:48:55.106746485 -0500] conn=3 op=1 UNBIND [20/Jan/2017:05:48:55.106793190 -0500] conn=3 op=1 fd=64 closed - U1 }}}
Can you, please, take a look what can be wrong?
https://fedorahosted.org/389/ticket/49086
Hey mate, I already found it ;)
Closing as dup, I'll cc you on the other ticket.
Metadata Update from @nhosoi: - Issue assigned to firstyear - Issue set to the milestone: 1.3.6.0
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/1603
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.