389-ds-base

Clone
Source Code
GIT

#479 Console logins fail intermittenly
Closed: wontfix None Opened 11 years ago by mreynolds.

Closed: wontfix
Reopen Issue

When logging into console, using an "rdn" login, there is potential for it to incorrectly fail with a 401 error. For example: using the rdn "jsmith" can fail once the admin server/console gets into a bad state. Using the full DN always works: "uid=jsmith,ou=people,dc=example,dc=com"

Here is the sequence that leads to the problem:

[1] This error in the amdin server error triggers the issue:

admserv_host_ip_check: ap_get_remote_host could not resolve <IP>

--> this error seems to be random, and is not trigger by the console/DS

[2] This error invalidates the existing "user & group" information in the admin server
[3] The admin server attempts to rebuild the "user & group" information, but it binds as a legacy user account(SIE entry)
[4] This bind fails as there is no userpassword in the entry, and it is basically converted into an anonymous bind from the DS point of view.
[5] "Anonymous" does not have access to the user and group information in o=netscaperoot.
[6] This causes the login to fail.

This effects all versions of admin server/console.

The current solution is to add an aci to the cn=server group entries in o=netscaperoot:

dn: cn=Server Group,....

aci: (targetattr = "nsDirectoryURL || nsDirectoryFailoverList || nsBindPassword || nsBindDN || nsDirectoryInfoRef || objectClass")(version 3.0;acl "Console Anonymous Access To User & Groups Information";allow (read, compare, search)(userdn = "ldap:///anyone");)

aci that allows console to retreive user and group information
aci.txt

Here is DS access logging showing the problem. Note "user" is the exact text used in the console login box.

[08/May/2012:18:27:28 +0200] conn=5588 fd=1028 slot=1028 SSL connection from 127.0.0.1 to 127.0.0.1
[08/May/2012:18:27:28 +0200] conn=5588 SSL 128-bit RC4
[08/May/2012:18:27:28 +0200] conn=5588 op=0 BIND dn="" method=128 version=3
[08/May/2012:18:27:28 +0200] conn=5588 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn=""
[08/May/2012:18:30:31 +0200] conn=5588 op=1 SRCH base="o=NetscapeRoot" scope=2 filter="(uid=user)"
[08/May/2012:18:30:31 +0200] conn=5588 op=1 RESULT err=0 tag=101 nentries=0 etime=0
[08/May/2012:18:30:31 +0200] conn=5588 op=2 UNBIND
[08/May/2012:18:30:31 +0200] conn=5588 op=2 fd=1040 closed - U1
[08/May/2012:18:30:31 +0200] conn=6576 fd=1040 slot=1040 SSL connection from 127.0.0.1 to 127.0.0.1
[08/May/2012:18:30:31 +0200] conn=6576 SSL 128-bit RC4
[08/May/2012:18:30:31 +0200] conn=6576 op=0 BIND dn="cn=admin-serv-localhost,cn=Red Hat Administration Server,cn=Server Group,cn=localhost.localdomain,ou=localdomain,o=NetscapeRoot" method=128 version=3
[08/May/2012:18:30:31 +0200] conn=6576 op=0 RESULT err=53 tag=97 nentries=0 etime=0
[08/May/2012:18:30:31 +0200] conn=6576 op=1 UNBIND

Auth fails.

With the aci in place:

27/Sep/2012:12:35:25 -0400] conn=282 fd=64 slot=64 connection from 127.0.0.1 to 127.0.0.1
[27/Sep/2012:12:35:25 -0400] conn=282 op=0 SRCH base="o=NetscapeRoot" scope=2 filter="(uid=user)"
[27/Sep/2012:12:35:25 -0400] conn=282 op=0 RESULT err=0 tag=101 nentries=0 etime=0
[27/Sep/2012:12:35:25 -0400] conn=282 op=1 UNBIND
[27/Sep/2012:12:35:25 -0400] conn=282 op=1 fd=64 closed - U1
[27/Sep/2012:12:35:25 -0400] conn=283 fd=65 slot=65 connection from 127.0.0.1 to 127.0.0.1
[27/Sep/2012:12:35:25 -0400] conn=283 op=0 SRCH base="o=NetscapeRoot" scope=2 filter="(uid=my admin)"
[27/Sep/2012:12:35:25 -0400] conn=283 op=0 RESULT err=0 tag=101 nentries=0 etime=0
[27/Sep/2012:12:35:25 -0400] conn=283 op=1 UNBIND
[27/Sep/2012:12:35:25 -0400] conn=283 op=1 fd=65 closed - U1
[27/Sep/2012:12:35:25 -0400] conn=284 fd=64 slot=64 connection from 127.0.0.1 to 127.0.0.1
[27/Sep/2012:12:35:25 -0400] conn=284 op=0 BIND dn="cn=admin-serv-localhost,cn=389 Administration Server,cn=Server Group,cn=localhost.localdomain,ou=localdomain,o=NetscapeRoot" method=128 version=3
[27/Sep/2012:12:35:25 -0400] conn=284 op=0 RESULT err=53 tag=97 nentries=0 etime=0
[27/Sep/2012:12:35:25 -0400] conn=284 op=1 SRCH base="cn=configuration,cn=admin-serv-localhost,cn=389 Administration Server,cn=Server Group,cn=localhost.localdomain,ou=localdomain,o=NetscapeRoot" scope=0 filter="(objectClass=nsDirectoryInfo)" attrs=ALL
[27/Sep/2012:12:35:25 -0400] conn=284 op=1 RESULT err=0 tag=101 nentries=1 etime=0
[27/Sep/2012:12:35:25 -0400] conn=284 op=2 SRCH base="cn=Server Group,cn=localhost.localdomain,ou=localdomain,o=NetscapeRoot" scope=0 filter="(objectClass=nsDirectoryInfo)" attrs=ALL
[27/Sep/2012:12:35:25 -0400] conn=284 op=2 RESULT err=0 tag=101 nentries=1 etime=0
[27/Sep/2012:12:35:25 -0400] conn=284 op=3 SRCH base="cn=UserDirectory,ou=Global Preferences,ou=localdomain,o=NetscapeRoot" scope=0 filter="(objectClass=nsDirectoryInfo)" attrs=ALL
[27/Sep/2012:12:35:25 -0400] conn=284 op=3 RESULT err=0 tag=101 nentries=1 etime=0
[27/Sep/2012:12:35:25 -0400] conn=284 op=4 UNBIND
[27/Sep/2012:12:35:25 -0400] conn=284 op=4 fd=64 closed - U1

Auth succeeds.

Update in bugzilla about aci's:

This is the aci we need:

(targetattr = "*") (version 3.0;acl "console anonymous access";allow (read,compare,search)(userdn = "ldap:///anyone");)

Here are the enties that "still" need this aci (the "cn=server group" entries do have the aci's already in place):

dn: cn=configuration,cn=admin-serv-m1,cn=Red Hat Administration Server,cn=Server Group,cn=m1.rhdsa.rabobank.nl,ou=rabobank.nl,o=NetscapeRoot

dn: cn=configuration,cn=admin-serv-m2,cn=Red Hat Administration Server,cn=Server Group,cn=m2.rhdsa.rabobank.nl,ou=rabobank.nl,o=NetscapeRoot

dn: cn=configuration,cn=admin-serv-s1,cn=Red Hat Administration Server,cn=Server Group,cn=s1.rhdsa.rabobank.nl,ou=rabobank.nl,o=NetscapeRoot

dn: cn=configuration,cn=admin-serv-s2,cn=Red Hat Administration Server,cn=Server Group,cn=s2.rhdsa.rabobank.nl,ou=rabobank.nl,o=NetscapeRoot

Just to be safe the following attribute/value should be added to the cn=server group entries:

nsDirectoryInfoRef: cn=UserDirectory,ou=Global Preferences,ou=rabobank.nl,o=NetscapeRoot

dn: cn=Server Group,cn=m1.rhdsa.rabobank.nl,ou=rabobank.nl,o=NetscapeRoot
dn: cn=Server Group,cn=m2.rhdsa.rabobank.nl,ou=rabobank.nl,o=NetscapeRoot
dn: cn=Server Group,cn=s1.rhdsa.rabobank.nl,ou=rabobank.nl,o=NetscapeRoot
dn: cn=Server Group,cn=s2.rhdsa.rabobank.nl,ou=rabobank.nl,o=NetscapeRoot

So, the aci's are NOT enough to resolve this. They need the latest patch I provided to Marc Sauton. I think support should regenerate this patch to make sure they have the right one. Support should directly contact me for the new patch when they are ready to build it.

I'm sorry, I mistakenly closed this ticket... :(

I'm reopening back with the target milestone changing to 1.1.32...

Metadata Update from @nhosoi:
- Issue assigned to mreynolds
- Issue set to the milestone: 389-admin,console 1.1.32
7 years ago

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/479

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 Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)
3 years ago

Login to comment on this ticket.

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