389-users December 2013

389-users@lists.fedoraproject.org

17 participants
33 discussions

Unable to open 389 Console after running setupssl2.sh
by Fosiul alam 24 Dec '13

24 Dec '13

Hi I would really appreciated if any one can help me out here. I have installed fedora directory server 389-dsgw-1.1.10-1.el6.x86_64 389-ds-base-1.2.9.14-1.el6.x86_64 389-ds-console-doc-1.2.6-1.el6.noarch 389-ds-base-libs-1.2.9.14-1.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-ds-1.2.2-1.el6.noarch the problem: as soon as i ran bellow script, its executes fine witout any issues. https://github.com/richm/scripts/blob/master/setupssl2.sh dirsrv-admin, dirsrv is running, but i cant connect to console I am trying with username : admin/cn=Directory Manager http://ldapserver:9830 also https://ldapserver:9830 but no luck Dont understand why its failling to open 389. Thanks for your help.

2 1

Re: [389-users] Password Failure Lockout doesn't seem to work
by JLPicard 19 Dec '13

19 Dec '13

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

4 5

group issues
by Alberto Viana 18 Dec '13

18 Dec '13

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

2 7

unstable 389 in Fedora 20 - a time for epoch bump?
by Petr Spacek 13 Dec '13

13 Dec '13

Hello list, I'm sorry for nagging you, but Fedora 20 release day is coming and I have experienced serious issues with 389-ds-base-1.3.2.8-1.fc20.x86_64. https://fedorahosted.org/389/ticket/47629 Would it be worth to build a 389-ds-base-1.3.1 for Fedora 20 (and bump epoch in RPM spec file)? That will give us more time for debugging and testing ... Have a nice day. -- Petr^2 Spacek

2 1

Disable password change prompt
by Darcy Hodgson 12 Dec '13

12 Dec '13

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_D…] that shows what is happening. In the bottom right if you follow Grace Logins? > No > Prompt: Password Change Thanks, Darcy

1 0

hang on 1.2.11.15
by Michael Gettes 11 Dec '13

11 Dec '13

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.

2 1

Re: [389-users] Version Display on RHDS 9 Upgrade
by Paul Whitney 09 Dec '13

09 Dec '13

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

2 3

1.2.11.15 "rolls up" some objectclasses?
by Colin Panisset 09 Dec '13

09 Dec '13

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

2 3

Version Display on RHDS 9 Upgrade
by Paul Whitney 06 Dec '13

06 Dec '13

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

2 5

check hostname option
by Alberto Viana 05 Dec '13

05 Dec '13

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?

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users December 2013