Re: [389-users] Password Failure Lockout doesn't seem to work
by JLPicard
Yes, I can, after 8 consecutive failed authentications, the account can
still successfully query the DS with the correct password.
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w badPword
"cn=test-user-account"
ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h "my-ldapHost01.my-domain.com" -b
"dc=my-domain,dc=com" -D
"uid=test-user-account,ou=people,dc=my-domain,dc=com" -w goodPwrd
"cn=test-user-account"
dn: uid=test-user-account,ou=people,dc=my-domain,dc=com
description: accountHasItsOwnPwdPolicy
objectClass: posixAccount
objectClass: shadowAccount
objectClass: account
objectClass: top
uid: test-user-account
cn: test-user-account
uidNumber: 2853
gidNumber: 2600
gecos: LDAP Test
homeDirectory: /home/test-user-account
loginShell: /bin/tcsh
On 11/25/2013 5:49 PM, 389-users-request(a)lists.fedoraproject.org wrote:
> From: Rich Megginson <rmeggins(a)redhat.com> To: "General discussion
> list for the 389 Directory server project."
> <389-users(a)lists.fedoraproject.org> Cc: JLPicard
> <jlpicard15(a)hotmail.com> Subject: Re: [389-users] Password Failure
> Lockout doesn't seem to work Message-ID: <5293D3FC.2090907(a)redhat.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed" On
> 11/25/2013 03:33 PM, JLPicard wrote:
>> >Hi, I am testing out 389_ds_base, version =1.2.11.15,REV=2013.01.31
>> >running on mixed Solaris 10 servers (SPARC and X86) sourced from
>> >http://www.opencsw.org/packages/CSW389-ds-base
>> >in multi-master mode with 4 servers that is primarily used for
>> >authentication and user/group/netgroup management.
>> >
>> >Most of the Password policy components seem to work as they should,
>> >but password failure account lockout doesn't appear to engage after
>> >X-failed attempts. After creating a new account, testing a successful
>> >login, after 5+ failed logins with bad passwords, I can still login
>> >after I would expect to be locked out. I even created a new password
>> >policy and applied it to this user and it still doesn't lock him out
>> >after 5+ failed logins with bad passwords.
> Can you reproduce the issue with ldapsearch?
>
> ldapsearch ... -D "uid=myuser,...." -w "badpassword" ...
> repeat 5 times
>
>
10 years, 4 months
group issues
by Alberto Viana
I have 2 389 DS with multimaster replicaton and one of them replicating
(multimaster) with my AD server
389DS2 <--> 389DS1 <--> ADServer
389-Directory/1.2.10.12
AD Server 2008 R2
With 2 specific groups, for some reason that could not identify in my logs,
all members are deleted (i'm not sure if the root cause is the 389DS or my
AD).
Can someone take a look on my log file and point me what is going on?
I dont want to send my log to the list because that a lot of information of
my users. Can I send direct to someone?
Thanks a lot
10 years, 4 months
Disable password change prompt
by Darcy Hodgson
Hey everyone,
I have setup the directory server with version 1.2.11. I am running a
subtree password policy and was wondering if it's possible to disabled
the feature that requests a password changed once the user's password
has expired. If a user let's their password expire I just want them to
get an "access denied" or "password expired" message and not let them
in. Is this possible?
There is a flow chart on the Redhat website
[https://access.redhat.com/site/documentation/resources/docs/en-US/Red_Hat...]
that shows what is happening. In the bottom right if you follow Grace
Logins? > No > Prompt: Password Change
Thanks,
Darcy
10 years, 4 months
hang on 1.2.11.15
by Michael Gettes
389-Directory/1.2.11.15 B2013.238.2155
2 MMR master servers (this hang happened on one of the masters) along with 3 read-only replicas.
Linux XXXX 2.6.32-358.18.1.el6.x86_64 #1 SMP Fri Aug 2 17:04:38 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
389-admin.x86_64 1.1.29-1.el6 @epel-x86_64-server-6
389-admin-console.noarch 1.1.8-1.el6 @epel-x86_64-server-6
389-admin-console-doc.noarch 1.1.8-1.el6 @epel-x86_64-server-6
389-adminutil.x86_64 1.1.15-1.el6 installed
389-console.noarch 1.1.7-3.el5 installed
389-ds.noarch 1.2.2-1.el6 @epel-x86_64-server-6
389-ds-base.x86_64 1.2.11.15-22.el6_4
389-ds-base-debuginfo.x86_64 1.2.11.15-22.el6_4
389-ds-base-libs.x86_64 1.2.11.15-22.el6_4
389-ds-console.noarch 1.2.6-1.el6 @epel-x86_64-server-6
389-ds-console-doc.noarch 1.2.6-1.el6 @epel-x86_64-server-6
389-dsgw.x86_64 1.1.10-1.el6 @epel-x86_64-server-6
389-admin.i686 1.1.29-1.el6 epel-x86_64-server-6
389-adminutil.i686 1.1.15-1.el6 epel-x86_64-server-6
389-adminutil-devel.i686 1.1.15-1.el6 epel-x86_64-server-6
389-adminutil-devel.x86_64 1.1.15-1.el6 epel-x86_64-server-6
389-ds-base.x86_64 1.2.11.25-1.el6 389_rhel6_x86_64
389-ds-base-debuginfo.i686 1.2.11.15-30.el6_5
389-ds-base-debuginfo.x86_64 1.2.11.25-1.el6 389_rhel6_x86_64
389-ds-base-devel.i686 1.2.11.15-30.el6_5
389-ds-base-devel.x86_64 1.2.11.25-1.el6 389_rhel6_x86_64
389-ds-base-libs.i686 1.2.11.15-30.el6_5
389-ds-base-libs.x86_64 1.2.11.25-1.el6 389_rhel6_x86_64
nothing in the error log.
non-buffered access log: last 2 seconds
[11/Dec/2013:00:07:07 -0500] conn=104961 fd=84 slot=84 connection from 172.19.224.96 to XX
[11/Dec/2013:00:07:07 -0500] conn=104961 op=0 BIND dn="" method=128 version=2
[11/Dec/2013:00:07:07 -0500] conn=104961 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn=""
[11/Dec/2013:00:07:07 -0500] conn=104961 op=1 SRCH base="dc=cmu,dc=edu" scope=0 filter="(objectClass=*)" attrs=ALL
[11/Dec/2013:00:07:07 -0500] conn=104961 op=1 RESULT err=0 tag=101 nentries=1 etime=0
[11/Dec/2013:00:07:07 -0500] conn=104961 op=2 UNBIND
[11/Dec/2013:00:07:07 -0500] conn=104961 op=2 fd=84 closed - U1
[11/Dec/2013:00:07:07 -0500] conn=104962 fd=85 slot=85 SSL connection from 172.19.224.96 to XX
[11/Dec/2013:00:07:07 -0500] conn=104963 fd=84 slot=84 SSL connection from 172.19.224.96 to XX
[11/Dec/2013:00:07:07 -0500] conn=104962 SSL 256-bit AES
[11/Dec/2013:00:07:07 -0500] conn=104962 op=-1 fd=85 closed - B1
[11/Dec/2013:00:07:07 -0500] conn=104963 SSL 256-bit AES
[11/Dec/2013:00:07:07 -0500] conn=104963 op=0 BIND dn="uid=zenoss,ou=Account,dc=andrew,dc=cmu,dc=edu" method=128 version=2
[11/Dec/2013:00:07:08 -0500] conn=104963 op=0 RESULT err=0 tag=97 nentries=0 etime=1 dn="uid=zenoss,ou=Account,dc=andrew,dc=cmu,dc=edu”
stack trace of threads apply all bt full attached. I have the core file so am happy to do any additional gdb poking.
there is no SASL activity (given our previous reports) so this is something else. We have to kill -9 and then start the server to get it back up and running. Happy to make a bug report if that is more appropriate. I wanted to move to 1.2.11.26 but could not given the unprotected cert db problem.
10 years, 4 months
Re: [389-users] Version Display on RHDS 9 Upgrade
by Paul Whitney
Paul M. Whitney
E-mail: paul.whitney(a)mac.com
On Dec 09, 2013, at 11:27 AM, Rich Megginson <rmeggins(a)redhat.com> wrote:
> On 12/09/2013 09:30 AM, Paul Whitney wrote:
>> Rich,
>>
>> I deinstalled and reinstalled my DS 9.0 ISO, then ran through the updates:
>> - DS9-RHBA-2011-1788 (nothing to update/install from here since the ISO is as current in versions)
>> - DS9-RHBA-2012-1345 (updated the 389-ds-console to 1.2.7-1)
>> - DS9-RHBA-2013-0960 (updated everything to 9.1)
>>
>> So now this is what I have installed:
>>
>> 389-ds-base-1.2.11.15-22
>> 389-ds-base-libs-1.2.11.15-22
>> 389-ds-console-1.2.7-1
>> 389-console-1.1.7-1
>> 389-admin-1.1.34-1
>> 389-adminutil-1.1.17-1
>> 389-admin-console-1.1.8-1
>>
>> redhat-ds-admin-9.1.0-1
>> redhat-ds-console-9.1.0-1
>> redhat-idm-console-9.1.0-1
>> redhat-ds-9.1.0-1
>> redhat-ds-base-9.1.0-1
>> redhat-admin-console-9.1.0-1
>
> Did you run setup-ds-admin.pl -u on all of the systems that you upgraded?
I ran it and am getting the following error: Error adding entry 'cn=PAM Pass Through Auth,cn=plugins,cn=config'. Error: Already exists (i tried to remedy this by removing the entry, but still getting the same error).
>
>
>>
>> idm-console-framework-1.1.7-2
>> java-1.6.0-openjdk-1.6.0.0-1.65.1.11.1.3
>>
>> As root (just to eliminate any write permissions issue), I launched the 389-console.
>
> That shouldn't make any difference.
>
>> Log in successfully to master on local host. However a couple of things:
>> - The console window cannot access any of the slapd instances or the admin portion because system "failed to install a local copy of redhat-admin-9.0.jar or one of its supporting files." (The 9.0 jar links were replaced with 9.1). Links in this directory are confusing as all get out. Not sure why so many are needed....
>
> setup-ds-admin.pl -u is supposed to change the versions of the required jar files from 9.0 to 9.1.
>
> Links in which directory are confusing? You should never have to look in the directory.
I agree I should not have to look in the html/java directory. But that is where the jar files come from and wanted to verify that 9.0 jar files were replaced.
>
>
>>
>> In the admin-serv error log I am getting error: File does not exist: /usr/share/dirsrv/html/redhat-admin-9.0.jar (the java directory was not overlooked in the path, this is the error in the log, as if it is looking for the 9.0 jar files in html).
>
> Let's see what the console is looking for. Run
> redhat-idm-console -D 9 -f console.log
Unfortunately, I cannot capture this information and post here. Info is on intranet with no access to Internet.
>
> scrub the console.log and email it to me (it will probably be too large to post to the list)
>>
>>
>> Paul M. Whitney
>> E-mail: paul.whitney(a)mac.com
>>
>>
>>
>>
>>
>> On Dec 06, 2013, at 04:59 PM, Rich Megginson <rmeggins(a)redhat.com> wrote:
>>
>>> On 12/06/2013 02:34 PM, Paul Whitney wrote:
>>>> Rich,
>>>>
>>>> I think the problem has to do with the version of JAR files the console I am running is looking for. I see in /usr/share/dirsrv/html/java a lot of symbolic links that cascade back to 389 jar files.
>>>
>>> The console downloads these from the admin server and stores them in ~/.redhat-idm-console/jars. It is the latter directory used by the console.
>>>
>>>> They are all 9.1 and my console is looking for 9.0.
>>>
>>> A 9.1 server installation should use the 9.1 jars.
>>>
>>> What do you mean by "my console is looking for 9.0"?
>>>
>>>>
>>>> While I am ok with creating symbolic links and for 9.0 jar files, why will the console not use the jars already present?
>>>
>>> A 9.1 server must use the 9.1 jars, not the 9.0 jars.
>>>
>>>>
>>>> Paul M. Whitney
>>>> E-mail: paul.whitney(a)mac.com
>>>> Cell: 410.493.9448
>>>>
>>>>
>>>>
>>>>
>>>> On Dec 06, 2013, at 12:35 PM, Rich Megginson <rmeggins(a)redhat.com> wrote:
>>>>
>>>>> On 12/06/2013 10:41 AM, Paul Whitney wrote:
>>>>>> I recently upgraded my DS9 instance (RHDS9 RHBA-2013-0960) on both ldap server and my console. This should bring my servers to DS 9.1. Yet, I still see Version 9.0.0. Is this correct or did I miss a step?
>>>>>
>>>>> There should have been something in the upgrade docs about running setup-ds-admin.pl -u after doing the yum update.
>>>>>
>>>>>>
>>>>>>
>>>>>> Paul M. Whitney
>>>>>> E-mail: paul.whitney(a)mac.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 389 users mailing list
>>>>>> 389-users(a)lists.fedoraproject.org
>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>
10 years, 4 months
1.2.11.15 "rolls up" some objectclasses?
by Colin Panisset
I have a 4-way multi-master replication configuration; the servers are
slightly different versions, as below:
A - 1.2.9.9-1.el5 (CentOS 5)
B - 1.2.9.9-1.el5 (CentOS 5)
C - 1.2.10.2-20.el6_3 (CentOS 6)
D - 1.2.11.15-22.el6_4 (CentOS 6)
D was recently brought into the configuration to replace A (ultimately).
I initialized D as a consumer directly from A, and I've confirmed that
replication proceeds throughout the mesh without apparent incident --
there are no errors in /var/log/dirsrv/slapd*/errors relating to
replication.
The problem is that *some* objects under ou=people,dc=foo,dc=bar on D do
not show some objectclasses, notably "person" and
"organizationalPerson". These values don't show up in the output of
ldapsearch, via the console, or when used by an internal search process,
such as populating an nsFilteredRole.
These objects *do* have those objectclasses visible on all the other
servers (A, B, and C). Searches against those other servers return
expected results.
If I explicitly add the objectclass to the object via server D, the
objectclasses are now visible. Added objectclasses do not create
duplicates on the other servers in the replication mesh.
Has anyone seen anything like this before? The objects which exhibit
this behaviour don't seem to have any commonality with each other, and
are interspersed (by createtimestamp) with other almost identical
objects which do *not* exhibit the behaviour.
If the answer is "known bug fixed in version BLAH", then I'm perfectly
happy.
--
Colin Panisset
Tech Lead - Infrastructure, REA Group
Ph: +61 (0)3 8456 4636 Mb: +61 (0) 457 788 259
10 years, 4 months
Version Display on RHDS 9 Upgrade
by Paul Whitney
I recently upgraded my DS9 instance (RHDS9 RHBA-2013-0960) on both ldap server and my console. This should bring my servers to DS 9.1. Yet, I still see Version 9.0.0. Is this correct or did I miss a step?
Paul M. Whitney
E-mail: paul.whitney(a)mac.com
10 years, 4 months
check hostname option
by Alberto Viana
I have 2 389 running (389-Directory/1.3.2.6 and 389-Directory/1.3.1.3) with
multiple master configuration.
When I set the option "check hostname against name in certificate for
outbound SSL connections" the agreement does not work and shows me this
error:
[05/Dec/2013:14:35:55 -0200] slapi_ldap_bind - Error: could not send bind
request for id [uid=app.389.w,cn=config] authentication mechanism [SIMPLE]:
error -1 (Can't contact LDAP server), system error -5987 (Invalid function
argument.), network error 115 (Operation now in progress, host
"hmg2.homolog.rnp")
[05/Dec/2013:14:35:55 -0200] NSMMReplicationPlugin - agmt="cn=389-HMG2"
(hmg2:636): Replication bind with SIMPLE auth failed: LDAP error -1 (Can't
contact LDAP server) ((unknown error code))
When I unset the option, everything works as expected.
Here's the subject of my certificates:
Subject: C=BR, ST=Rio de Janeiro, L=Rio de Janeiro, O=Rede Nacional de
Ensino e Pesquisa, OU=GTI, CN=hmg3.homolog.rnp
Subject: C=BR, ST=Rio de Janeiro, L=Rio de Janeiro, O=Rede Nacional de
Ensino e Pesquisa, OU=GTI, CN=hmg2.homolog.rnp
My DNS is configured correctly (the reverse too).
In my production enviroment this options works fine, but it's a little bit
old (389-Directory/1.2.10.12)
Any clues?
10 years, 4 months
