[389-users] Re: passwordexpirationtime question

[Noriko Hosoi]

On 02/28/2017 11:40 AM, xinhuan zheng wrote:

Hello,

I have setup password policy for user account to enforce a few things:

passwordchange: on
passwordchecksyntax: on
passwordexp: on
passwordlockout: on
passwordlockoutduration: 180
passwordmaxage: 7

Please take a look at the Doc.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnconfig-passwordMaxAge_Password_Maximum_Age

⁠3.1.1.182. passwordMaxAge (Password Maximum Age)

Valid Range 1 to the maximum 32 bit integer value (2147483647) in seconds



passwordmaxfailure: 3
passwordmustchange: on
passwordwarning: 518400

With that policy on a user account, I changed one user's password from 389 
console. It basically resets user's password.

When user login, user gets "Password expired. Change your password now." 
prompt. The user goes through prompt to change the password. Then user gets login shell 
successfully. User then logout.

Next time when user login again, the user still gets "Password expired. Change your 
password now." prompt. It appears 'passwordexpirationtime' attribute is set to the 
very first time when user changed password, but never set to password change time + 7 
days, as the policy is configured.

What went wrong in my previous procedure? How do I get passwordexpirationtime 
set to correct time when user change their password from administrative reset?

Thanks,
- xinhuan
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org



___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Need help to tune 389 DS

[Noriko Hosoi]

On 02/22/2017 10:30 AM, Gordon Messmer wrote:

On 02/22/2017 03:27 AM, wodel youchi wrote:


we have many entries like these

*  Unindexed Search #32105 (notes=A)
(&(null=uid=lastname.lastname,ou=people,dc=domain,dc=tld))
  -  Bind DN:   cn=directory manager
*


You've got two problems here.  One is that you appear to be using 
"cn=directory manager" for one of your LDAP clients, and that is a 
very serious security risk.  Don't do that!


The other is that this application appears to be misconfigured. It 
looks like it's searching for an attribute whose value will be an LDAP 
DN, but it doesn't have the name of that attribute.  It might be 
looking for a group by "member" but because it doesn't know the name 
of the attribute, it's searching for an attribute named "null".



*Unindexed Component #1 (notes=U)
**  -  Search Base:   ou=people,***dc=domain,dc=tld*
  -  Search Filter: (&(objectclass=*)(uid=pat))
  -  Bind DN:   uid=dovecot,***dc=domain,dc=tld**


Take a look at either the 389 console or 
/etc/dirsrv/slapd-/dse.ldif (where you will look for default 
indexes,cn=config,cn=ldbm database,cn=plugins,cn=config). You should 
see equality indexes (nsIndexType: eq) for both of those attributes by 
default.  Is one of them not currently indexed?

A tiny correction...
presence (pres) for objectclass, and
equality (eq) for uid

And we recommend to tune nsslapd-idlistscanlimit with the appropriate 
value to avoid unnecessary unindexed search.

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/Database_Plug_in_Attributes.html#nsslapd_idlistscanlimit


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: elapsed time gremlin

[Noriko Hosoi]

On 02/17/2017 07:42 AM, Winstanley, Anthony wrote:


It was set to the default (4000). I set it to 70, and now both 
searches are fast (initial run time 3 seconds, then instant). And the 
server logs don't show any 'notes=?' for either search.


But… that's not what the docs say to do?

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Performance_Tuning_Guide/improving-search-performance.html#setting-scan-limits


Glad to hear it improved the performance.

BTW, please refer a newer Doc.  There are lots of enhancements and bug 
fixes since the RHDS8.2 time frame...


RHDS 10 Performance Tuning Guide
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Performance_Tuning_Guide/setting-scan-limits.html


   5.3. Setting Index Scan Limits

In large directories, the search results list can get huge. A directory 
with a million |inetorgperson| entries would have a million entries that 
were returned with a filter like |(objectclass=inetorgperson)|, and an 
index for the /|sn|/ attribute would have at least a million entries in it.
Loading a long ID list from the database significantly reduces search 
performance. *The configuration parameter, 
**|nsslapd-idlistscanlimit|**, sets a limit on the number of IDs that 
are read before a key is considered to match the entire primary index 
(meaning the search is treated as an unindexed search with a different 
set of resource limits). *


So basically, setting nsslapd-idlistscanlimit big tells the server to 
NOT revert to unindexed search, and indexed search makes me happy in 
this case.


But why is unindexed search on ou=PEOPLE so much faster than on 
ou=STUDENTS,ou=RECORDS?


If you get the entire 7 ou=PEOPLE entries, it'd also take long time, 
I'd think.  If the search goes to the unindexed search, it scans all the 
entries in the database one by one and checks if it satisfies the search 
condition.  Probably, OU=PEOPLE entries are put at the older part of the 
database (having lower entry id's) and OU=STUDENTS entries are placed 
after that (with higher entry id's)? If that's the case, you cannot get 
the OU=STUDENTS entries unless you finish scanning OU=PEOPLE entries.


If indexed, you don't have to scan them but get the entry id list via 
indexes.


Hope it helps.
--noriko


Or should I not care what the answer to that question is and just set 
nsslapd-idlistscanlimit to a million and be happy?


Thanks for your help,

Anthony

*From:*Noriko Hosoi [mailto:nho...@redhat.com]
*Sent:* Thursday, February 16, 2017 5:16 PM
*To:* 389-users@lists.fedoraproject.org
*Subject:* [389-users] Re: elapsed time gremlin

Hello,

What is the value set to nsslapd-idlistscanlimit?

$ ldapsearch -x -LLL -H ldaps://ldap.example.com:636 -b  
'cn=config,cn=ldbm database,cn=plugins,cn=config' -D cn=Directory\ 
Manager -w password -s base nsslapd-idlistscanlimit


If it is less than 6000, could you increase it to some large number, 
e.g., 70, and retry the searches?


Thanks,
--noriko

On 02/16/2017 04:54 PM, Winstanley, Anthony wrote:

Hi,

I'm hoping somebody can tell me where I might look to find why
this is happening…

We're running 389-Directory/1.2.11.15 B2014.300.2010

I have two ldapsearch queries that only vary in searchbase, one
which is taking too long. (Times don't vary much with consecutive
executions.)

ou=PEOPLE has just under 700,000 entries. Search takes 0-3 seconds.

ou=STUDENTS,ou=RECORDS has just under 6000 entries. Search takes
123-126 seconds.

There are no attributes used in ou=STUDENTS,ou=RECORDS that aren't
also used in ou=PEOPLE.

Two sample executions and log output:

[user@workstation ~]$ ldapsearch -x -LLL -H
ldaps://ldap.example.com:636 -b
ou=STUDENTS,ou=RECORDS,dc=example,dc=com -D cn=Directory\ Manager
-w password -s one -z 5 'cn=*' dn

… 5 entries returned …

[user@workstation ~]$

[root@server slapd-ldap1]# grep conn=33505 access

[16/Feb/2017:16:31:37] conn=33505 fd=96 slot=96 SSL connection
from IP1 to IP2

[16/Feb/2017:16:31:37] conn=33505 SSL 256-bit AES

[16/Feb/2017:16:31:37] conn=33505 op=0 BIND dn="cn=Directory
Manager" method=128 version=3

[16/Feb/2017:16:31:37] conn=33505 op=0 RESULT err=0 tag=97
nentries=0 etime=0 dn="cn=directory manager"

[16/Feb/2017:16:31:37] conn=33505 op=1 SRCH
base="ou=STUDENTS,ou=RECORDS,dc=example,dc=com" scope=1
filter="(cn=*)" attrs="distinguishedName"

[16/Feb/2017:16:33:40] conn=33505 op=1 RESULT err=4 tag=101
nentries=5 etime=123 notes=A

[16/Feb/2017:16:33:40] conn=33505 op=2 UNBIND

[16/Feb/2017:16:33:40] conn=33505 op=2 fd=96 closed - U1

[root@server slapd-ldap1]#

[user@workstation ~]$ ldapsearch -x -LLL -H
ldaps://ldap.example.ca:636 -b ou=PEOPLE,dc=exa

[389-users] Re: elapsed time gremlin

[Noriko Hosoi]

Hello,

What is the value set to nsslapd-idlistscanlimit?

$ ldapsearch -x -LLL -H ldaps://ldap.example.com:636 -b  
'cn=config,cn=ldbm database,cn=plugins,cn=config' -D cn=Directory\ 
Manager -w password -s base nsslapd-idlistscanlimit


If it is less than 6000, could you increase it to some large number, 
e.g., 70, and retry the searches?


Thanks,
--noriko

On 02/16/2017 04:54 PM, Winstanley, Anthony wrote:


Hi,

I'm hoping somebody can tell me where I might look to find why this is 
happening…


We're running 389-Directory/1.2.11.15 B2014.300.2010

I have two ldapsearch queries that only vary in searchbase, one which 
is taking too long. (Times don't vary much with consecutive executions.)


ou=PEOPLE has just under 700,000 entries. Search takes 0-3 seconds.

ou=STUDENTS,ou=RECORDS has just under 6000 entries. Search takes 
123-126 seconds.


There are no attributes used in ou=STUDENTS,ou=RECORDS that aren't 
also used in ou=PEOPLE.


Two sample executions and log output:

[user@workstation ~]$ ldapsearch -x -LLL -H 
ldaps://ldap.example.com:636 -b 
ou=STUDENTS,ou=RECORDS,dc=example,dc=com -D cn=Directory\ Manager -w 
password -s one -z 5 'cn=*' dn


… 5 entries returned …

[user@workstation ~]$

[root@server slapd-ldap1]# grep conn=33505 access

[16/Feb/2017:16:31:37] conn=33505 fd=96 slot=96 SSL connection from 
IP1 to IP2


[16/Feb/2017:16:31:37] conn=33505 SSL 256-bit AES

[16/Feb/2017:16:31:37] conn=33505 op=0 BIND dn="cn=Directory Manager" 
method=128 version=3


[16/Feb/2017:16:31:37] conn=33505 op=0 RESULT err=0 tag=97 nentries=0 
etime=0 dn="cn=directory manager"


[16/Feb/2017:16:31:37] conn=33505 op=1 SRCH 
base="ou=STUDENTS,ou=RECORDS,dc=example,dc=com" scope=1 
filter="(cn=*)" attrs="distinguishedName"


[16/Feb/2017:16:33:40] conn=33505 op=1 RESULT err=4 tag=101 nentries=5 
etime=123 notes=A


[16/Feb/2017:16:33:40] conn=33505 op=2 UNBIND

[16/Feb/2017:16:33:40] conn=33505 op=2 fd=96 closed - U1

[root@server slapd-ldap1]#

[user@workstation ~]$ ldapsearch -x -LLL -H 
ldaps://ldap.example.ca:636 -b ou=PEOPLE,dc=example,dc=com -D 
cn=Directory\ Manager -w password -s one -z 5 'cn=*' dn


… 5 entries returned …

[user@workstation ~]$

[root@server slapd-ldap1]# grep conn=33578 access

[16/Feb/2017:16:38:43] conn=33578 fd=96 slot=96 SSL connection from 
142.103.30.27 to 10.7.128.16


[16/Feb/2017:16:38:44] conn=33578 SSL 256-bit AES

[16/Feb/2017:16:38:44] conn=33578 op=0 BIND dn="cn=Directory Manager" 
method=128 version=3


[16/Feb/2017:16:38:44] conn=33578 op=0 RESULT err=0 tag=97 nentries=0 
etime=1 dn="cn=directory manager"


[16/Feb/2017:16:38:44] conn=33578 op=1 SRCH 
base="ou=PEOPLE,dc=example,dc=com" scope=1 filter="(cn=*)" 
attrs="distinguishedName"


[16/Feb/2017:16:38:44] conn=33578 op=1 RESULT err=4 tag=101 nentries=5 
etime=0 notes=A


[16/Feb/2017:16:38:44] conn=33578 op=2 UNBIND

[16/Feb/2017:16:38:44] conn=33578 op=2 fd=96 closed - U1

[root@server slapd-ldap1]#

Help? This is driving me nuts… Where can I look to find out why this 
might be happening?


Thanks,

Anthony



___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org



___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: sslversionMin supported in 389-DS 1.3.5

[Noriko Hosoi]

On 01/26/2017 10:53 AM, ghiureai wrote:

Hi List,
I 'm running 389-DS :
389-ds-base-1.3.5.15-1.fc24.x86_64 with TLS enable and  the following 
cfg ,

 is the last update version of TLS supported in this version?
i try using ( sslVersionMin: TLS1.1 and sslVersionMax: TLS2.0) but 
will not work, seems works for (sslVersionMin: TLS1.1 and 
sslVersionMax: TLS1.2)
I recommend not to set sslVersionMax.  The Directory Server will 
automatically pick up the highest available version supported by the NSS 
library installed on the host.  As you found out, TLS2.0 is not 
available yet.  (I'd think TLS1.3 is still in the DRAFT.)


dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
sslVersionMin: TLS1.0
sslVersionMax: TLS2.0
nsSSL3Ciphers: default
allowWeakCipher: off
nsKeyfile: alias/slapd***
nsCertfile: alias/slapd*


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: shadowexpire attribute on 389-ds-base-1.3.5.10-12.el7_3.x86_64

[Noriko Hosoi]

Sorry about the misunderstanding. Please file a ticket with the expected 
behaviour.


https://fedorahosted.org/389/newticket

Thanks.

On 01/05/2017 06:34 PM, Gordon Messmer wrote:

On 01/05/2017 04:00 PM, William Brown wrote:

http://www.port389.org/docs/389ds/design/shadow-account-support.html


I feel like I must be missing something, because this makes *no* sense 
at all.  When a search is performed, shadowExpire will reflect the 
current time plus the maximum password age?  Why the current time and 
not the time the password is set?  How could this value possibly be 
useful?  I looked at the code because I couldn't believe the document 
referenced above, but that document appears to accurately describe the 
code.


This goes beyond simply being a bug in implementation.  Whoever wrote 
this code fundamentally misunderstands the purpose of the shadowExpire 
attribute.  It isn't an expiration date for the password, and 
shouldn't be affected in any way by password policies.  The shadow 
expiration date is an expiration date on the account itself.  For 
example, I work in a university where our student accounts are valid 
only while they are enrolled in classes. shadowExpire is set to the 
end date for their enrolled courses.  It does not change when they set 
their password, and shouldn't depend on whether or not passwords expire.


Please see "man 5 shadow".  The new behavior is wrong.  I think it 
should be reverted for several reasons:  Primarily, the behavior is 
incorrect according to the documentation.  The standard behavior for 
this attribute provides a fixed date on which an account will no 
longer be valid.  Additionally, a change of this type is in 
appropriate in RHEL.  The proposition of a "stable" system is that 
features and functionality will not change in incompatible ways 
without notice.  This is an incompatible change, and was not 
documented in the release notes as far as I can see. Finally, this 
change quietly allows accounts which were previously expired to be 
considered to now be considered valid.  Almost no one will notice that 
their existing security policies are no longer being enforced as a 
result of this change.



Well previously the shadowExpire value did nothing


Yes, it did.  It indicated to client systems when the account should 
no longer be considered valid.  It was used by our user management 
tools to notify students before their accounts were terminated.



, it was just there
for schema compat. It was a static value, that never decremented so an
account was "always valid".


Why would it decrement?


At worst, we just lock accounts that would
have been locked out anyway due to the expiry of the password within ds
- Nothing is prematurely locked out, not activated.


No, at worst accounts that should be locked out are now allowed in 
forever because we don't expire passwords (because those ages are 
relative to the most recent change) but we do expire accounts (because 
that occurs on a fixed date).



This is a positive change, allowing synchronisation of policy between ns
and unix clients. Issues you see, are because of an inconsistent
management of password policy on directory server and shadow values. I
don't think we will revert or back out of this change, given the
positive benefits we perceive that it brings on a bigger scale to many
installations.

My advice would be to alter your password policy to match what you
expect shadow to contain.


That doesn't appear to be possible.

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: 389-ds 1.3.5.15 issue

[Noriko Hosoi]

Please see this section:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10.1/html/Administration_Guide/Starting_and_Stopping-DS.html#Starting_and_Stopping-DS-cmd

If you prefer, you could start the server(s) as follows:
# systemctl start dirsrv@YOUR_SERVER_ID.service
or
# systemctl start dirsrv.target

On 11/18/2016 08:49 AM, ghiureai wrote:

Hi Team,
need help with following error after a fresh installation on FC 24:
rpm -qa | grep 389-ds
389-ds-base-1.3.5.15-1.fc24.x86_64
389-ds-console-1.2.16-1.fc24.noarch
389-ds-base-libs-1.3.5.15-1.fc24.x86_64

Seeing  the following:
 service dirsrv stop
Redirecting to /bin/systemctl stop  dirsrv.service
Failed to stop dirsrv.service: Unit dirsrv.service not loaded.

or
 service dirsrv status
Redirecting to /bin/systemctl status  dirsrv.service
  dirsrv.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: performance degrades over time on CentOS 7

[Noriko Hosoi]

rpm -q 389-ds-base?

I wonder you are running the latest version?

https://git.centos.org/summary/rpms!!389-ds-base
2016-11-03 	*imports/c7/389-ds-base-1.3.5.10-11.el7 
 
* 		import 389-ds-base-1.3.5.10-11.el7 
 
	tag 
 
| commit 
 
| log 
 





On 11/15/2016 04:51 PM, Gordon Messmer wrote:

On 11/15/2016 12:08 PM, Rich Megginson wrote:
It is also useful to get a few stacktraces which will give us 
detailed information about what the server is doing.  For example, if 
you can "catch" the server while it is misbehaving, and get 
stacktraces every second for 10 seconds. 
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs 



This might be really good news:  In addition to oddly high CPU 
utilization, we sometimes see slapd lock up completely.   I managed to 
catch the server in such a state and get a backtrace. Can you let me 
know if this clarifies the problem at all?


When the server wedged, an ldap client would complete a connect() call 
to establish the connection, write some data, and then hang indefinitely:


connect(3, {sa_family=AF_INET6, sin6_port=htons(389), 
inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, 
sin6_scope_id=0}, 28) = 0
write(3, 
"0>\2\1\1c9\4\0\n\1\0\n\1\0\2\1\0\2\1\0\1\1\0\207\vobjectclass0\31\4\27supportedSASLMechanisms", 
64) = 64
poll([{fd=3, events=POLLIN|POLLPRI}], 1, 4294967295) = ? 
ERESTART_RESTARTBLOCK (Interrupted by signal)


I'd been running dbmon.sh in a terminal, and it had hung with no 
output for several minutes.  The last thing it printed was rather normal:


  dbname  count  free  free%size
userroot:ent   3607  78692851   75.0  7253.9
userroot:dn3607  10162827   96.989.5



___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: ds-admin setup error

[Noriko Hosoi]

On 10/11/2016 10:33 AM, Ghiurea, Isabella wrote:


Hi Noriko,

Thank you for reply! The Sysadmin here was able to build and compile 
the 389-DS 1.3.4.4  on rhel6-scientific linux 6, we have 3 other hosts 
with same cfg running fine, I am seeing this issues after we had to 
re-image this host , re-install the  389-ds packages from puppet we 
have  , I am unable to rebuild the 389-DS now , any tips were to look 
for ?


We have no experience to build 1.3.x on rhel-6...   You are failing to 
build 389-ds-base-1.3.4.4 on rhel-6 based OS, right?  Could you share 
the build failure messages with us?


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: ds-admin setup error

[Noriko Hosoi]

On 10/07/2016 01:46 PM, ghiureai wrote:

Hi LIst,
I am seeing a segmentation fault (Error updating console.conf: ) r 
when trying to build 389-ds admin console ,

see details : running setup-ds-admin.pl , my OS  and packages installed
Any clues , much appreciate.
Thank you

>>> setup-ds-admin.pl -ddd
+++check_and_add_entry: Entry not found cn=Commands,cn=admin-serv-xxx 
cn=389 Administration Server, cn=Server Group, cn=..., ou=., 
o=NetscapeRoot error No such object
+Entry cn=Commands,cn=admin-serv, cn=389 Administration 
Server, cn=Server Group, x, o=NetscapeRoot is added

+++updateLocalConf: writing Commands.objectclass: top
+++updateLocalConf: writing Commands.objectclass: nsResourceRef
+++check_and_add_entry: Entry not found 
cn=sync-task-sie-data,cn=Commands,cn=, cn=389 
Administration Server, cn=Server Group, cn=xxx, 
ou=xxx, o=NetscapeRoot error No such object
+++check_and_add_entry: attepting to modify the entry 
cn=sync-task-sie-data,cn=Commands,cn=, cn=389 
Administration Server, cn=Server Group, x, o=NetscapeRoot 
that does not exist

+++updateLocalConf: writing Commands.sync-task-sie-data.changetype: modify
+++updateLocalConf: writing Commands.sync-task-sie-data.replace: nsHelpRef
+++updateLocalConf: writing Commands.sync-task-sie-data.nshelpref: 
/usr/share/dirsrv/manual/help/sync-task-sie-data.html
+++check_and_add_entry: Entry not found 
cn=sync-task-sie-data,cn=Commands,cn= cn=389 
Administration Server, cn=Server Group, , 
o=NetscapeRoot error No such object
+Entry cn=sync-task-sie-data,cn=Commands,cn=admin-serv-xx, 
cn=Server Group, xx, o=NetscapeRoot is added

+++updateLocalConf: writing Commands.sync-task-sie-data.objectclass: top
+++updateLocalConf: writing Commands.sync-task-sie-data.objectclass: 
nstask
+++updateLocalConf: writing Commands.sync-task-sie-data.nshelpref: 
/usr/share/dirsrv/manual/help/sync-task-sie-data.html

+++updateLocalConf: writing Commands.sync-task-sie-data.nsexecref: runtime
+++check_and_add_entry: Entry not found 
cn=change-sie-password,cn=Commands,cn=admin-serv-xxx 
ou=xx, o=NetscapeRoot error No such object
+Entry cn=change-sie-password,cn=Commands,x 
o=NetscapeRoot is added

+++updateLocalConf: writing Commands.change-sie-password.objectclass: top
+++updateLocalConf: writing Commands.change-sie-password.objectclass: 
nstask
+++updateLocalConf: writing Commands.change-sie-password.nsexecref: 
runtime
Updating adm.conf with information from configuration directory server 
. . .

Updating the configuration for the httpd engine . . .
+Running /usr/lib64/dirsrv/cgi-bin/config op=set 
configuration.nsSuiteSpotUser="ldap-d" 
configuration.nsServerAddress="0.0.0.0" ..._sh: line 1: 28656 
Segmentation fault  /usr/lib64/dirsrv/cgi-bin/config op=set 
configuration.nsSuiteSpotUser="ldap-ds" 
configuration.nsServerAddress="0.0.0.0" 2>&1__

_Error updating console.conf:
Could not update the httpd engine configuration.
Failed to create and configure the admin server


The combination looks a little odd to me...

Your OS is rhel-6.x based upon the extension .el6.  But the version of 
389-ds-base is 1.3.4.4.  How did your get the version for el6? Supported 
389-ds-base for rhel-6 is 1.2.11.15-##.


Our latest 389-ds-base for el6 is 389-ds-base-1.2.11.15-75.el6_8.

There is an upstream release 1.3.4.4, but it was one year ago and just 
for Fedoras...

http://www.port389.org/docs/389ds/releases/release-notes.html


my OS:
Linux 2.6.32-431.el6.x86_64 #1 SMP Thu Nov 21 13:35:52 CST 2013 x86_64 
x86_64 x86_64 GNU/Linux


 rpm -qa | grep 389-*
389-admin-console-1.1.10-000.noarch
389-console-1.1.9-000.noarch
389-admin-1.1.42-000.x86_64
389-ds-base-1.3.4.4-000.x86_64
389-adminutil-1.1.22-000.x86_64
389-ds-console-1.2.12-000.noarch

***



___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org



___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Remote Management Console doesn't show "Directory Server" entry anymore

[Noriko Hosoi]

2016-09-29 15:11 GMT+01:00 Mark Reynolds >:


   I've never heard of this happening.  What version of the windows
   console do you have?

I have never seen it, either...  Could the 389-console-win version be 
389-Console-1.1.15 (installer: 389-Console-1.1.15-x86_64.msi)? What are 
the Windows and java version?


Did you have a chance to refresh the Console?

Also, if you remove 389-ds-1.2_en.jar and 389-ds-1.2.jar from 
.389-console/jar directory in the Administrator's home directory, does 
it change any behavior?


Thanks,
--noriko

On 09/29/2016 02:53 PM, wodel youchi wrote:

Hi, and thanks for your responses.

I did the test with both localhost and the Windows station, and here 
are the results


1- localhost

using :*/usr/bin/389-console -a http://localhost:9830* to launch the 
console


Logged as cn=Directory Manager

[29/Sep/2016:20:41:59 +0100] conn=7219 op=0 BIND dn="cn=Directory 
Manager" method=128 version=3
[29/Sep/2016:20:41:59 +0100] conn=7219 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[29/Sep/2016:20:41:59 +0100] conn=7219 op=1 SRCH 
base="cn=user,cn=DefaultObjectClassesContainer,ou=1.1,ou=admin,ou=Global 
Preferences,ou=mydomain.tld,o=NetscapeRoot" scope=0 
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[29/Sep/2016:20:41:59 +0100] conn=7219 op=1 RESULT err=0 tag=101 
nentries=1 etime=0

...
*[29/Sep/2016:20:42:22 +0100] conn=7219 op=46 SRCH base="cn=Server 
Group,cn=idm01.mydomain.tld,ou=mydomain.tld,o=NetscapeRoot" scope=1 
filter="(objectClass=nsApplication)" attrs=ALL

[29/Sep/2016:20:42:22 +0100] conn=7219 op=46 SORT cn (2)
[29/Sep/2016:20:42:22 +0100] conn=7219 op=46 RESULT err=0 tag=101 
nentries=2 etime=0


*[29/Sep/2016:20:42:22 +0100] conn=7219 op=47 SRCH base="cn=389 
Administration Server,cn=Server 
Group,cn=idm01.mydomain.tld,ou=mydomain.tld,o=NetscapeRoot" scope=1 
filter="(objectClass=netscapeServer)" attrs=ALL

[29/Sep/2016:20:42:22 +0100] conn=7219 op=47 SORT cn (2)
[29/Sep/2016:20:42:22 +0100] conn=7219 op=47 RESULT err=0 tag=101 
nentries=1 etime=0
[29/Sep/2016:20:42:22 +0100] conn=7219 op=48 SRCH 
base="cn=configuration,cn=admin-serv-idm01,cn=389 Administration 
Server,cn=Server 
Group,cn=idm01.mydomain.tld,ou=mydomain.tld,o=NetscapeRoot" scope=0 
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[29/Sep/2016:20:42:22 +0100] conn=7219 op=48 RESULT err=0 tag=101 
nentries=1 etime=0
[29/Sep/2016:20:42:22 +0100] conn=7219 op=49 SRCH 
base="cn=configuration,cn=admin-serv-idm01,cn=389 Administration 
Server,cn=Server 
Group,cn=idm01.mydomain.tld,ou=mydomain.tld,o=NetscapeRoot" scope=0 
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[29/Sep/2016:20:42:22 +0100] conn=7219 op=49 RESULT err=0 tag=101 
nentries=1 etime=0
[29/Sep/2016:20:42:22 +0100] conn=7219 op=50 SRCH 
base="cn=configuration,cn=admin-serv-idm01,cn=389 Administration 
Server,cn=Server 
Group,cn=idm01.mydomain.tld,ou=mydomain.tld,o=NetscapeRoot" scope=0 
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[29/Sep/2016:20:42:22 +0100] conn=7219 op=50 RESULT err=0 tag=101 
nentries=1 etime=0
[29/Sep/2016:20:42:22 +0100] conn=7219 op=51 SRCH 
base="cn=admin-serv-idm01,cn=389 Administration Server,cn=Server 
Group,cn=idm01.mydomain.tld,ou=mydomain.tld,o=NetscapeRoot" scope=0 
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[29/Sep/2016:20:42:22 +0100] conn=7219 op=51 RESULT err=0 tag=101 
nentries=1 etime=0
[29/Sep/2016:20:42:22 +0100] conn=7219 op=52 SRCH base="cn=389 
Administration Server,cn=Server 
Group,cn=idm01.mydomain.tld,ou=mydomain.tld,o=NetscapeRoot" scope=0 
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[29/Sep/2016:20:42:22 +0100] conn=7219 op=52 RESULT err=0 tag=101 
nentries=1 etime=0
[29/Sep/2016:20:42:22 +0100] conn=7219 op=53 SRCH 
base="cn=ResourceEditorExtension,ou=1.1,ou=admin,ou=Global 
Preferences,ou=mydomain.tld,o=NetscapeRoot" scope=1 
filter="(objectClass=nsAdminResourceEditorExtension)" attrs=ALL
[29/Sep/2016:20:42:22 +0100] conn=7219 op=53 RESULT err=0 tag=101 
nentries=6 etime=0
*[29/Sep/2016:20:42:22 +0100] conn=7219 op=54 SRCH base="cn=389 
Directory Server,cn=Server 
Group,cn=idm01.mydomain.tld,ou=mydomain.tld,o=NetscapeRoot" scope=1 
filter="(objectClass=netscapeServer)" attrs=ALL

[29/Sep/2016:20:42:22 +0100] conn=7219 op=54 SORT cn (2)
[29/Sep/2016:20:42:22 +0100] conn=7219 op=54 RESULT err=0 tag=101 
nentries=1 etime=0*
[29/Sep/2016:20:42:22 +0100] conn=7219 op=55 SRCH 
base="cn=configuration,cn=slapd-idm01,cn=389 Directory 
Server,cn=Server 
Group,cn=idm01.mydomain.tld,ou=mydomain.tld,o=NetscapeRoot" scope=0 
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL
[29/Sep/2016:20:42:22 +0100] conn=7219 op=55 RESULT err=0 tag=101 
nentries=1 etime=0
[29/Sep/2016:20:42:22 +0100] conn=7219 op=56 SRCH 
base="cn=configuration,cn=slapd-idm01,cn=389 Directory 
Server,cn=Server 
Group,cn=idm01.mydomain.tld,ou=mydomain.tld,o=NetscapeRo

[389-users] Re: "Directory Manager" can't change user's password; result is an inaccessible account.

[Noriko Hosoi]

On 09/27/2016 02:36 PM, Janet Houser wrote:



On 9/27/16 2:26 PM, Noriko Hosoi wrote:

On 09/27/2016 07:32 AM, Janet Houser wrote:



On 9/26/16 4:23 PM, Noriko Hosoi wrote:

On 09/26/2016 09:44 AM, Janet Houser wrote:



On 9/26/16 10:14 AM, Noriko Hosoi wrote:

Hi Janet,
On 09/26/2016 06:08 AM, Janet Houser wrote:

On 9/23/16 4:35 PM, Noriko Hosoi wrote:

On 09/23/2016 03:16 PM, Janet Houser wrote:

Hi Noriko,

thanks for the quick response.

On 9/23/16 3:37 PM, Noriko Hosoi wrote:

On 09/23/2016 02:24 PM, Janet Houser wrote:

Hi folks,

I'm fairly new to 389-ds and I ran into an issue when trying 
to update a user's password via the command line.


I was able to change a password "as" the user via the 
command line using the following syntax without issue:


ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"uid=jdoe,ou=People,dc=domain,dc=edu" -w current_user_passwd 
-s new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"


However, when I tried doing the same thing as the Directory 
Manager, it changes the password hash, but it doesn't update 
the password. In fact, after
issuing the following command (see below), both the old and 
new passwords don't work:



ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd -s 
new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"
Do you see any error messages in 
/var/log/dirsrv/slapd-INSTANCE/errors?


No errors reported in /var/log/dirsrv/slapd-INSTANCE/errors 
when I run the ldappasswd command with "cn=Directory Manager".


What does this access log file log for the operation?
/var/log/dirsrv/slapd-INSTANCE/access


[23/Sep/2016:15:54:44 -0600] conn=27891 fd=125 slot=125 
connection from XXX.X.XX.10 to XXX.XX.XXX.4
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 EXT 
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 RESULT err=0 
tag=120 nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 TLS1.2 256-bit AES
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 BIND 
dn="cn=Directory Manager" method=128 version=3
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 RESULT err=0 
tag=97 nentries=0 etime=0 dn="cn=directory manager"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 EXT 
oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 RESULT err=0 
tag=120 nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 UNBIND
[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 fd=125 closed - U1





What happens if you run this command line?
$ ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

dn: uid=jdoe,ou=People,dc=domain,dc=edu
changetype: modify
replace: userPassword
userPassword: new_user_passwd
EOF

Is the user's password is set to new_user_passwd?


No, the password fails to be set, and both passwords, old and 
new, are now invalid.   The output is:


- keystrokes of issued command 
# ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

> dn: uid=jdoe,ou=People,dc=domain,dc=edu
> changetype: modify
> replace: userPassword
> userPassword: 123abc!@garbage
> EOF
modifying entry "uid=jdoe,ou=People,dc=domain,dc=edu"
--- end of output ---

I'm puzzled.  So, it "acts" like it changes the password by 
telling me it is "modifying the entry", but it inserts 
something into the password

because the old password and the new password don't work.

Hi Janet,
Could you tell us how you are testing the new password?


Hi Noriko,

Sure!  I have several flavors of linux systems all using 389ds 
as the authentication server.


I've been testing the new password by trying to ssh to a LDAP 
system with the new password (and the old) and both would be 
rejected with a "Permission denied" error.
During my testing, I had disabled the Password Syntax, but left 
the general Subtree Password Policy applied to my domain.


In an act of desperation, I removed the subtree password policy 
and tried to change the password via the command line and it 
worked!  I was able to

ssh into my servers slaved into LDAP.

I then re-added the identical subtree password policy for my 
domain and I could *still* change the password via the command 
line.
The policy is *exactly* as it was before and is applied to the 
subtree of my main domain.


I don't have an explanation.  Perhaps something re-initialized 
by removing and re-adding the policy.


I tested this procedure again this morning and removed my 
subtree password policy on my domain and re-added it. Things 
still work and I
can ssh into various LDAP clients after I change the user's 
password via the command line.


If there&#x

[389-users] Re: "Directory Manager" can't change user's password; result is an inaccessible account.

[Noriko Hosoi]

On 09/27/2016 07:32 AM, Janet Houser wrote:



On 9/26/16 4:23 PM, Noriko Hosoi wrote:

On 09/26/2016 09:44 AM, Janet Houser wrote:



On 9/26/16 10:14 AM, Noriko Hosoi wrote:

Hi Janet,
On 09/26/2016 06:08 AM, Janet Houser wrote:

On 9/23/16 4:35 PM, Noriko Hosoi wrote:

On 09/23/2016 03:16 PM, Janet Houser wrote:

Hi Noriko,

thanks for the quick response.

On 9/23/16 3:37 PM, Noriko Hosoi wrote:

On 09/23/2016 02:24 PM, Janet Houser wrote:

Hi folks,

I'm fairly new to 389-ds and I ran into an issue when trying 
to update a user's password via the command line.


I was able to change a password "as" the user via the command 
line using the following syntax without issue:


ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"uid=jdoe,ou=People,dc=domain,dc=edu" -w current_user_passwd 
-s new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"


However, when I tried doing the same thing as the Directory 
Manager, it changes the password hash, but it doesn't update 
the password. In fact, after
issuing the following command (see below), both the old and 
new passwords don't work:



ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd -s 
new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"
Do you see any error messages in 
/var/log/dirsrv/slapd-INSTANCE/errors?


No errors reported in /var/log/dirsrv/slapd-INSTANCE/errors when 
I run the ldappasswd command with "cn=Directory Manager".


What does this access log file log for the operation?
/var/log/dirsrv/slapd-INSTANCE/access


[23/Sep/2016:15:54:44 -0600] conn=27891 fd=125 slot=125 
connection from XXX.X.XX.10 to XXX.XX.XXX.4
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 EXT 
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 RESULT err=0 
tag=120 nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 TLS1.2 256-bit AES
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 BIND 
dn="cn=Directory Manager" method=128 version=3
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 EXT 
oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 RESULT err=0 
tag=120 nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 UNBIND
[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 fd=125 closed - U1





What happens if you run this command line?
$ ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

dn: uid=jdoe,ou=People,dc=domain,dc=edu
changetype: modify
replace: userPassword
userPassword: new_user_passwd
EOF

Is the user's password is set to new_user_passwd?


No, the password fails to be set, and both passwords, old and 
new, are now invalid.   The output is:


- keystrokes of issued command 
# ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

> dn: uid=jdoe,ou=People,dc=domain,dc=edu
> changetype: modify
> replace: userPassword
> userPassword: 123abc!@garbage
> EOF
modifying entry "uid=jdoe,ou=People,dc=domain,dc=edu"
--- end of output ---

I'm puzzled.  So, it "acts" like it changes the password by 
telling me it is "modifying the entry", but it inserts something 
into the password

because the old password and the new password don't work.

Hi Janet,
Could you tell us how you are testing the new password?


Hi Noriko,

Sure!  I have several flavors of linux systems all using 389ds as 
the authentication server.


I've been testing the new password by trying to ssh to a LDAP 
system with the new password (and the old) and both would be 
rejected with a "Permission denied" error.
During my testing, I had disabled the Password Syntax, but left 
the general Subtree Password Policy applied to my domain.


In an act of desperation, I removed the subtree password policy 
and tried to change the password via the command line and it 
worked!  I was able to

ssh into my servers slaved into LDAP.

I then re-added the identical subtree password policy for my 
domain and I could *still* change the password via the command line.
The policy is *exactly* as it was before and is applied to the 
subtree of my main domain.


I don't have an explanation.  Perhaps something re-initialized by 
removing and re-adding the policy.


I tested this procedure again this morning and removed my subtree 
password policy on my domain and re-added it. Things still work and I
can ssh into various LDAP clients after I change the user's 
password via the command line.


If there's any info you'd like me to gather from my system for you 
to analyze, please let me

[389-users] Re: "Directory Manager" can't change user's password; result is an inaccessible account.

[Noriko Hosoi]

On 09/26/2016 09:44 AM, Janet Houser wrote:



On 9/26/16 10:14 AM, Noriko Hosoi wrote:

Hi Janet,
On 09/26/2016 06:08 AM, Janet Houser wrote:

On 9/23/16 4:35 PM, Noriko Hosoi wrote:

On 09/23/2016 03:16 PM, Janet Houser wrote:

Hi Noriko,

thanks for the quick response.

On 9/23/16 3:37 PM, Noriko Hosoi wrote:

On 09/23/2016 02:24 PM, Janet Houser wrote:

Hi folks,

I'm fairly new to 389-ds and I ran into an issue when trying to 
update a user's password via the command line.


I was able to change a password "as" the user via the command 
line using the following syntax without issue:


ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"uid=jdoe,ou=People,dc=domain,dc=edu" -w current_user_passwd -s 
new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"


However, when I tried doing the same thing as the Directory 
Manager, it changes the password hash, but it doesn't update the 
password. In fact, after
issuing the following command (see below), both the old and new 
passwords don't work:



ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd -s 
new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"
Do you see any error messages in 
/var/log/dirsrv/slapd-INSTANCE/errors?


No errors reported in /var/log/dirsrv/slapd-INSTANCE/errors when I 
run the ldappasswd command with "cn=Directory Manager".


What does this access log file log for the operation?
/var/log/dirsrv/slapd-INSTANCE/access


[23/Sep/2016:15:54:44 -0600] conn=27891 fd=125 slot=125 connection 
from XXX.X.XX.10 to XXX.XX.XXX.4
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 EXT 
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 RESULT err=0 tag=120 
nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 TLS1.2 256-bit AES
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 BIND dn="cn=Directory 
Manager" method=128 version=3
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 EXT 
oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 RESULT err=0 tag=120 
nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 UNBIND
[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 fd=125 closed - U1





What happens if you run this command line?
$ ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

dn: uid=jdoe,ou=People,dc=domain,dc=edu
changetype: modify
replace: userPassword
userPassword: new_user_passwd
EOF

Is the user's password is set to new_user_passwd?


No, the password fails to be set, and both passwords, old and new, 
are now invalid.   The output is:


- keystrokes of issued command 
# ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

> dn: uid=jdoe,ou=People,dc=domain,dc=edu
> changetype: modify
> replace: userPassword
> userPassword: 123abc!@garbage
> EOF
modifying entry "uid=jdoe,ou=People,dc=domain,dc=edu"
--- end of output ---

I'm puzzled.  So, it "acts" like it changes the password by 
telling me it is "modifying the entry", but it inserts something 
into the password

because the old password and the new password don't work.

Hi Janet,
Could you tell us how you are testing the new password?


Hi Noriko,

Sure!  I have several flavors of linux systems all using 389ds as 
the authentication server.


I've been testing the new password by trying to ssh to a LDAP system 
with the new password (and the old) and both would be rejected with 
a "Permission denied" error.
During my testing, I had disabled the Password Syntax, but left the 
general Subtree Password Policy applied to my domain.


In an act of desperation, I removed the subtree password policy and 
tried to change the password via the command line and it worked!  I 
was able to

ssh into my servers slaved into LDAP.

I then re-added the identical subtree password policy for my domain 
and I could *still* change the password via the command line.
The policy is *exactly* as it was before and is applied to the 
subtree of my main domain.


I don't have an explanation.  Perhaps something re-initialized by 
removing and re-adding the policy.


I tested this procedure again this morning and removed my subtree 
password policy on my domain and re-added it.   Things still work and I
can ssh into various LDAP clients after I change the user's password 
via the command line.


If there's any info you'd like me to gather from my system for you 
to analyze, please let me know.


Thanks for all your help!

Cheers, 

So, when testing the password, you are u

[389-users] Re: "Directory Manager" can't change user's password; result is an inaccessible account.

[Noriko Hosoi]

Hi Janet,
On 09/26/2016 06:08 AM, Janet Houser wrote:

On 9/23/16 4:35 PM, Noriko Hosoi wrote:

On 09/23/2016 03:16 PM, Janet Houser wrote:

Hi Noriko,

thanks for the quick response.

On 9/23/16 3:37 PM, Noriko Hosoi wrote:

On 09/23/2016 02:24 PM, Janet Houser wrote:

Hi folks,

I'm fairly new to 389-ds and I ran into an issue when trying to 
update a user's password via the command line.


I was able to change a password "as" the user via the command line 
using the following syntax without issue:


ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"uid=jdoe,ou=People,dc=domain,dc=edu" -w current_user_passwd -s 
new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"


However, when I tried doing the same thing as the Directory 
Manager, it changes the password hash, but it doesn't update the 
password. In fact, after
issuing the following command (see below), both the old and new 
passwords don't work:



ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D "cn=Directory 
Manager" -w directorymanager_passwd -s new_user_passwd 
"uid=jdoe,ou=People,dc=domain,dc=edu"
Do you see any error messages in 
/var/log/dirsrv/slapd-INSTANCE/errors?


No errors reported in /var/log/dirsrv/slapd-INSTANCE/errors when I 
run the ldappasswd command with "cn=Directory Manager".


What does this access log file log for the operation?
/var/log/dirsrv/slapd-INSTANCE/access


[23/Sep/2016:15:54:44 -0600] conn=27891 fd=125 slot=125 connection 
from XXX.X.XX.10 to XXX.XX.XXX.4
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 EXT 
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 RESULT err=0 tag=120 
nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 TLS1.2 256-bit AES
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 BIND dn="cn=Directory 
Manager" method=128 version=3
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 EXT 
oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 RESULT err=0 tag=120 
nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 UNBIND
[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 fd=125 closed - U1





What happens if you run this command line?
$ ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D 
"cn=Directory Manager" -w directorymanager_passwd << EOF

dn: uid=jdoe,ou=People,dc=domain,dc=edu
changetype: modify
replace: userPassword
userPassword: new_user_passwd
EOF

Is the user's password is set to new_user_passwd?


No, the password fails to be set, and both passwords, old and new, 
are now invalid.   The output is:


- keystrokes of issued command 
# ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D "cn=Directory 
Manager" -w directorymanager_passwd << EOF

> dn: uid=jdoe,ou=People,dc=domain,dc=edu
> changetype: modify
> replace: userPassword
> userPassword: 123abc!@garbage
> EOF
modifying entry "uid=jdoe,ou=People,dc=domain,dc=edu"
--- end of output ---

I'm puzzled.  So, it "acts" like it changes the password by telling 
me it is "modifying the entry", but it inserts something into the 
password

because the old password and the new password don't work.

Hi Janet,
Could you tell us how you are testing the new password?


Hi Noriko,

Sure!  I have several flavors of linux systems all using 389ds as the 
authentication server.


I've been testing the new password by trying to ssh to a LDAP system 
with the new password (and the old) and both would be rejected with a 
"Permission denied" error.
During my testing, I had disabled the Password Syntax, but left the 
general Subtree Password Policy applied to my domain.


In an act of desperation, I removed the subtree password policy and 
tried to change the password via the command line and it worked!  I 
was able to

ssh into my servers slaved into LDAP.

I then re-added the identical subtree password policy for my domain 
and I could *still* change the password via the command line.
The policy is *exactly* as it was before and is applied to the subtree 
of my main domain.


I don't have an explanation.  Perhaps something re-initialized by 
removing and re-adding the policy.


I tested this procedure again this morning and removed my subtree 
password policy on my domain and re-added it.   Things still work and I
can ssh into various LDAP clients after I change the user's password 
via the command line.


If there's any info you'd like me to gather from my system for you to 
analyze, please let me know.


Thanks for all your help!

Cheers, 

So, when testing the password, you are using "ssh".

Let me double check your steps.

Using this example:
# ldapmodify -h

[389-users] Re: "Directory Manager" can't change user's password; result is an inaccessible account.

[Noriko Hosoi]

On 09/23/2016 03:16 PM, Janet Houser wrote:

Hi Noriko,

thanks for the quick response.

On 9/23/16 3:37 PM, Noriko Hosoi wrote:

On 09/23/2016 02:24 PM, Janet Houser wrote:

Hi folks,

I'm fairly new to 389-ds and I ran into an issue when trying to 
update a user's password via the command line.


I was able to change a password "as" the user via the command line 
using the following syntax without issue:


ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"uid=jdoe,ou=People,dc=domain,dc=edu" -w current_user_passwd -s 
new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"


However, when I tried doing the same thing as the Directory Manager, 
it changes the password hash, but it doesn't update the password. In 
fact, after
issuing the following command (see below), both the old and new 
passwords don't work:



ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D "cn=Directory 
Manager" -w directorymanager_passwd -s new_user_passwd 
"uid=jdoe,ou=People,dc=domain,dc=edu"

Do you see any error messages in /var/log/dirsrv/slapd-INSTANCE/errors?


No errors reported in /var/log/dirsrv/slapd-INSTANCE/errors when I run 
the ldappasswd command with "cn=Directory Manager".


What does this access log file log for the operation?
/var/log/dirsrv/slapd-INSTANCE/access


[23/Sep/2016:15:54:44 -0600] conn=27891 fd=125 slot=125 connection 
from XXX.X.XX.10 to XXX.XX.XXX.4
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 EXT 
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=0 RESULT err=0 tag=120 
nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 TLS1.2 256-bit AES
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 BIND dn="cn=Directory 
Manager" method=128 version=3
[23/Sep/2016:15:54:44 -0600] conn=27891 op=1 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 EXT 
oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop"
[23/Sep/2016:15:54:44 -0600] conn=27891 op=2 RESULT err=0 tag=120 
nentries=0 etime=0

[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 UNBIND
[23/Sep/2016:15:54:44 -0600] conn=27891 op=3 fd=125 closed - U1





What happens if you run this command line?
$ ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D "cn=Directory 
Manager" -w directorymanager_passwd << EOF

dn: uid=jdoe,ou=People,dc=domain,dc=edu
changetype: modify
replace: userPassword
userPassword: new_user_passwd
EOF

Is the user's password is set to new_user_passwd?


No, the password fails to be set, and both passwords, old and new, are 
now invalid.   The output is:


- keystrokes of issued command 
# ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D "cn=Directory 
Manager" -w directorymanager_passwd << EOF

> dn: uid=jdoe,ou=People,dc=domain,dc=edu
> changetype: modify
> replace: userPassword
> userPassword: 123abc!@garbage
> EOF
modifying entry "uid=jdoe,ou=People,dc=domain,dc=edu"
--- end of output ---

I'm puzzled.  So, it "acts" like it changes the password by telling me 
it is "modifying the entry", but it inserts something into the password

because the old password and the new password don't work.

Hi Janet,
Could you tell us how you are testing the new password?


Thanks for your help on this


I found the following page, 
http://directory.fedoraproject.org/docs/389ds/design/password-administrator.html, 
but being fairly
new to 389-ds I wasn't sure how to create/define/add the ability to 
be a password administrator to an account.


Any suggestions would be appreciated.

Thanks,

/jh
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: "Directory Manager" can't change user's password; result is an inaccessible account.

[Noriko Hosoi]

On 09/23/2016 02:24 PM, Janet Houser wrote:

Hi folks,

I'm fairly new to 389-ds and I ran into an issue when trying to update 
a user's password via the command line.


I was able to change a password "as" the user via the command line 
using the following syntax without issue:


ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D 
"uid=jdoe,ou=People,dc=domain,dc=edu" -w current_user_passwd -s 
new_user_passwd "uid=jdoe,ou=People,dc=domain,dc=edu"


However, when I tried doing the same thing as the Directory Manager, 
it changes the password hash, but it doesn't update the password. In 
fact, after
issuing the following command (see below), both the old and new 
passwords don't work:



ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D "cn=Directory 
Manager" -w directorymanager_passwd -s new_user_passwd 
"uid=jdoe,ou=People,dc=int,dc=boulder,dc=nso,dc=edu"

Do you see any error messages in /var/log/dirsrv/slapd-INSTANCE/errors?

What does this access log file log for the operation?
/var/log/dirsrv/slapd-INSTANCE/access

What happens if you run this command line?
$ ldapmodify -h my389dsserver.domain.edu -p 389 -ZZ -D "cn=Directory 
Manager" -w directorymanager_passwd << EOF

dn: uid=jdoe,ou=People,dc=int,dc=boulder,dc=nso,dc=edu
changetype: modify
replace: userPassword
userPassword: new_user_passwd
EOF

Is the user's password is set to new_user_passwd?

I found the following page, 
http://directory.fedoraproject.org/docs/389ds/design/password-administrator.html, 
but being fairly
new to 389-ds I wasn't sure how to create/define/add the ability to be 
a password administrator to an account.


Any suggestions would be appreciated.

Thanks,

/jh
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: 389 directory server on Centos 6.8

[Noriko Hosoi]

On 09/05/2016 07:45 AM, Paolo Rughetti wrote:

Hi all,

I have installed 389 Directory Server on a Centos 6.8 server.
I followed the instructions reported in :

https://wiki.centos.org/HowTos/DirectoryServerSetup?highlight=%28directory%29%7C%28server%29

and installed with yum the following packages :

389-ds-base-1.2.11.15-75.el6_8.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-ds-base-libs-1.2.11.15-75.el6_8.x86_64
389-adminutil-1.1.19-1.el6.x86_64
389-admin-1.1.35-1.el6.x86_64

To proceed with the installation I would like to read the instructions
reported here :

https://access.redhat.com/documentation/en/red-hat-directory-server/

where I can choose the product version between 8.0 to 10.

Please select 9, which is for RHEL6.x/CentOS6.x.
https://access.redhat.com/documentation/en/red-hat-directory-server/?version=9


I would like to know which version of 389 Directory Server match
installed packages so I can select the right manual.

Thanking you in advance.

Bets regards.
--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Strange behaviour password sync , windows 2012 r2

[Noriko Hosoi]

On 08/29/2016 02:48 AM, Juan Carlos Camargo wrote:

Hi, 389ds'ers,

I have two 2012 r2 domain controllers with passsync 1.6 x64 installed. 
They're both targeting 389-ds-base-1.3.4.9-1.fc22.x86_64 . They're 
working flawlessly.
I dont know if it's been a software update or a change in the domain 
settings. Thing is today, one of the controllers has stopped sync'ing.
Could there be a certificate issue?  Did you have any chance to check 
the cert with the tool certutil?


Also, if you could try binding as the user "uid=juankar,ou=xxx" 
using an ldap command over SSL, you may be able to get more info, e.g., 
returned from the server.


Thanks.
Whenever I change one password in that controller, the following 
message is logged in passsync.log:


08/29/16 11:30:07: Password list has 1 entries
08/29/16 11:30:07: Attempting to sync password for juankar
08/29/16 11:30:07: Searching for (ntuserdomainid=juankar)
08/29/16 11:30:07: Checking password failed for remote entry: 
uid=juankar,ou=xxx

08/29/16 11:30:07: Deferring password change for juankar

and in the server access log I get ldap bind err=53 when the passsync 
user tries to check the password:


[29/Aug/2016:11:30:07 +0200] conn=276 fd=67 slot=67 SSL connection 
from 

[29/Aug/2016:11:30:07 +0200] conn=276 TLS1.2 128-bit AES
[29/Aug/2016:11:30:07 +0200] conn=276 op=0 BIND 
dn="uid=juankar,ou=xxx" method=128 version=3
[29/Aug/2016:11:30:07 +0200] conn=276 op=0 RESULT err=53 tag=97 
nentries=0 etime=0

[29/Aug/2016:11:30:07 +0200] conn=276 op=1 UNBIND
[29/Aug/2016:11:30:07 +0200] conn=276 op=1 fd=67 closed - U1
[29/Aug/2016:11:30:07 +0200] conn=275 op=2 UNBIND

Any hints? Could be a problem with certificates? They're both using 
the same CA (windows CA Cert serv is installed in one of the DCs)

Regards!






--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org



--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: 389-ds-base upgrade

[Noriko Hosoi]

On 08/22/2016 02:02 PM, xinhuan zheng wrote:

Hello,

I received the announcement on Friday about 389-ds-base upgrade. below is the 
short excerpt from the email:

---
389 Directory Server 1.3.5.13

The 389 Directory Server team is proud to announce 389-ds-base version 1.3.5.13.

Fedora packages are available from the Fedora 24, 25 and Rawhide repositories.

The new packages and versions are:

389-ds-base-1.3.5.13-1
---

However, since I am using Cent OS 6, I don't see the latest package available 
in epel. I tried to do 'yum upgrade 389-ds-base' but I just get the same 
version as my previous installation, not the newer version. What is the good 
way to upgrade on Cent OS 6?

Thank you,
- xinhuan
--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


Hello, We don't release 389-ds-base for centos 6 and 7.  Please get the 
packages from the centos download cites.


Please note that 389-ds-base-1.2.11.15-75.el6_8 is the latest available 
version for centos 6.


Thanks.
--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: user changing pass crashes 389ds

[Noriko Hosoi]

On 08/22/2016 12:03 PM, Frank Rosquin wrote:

ldappasswd -ZZ -H ldap://serverip -x -D "user_to_change_DN" -W -A -S

same, causes 389ds to crash.

The rest of your questions are really non-trivial for me to set up :(
--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


Looking at your stacktraces, passwd_extop.c has the right symbols but 
not the others.


Could you run this command line?

rpm -qa | grep 389-ds-base

If there are some mismatches between the debuginfo and the others, we 
cannot get the right stacktraces.


Thanks,
--noriko
--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: user changing pass crashes 389ds

[Noriko Hosoi]

Hello,

Could you share the stacktraces from the core file?

http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes

Thanks,
--noriko

On 08/21/2016 05:13 AM, Frank Rosquin wrote:

Hi,

I am writing a simple app to let users change their own ldap password in go, 
using gopkg.in/ldap.v2

binding and searching works great. But when I try to change a password as a 
user, 389ds just crashes.

This happens on both 389-Directory/1.3.2.16 B2014.098.2147 on Ubuntu 14.04 and 
389-Directory/1.2.11.15 B2016.132.835 on CentOS 6.

The only things I can see is the error log stating:

[21/Aug/2016:12:12:44 +] - 389-Directory/1.3.2.16 B2014.098.2147 starting up
[21/Aug/2016:12:12:44 +] - Detected Disorderly Shutdown last time Directory 
Server was running, recovering database.
[21/Aug/2016:12:12:45 +] - slapd started.  Listening on All Interfaces port 
389 for LDAP requests
[21/Aug/2016:12:12:45 +] - Listening on All Interfaces port 636 for LDAPS 
requests


Frank
--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server version 1.3.4.14

[Noriko Hosoi]

   389 Directory Server 1.3.4.14

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.4.14.


Fedora packages are available from the Fedora 23 repository.

The new packages and versions are:

 * 389-ds-base-1.3.4.14-1

Source tarballs are available for download at Download 389-ds-base 
Source  
and Download nunc-stans Source 
.



 Highlights in 1.3.4.14

 * Various bugs are fixed.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.org 
as well as 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.14-1.fc23 
.


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.4.9

 * CVE-2016-4992 389-ds-base: Information disclosure via repeated use
   of LDAP ADD operation, etc.
 * Ticket 47538 - Fix repl-monitor color and lag times
 * Ticket 47538 - repl-monitor.pl legend not properly sorted
 * Ticket 47538 - repl-monitor.pl not displaying correct color code for
   lag time
 * Ticket 47819 - RFE - improve tombstone purging performance
 * Ticket 47888 - DES to AES password conversion fails if a backend
   is empty
 * Ticket 47888 - Add CI test
 * Ticket 48078 - CI test - paged_results - TET part
 * Ticket 48109 - substring index with nssubstrbegin: 1 is not being
   used with filters like (attr=x*)
 * Ticket 48492 - heap corruption at schema replication.
 * Ticket 48497 - uncomment pytest from CI test
 * Ticket 48636 - Fix config validation check
 * Ticket 48636 - Improve replication convergence
 * Ticket 48752 - Page result search should return empty cookie if
   there is no returned entry
 * Ticket 48752 - Add CI test
 * Ticket 48755 - moving an entry could make the online init fail
 * Ticket 48766 - Replication changelog can incorrectly skip over updates
 * Ticket 48767 - flow control in replication also blocks receiving results
 * Ticket 48795 - Make various improvements to create_test.py
 * Ticket 48798 - Enable DS to offer weaker DH params in NSS
 * Ticket 48799 - objectclass values could be dropped on the consumer
 * Ticket 48799 - Test cases for objectClass values being dropped.
 * Ticket 48808 - Add test case
 * Ticket 48808 - Paged results search returns the blank list of entries
 * Ticket 48813 - password history is not updated when an admin resets
   the password
 * Ticket 48848 - modrdn deleteoldrdn can fail to find old attribute
   value, perhaps due to case folding
 * Ticket 48854 - Running db2index with no options breaks replication
 * Ticket 48862 - At startup DES to AES password conversion causes
   timeout in start script
 * Ticket 48889 - ldclt - fix man page and usage info
 * Ticket 48898 - Crash during shutdown if nunc-stans is enabled
 * Ticket 48900 - Add connection perf stats to logconv.pl
 * Ticket 48922 - Fix crash when deleting backend while import is running
 * Ticket 48924 - Fixup tombstone task needs to set proper flag when
   updating tombstones
 * Ticket 48930 - Paged result search can hang the server
 * Ticket 48935 - Update dirsrv.systemd file

http://www.port389.org/docs/389ds/releases/release-1-3-4-14.html

--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server version 1.3.5.13

[Noriko Hosoi]

   389 Directory Server 1.3.5.13

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.5.13.


Fedora packages are available from the Fedora 24, 25 and 
Rawhide repositories.


The new packages and versions are:

 * 389-ds-base-1.3.5.13-1

Source tarballs are available for download at Download 389-ds-base 
Source  
and Download nunc-stans Source 
.



 Highlights in 1.3.5.13

 * A security bug fix and lots of bug fixes and enhancements


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.org 
as well as 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.5.13-1.fc24 
.


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.5.4

 * CVE-2016-4992 389-ds-base: Information disclosure via repeated use
   of LDAP ADD operation, etc.
 * Ticket 47538 - Fix repl-monitor color and lag times
 * Ticket 47538 - repl-monitor.pl legend not properly sorted
 * Ticket 47538 - repl-monitor.pl not displaying correct color code for
   lag time
 * Ticket 47664 - Move CI test to the pr suite and refactor
 * Ticket 47824 - Remove CI test from tickets and add logging
 * Ticket 47911 - split out snmp agent into a subpackageTicket 47911
 * Ticket 47976 - Add fixed CI test case
 * Ticket 47982 - Fix log hr timestamps when invalid value is set
   in cn=config
 * Ticket 48109 - substring index with nssubstrbegin: 1 is not being
   used with filters like (attr=x*)
 * Ticket 48144 - Add /usr/sbin/status-dirsrv script to get the status
   of the directory server instance.
 * Ticket 48191 - Move CI test to the pr suite and refactor
 * Ticket 48234 - “matching rules” in ACI’s “bind rules not fully evaluated
 * Ticket 48234 - CI test: test case for ticket 48234
 * Ticket 48275 - search returns no entry when OR filter component
   contains non readable attribute
 * Ticket 48326 - Move CI test to config test suite and refactor
 * Ticket 48336 - Missing semanage dependency
 * Ticket 48336 - setup-ds should detect if port is already defined
 * Ticket 48346 - ldaputil code cleanup
 * Ticket 48346 - log too verbose when re-acquiring expired ticket
 * Ticket 48354 - Review of default ACI in the directory server
 * Ticket 48363 - CI test - add test suite
 * Ticket 48366 - proxyauth does not work bound as directory manager
 * Ticket 48404 - libslapd owned by libs and devel
 * Ticket 48449 - Import readNSState from richm’s repo
 * Ticket 48449 - Import readNSState.py from RichM’s repo
 * Ticket 48450 - Add prestart work around for systemd ask password
 * Ticket 48450 - Autotools components for ds_systemd_ask_password_acl
 * Ticket 48617 - Coverity fixes
 * Ticket 48636 - Fix config validation check
 * Ticket 48636 - Improve replication convergence
 * Ticket 48637 - DN cache is not always updated when ADD operation fails
 * Ticket 48743 - If a cipher is disabled do not attempt to look it up
 * Ticket 48745 - Matching Rule caseExactIA5Match indexes incorrectly
   values with upper cases
 * Ticket 48745 - Matching Rule caseExactIA5Match indexes incorrectly
   values with upper cases
 * Ticket 48747 - dirsrv service fails to start when nsslapd-listenhost
   is configured
 * Ticket 48752 - Page result search should return empty cookie if
   there is no returned entry
 * Ticket 48752 - Add CI test
 * Ticket 48754 - ldclt should support -H
 * Ticket 48755 - moving an entry could make the online init fail
 * Ticket 48755 - CI test: test case for ticket 48755
 * Ticket 48766 - Replication changelog can incorrectly skip over updates
 * Ticket 48767 - flow control in replication also blocks receiving results
 * Ticket 48795 - Make various improvements to create_test.py
 * Ticket 48799 - Test cases for objectClass values being dropped.
 * Ticket 48815 - ns-accountstatus.pl - fix DN normalization
 * Ticket 48832 - Fix timing and

[389-users] Announcing 389 Admin Server 1.1.43 and Consoles for EPEL6

[Noriko Hosoi]

   389 Admin Server 1.1.43 and Consoles for EPEL6

The 389 Directory Server team is proud to announce 389-admin version 
1.1.42, 389-adminutil version 1.1.22, 389-console version 1.1.16, 
389-ds-console version 1.2.12, 389-admin-console version 1.1.11, and 
idm-console-framework version version 9.1.2.


Fedora packages are available from the EPEL6.

The new packages and versions are:

 * 389-admin-1.1.43-1
 * 389-adminutil-1.1.22-1.el6
 * 389-console-1.1.17-1.el6
 * 389-ds-console-1.2.12-2.el6
 * 389-admin-console-1.1.11-1.el6
 * idm-console-framework-1.1.15-1.el6

Source tarballs are available for download at Download Admin Source 
, Download 
Adminutil Source 
, Download 
389-console Source 
, Download 
389-ds-console Source 
, 
Download 389-admin-console Source 
, and 
Download idm-console-framework Source 
.



 Highlights in 389-admin-1.1.43, 389-adminutil-1.1.22,
 389-console-1.1.17, 389-ds-console-1.2.12,
 389-admin-console-1.1.11, and idm-console-framework-1.1.15

 * Releasing the latest versions for EPEL6


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.org 
and following pages:


 * https://admin.fedoraproject.org/updates/389-admin-1.1.43-1.el6
   
 * https://admin.fedoraproject.org/updates/389-adminutil-1.1.22-1.el6
   
 * https://admin.fedoraproject.org/updates/389-console-1.1.17-1.el6
   
 * https://admin.fedoraproject.org/updates/389-ds-console-1.2.12-2.el6
   
 * https://admin.fedoraproject.org/updates/389-admin-console-1.1.11-1.el6
   
 * https://admin.fedoraproject.org/updates/idm-console-framework-1.1.15-1.el6
   

If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 389-admin-1.1.35

 * Ticket 48762 - 389-admin uses 389-admin-git.sh which uses HTTP to
   download content from git (should use HTTPS)
 * Ticket 48429 - running remove-ds-admin.pl multiple times will make
   it so you cannot inst all DS
 * Ticket 48409 - RHDS upgrade change Ownership of certificate files
   upon upgrade.
 * Ticket 47548 - register-ds-admin - silent file incorrectly processed
 * Ticket 47493 - Configuration Tab does not work with FIPS mode enabled
 * Ticket 48186 - register-ds-admin.pl script prints clear text
   password in the terminal
 * Ticket 47548 - register-ds-admin.pl fails to set local bind DN
   and password
 * Ticket 47467 - Improve Add CRL/CKL dialog and errors
 * Ticket 48171 - remove-ds-admin.pl removes files in the rpm
 * Ticket 48153 - “Manage certificates” crashes admin server
 * Ticket 48024 - repl-monitor invoked from adminserver cgi fails
 * Ticket 47995 - multiple /tmp/ file vulnerabilities [directory_server_10]
 * Ticket 47901 - Admin Server reconfig breaks SSL config
 * Ticket 47929 - Admin Server - disable SSLv3 by default
 * Ticket 201 - nCipher HSM cannot be configured via the console
 * Ticket 47493 - Configuration Tab does not work with FIPS mode enabled
 * Ticket 47697 - Resource leak in lib/libdsa/dsalib_updown.c
 * Ticket 47860 - register-ds-admin.pl problem when following steps to
   replicate o=netscaperoot
 * Ticket 47548 - register-ds-admin does not register into remote config ds
 * Ticket 47893 - Admin Server should use Sys::Hostname instead Net::Domain
 * Ticket 47

[389-users] Re: Detected Disorderly Shutdown last time Directory Server was running, recovering database.

[Noriko Hosoi]

Thank you, Carlos.

Could you repeat running gdb once more after installing debuginfo 
packages as follows?

# yum install 389-ds-base-debuginfo libdb-debuginfo

Note: you may need to enable debuginfo in you /etc/yum.repo.d/*.repo
enabled=1

Could you also share this output?
# egrep nsslapd-db /etc/dirsrv/slapd-YOUR_SERVER_INSTANCE/dse.ldif

Thanks.

On 07/15/2016 02:22 AM, Carlos Barrabes wrote:

Hello,

following your advice I ran the debugger and this is what I got:


(gdb) run -D /etc/dirsrv/slapd-pki -i /tmp/pid -d 0
Starting program: /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-pki -i 
/tmp/pid -d 0

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[15/Jul/2016:05:03:13 +0100] - 389-Directory/1.3.3.10 B2015.118.1912 
starting up
[15/Jul/2016:05:03:13 +0100] - WARNING -- Minimum cache size is 512000 
-- rounding up
[15/Jul/2016:05:03:13 +0100] - WARNING -- Minimum cache size is 512000 
-- rounding up
[15/Jul/2016:05:03:13 +0100] - WARNING -- Minimum cache size is 512000 
-- rounding up
[15/Jul/2016:05:03:13 +0100] - WARNING -- Minimum cache size is 512000 
-- rounding up
[15/Jul/2016:05:03:13 +0100] - WARNING -- Minimum cache size is 512000 
-- rounding up
[15/Jul/2016:05:03:13 +0100] - WARNING -- Minimum cache size is 512000 
-- rounding up
[15/Jul/2016:05:03:13 +0100] - WARNING: pki-matrix-gabon-OCSP: entry 
cache size 512000B is less than db size 516096B; We recommend to 
increase the entry cache size nsslapd-cachememsize.
[15/Jul/2016:05:03:13 +0100] - WARNING: pki-matrix-gabon-CA: entry 
cache size 512000B is less than db size 1589248B; We recommend to 
increase the entry cache size nsslapd-cachememsize.
[15/Jul/2016:05:03:13 +0100] - Detected Disorderly Shutdown last time 
Directory Server was running, recovering database.


Program received signal SIGBUS, Bus error.
0x7fffeef86a08 in __env_size_insert () from /lib64/libdb-5.3.so


and


(gdb) thread apply all bt

Thread 1 (Thread 0x77fd3800 (LWP 6597)):
#0  0x7fffeef86a08 in __env_size_insert () from /lib64/libdb-5.3.so
#1  0x7fffeef910ac in __env_detach () from /lib64/libdb-5.3.so
#2  0x7fffeef915da in __env_remove_env () from /lib64/libdb-5.3.so
#3  0x7fffeef8afdd in __env_open () from /lib64/libdb-5.3.so
#4  0x7fffed3014d5 in dblayer_start () from 
/usr/lib64/dirsrv/plugins/libback-ldbm.so
#5  0x7fffed356aa1 in ldbm_back_start () from 
/usr/lib64/dirsrv/plugins/libback-ldbm.so
#6  0x77b49283 in plugin_call_func () from 
/usr/lib64/dirsrv/libslapd.so.0
#7  0x77b49b84 in plugin_dependency_startall.isra.10.constprop 
() from /usr/lib64/dirsrv/libslapd.so.0

#8  0x555653fb in main ()


Thanks!


On 07/14/2016 06:22 PM, Noriko Hosoi wrote:

On 07/14/2016 09:06 AM, Carlos Barrabes wrote:

Hello,

we have a Fedora22 machine running 380 + Dogtag 10.2. Everything has 
been running smooth until today when we realized the DS was down and 
wouldn't go up.


After checking all the logs, we got this error message:

 Detected Disorderly Shutdown last time Directory Server was 
running, recovering database.

Could you please try this command line?
ps -ef | grep ns-slapd

If you see the ns-slapd process, start up (actually, database 
recovery) is still running.  Depending upon the size of the 
transaction log, it'd take a very long time.


If you don't see the process in the ps output, please start the 
server from gdb:

# gdb /usr/sbin/ns-slapd
(gdb) run -D /etc/dirsrv/slapd-SERVER_INSTANCE -i /tmp/pid -d 0

Once it crashes, get the stacktraces.
(gdb) thread apply all bt

And post the stacktraces?


We have even tried to reboot the entire server but the problem 
persists. Any suggestions on how to fix this will be really 
appreciated :D



Thanks!

--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org 



--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org 


--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org 



--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Detected Disorderly Shutdown last time Directory Server was running, recovering database.

[Noriko Hosoi]

On 07/14/2016 09:06 AM, Carlos Barrabes wrote:

Hello,

we have a Fedora22 machine running 380 + Dogtag 10.2. Everything has 
been running smooth until today when we realized the DS was down and 
wouldn't go up.


After checking all the logs, we got this error message:

 Detected Disorderly Shutdown last time Directory Server was 
running, recovering database.

Could you please try this command line?
ps -ef | grep ns-slapd

If you see the ns-slapd process, start up (actually, database recovery) 
is still running.  Depending upon the size of the transaction log, it'd 
take a very long time.


If you don't see the process in the ps output, please start the server 
from gdb:

# gdb /usr/sbin/ns-slapd
(gdb) run -D /etc/dirsrv/slapd-SERVER_INSTANCE -i /tmp/pid -d 0

Once it crashes, get the stacktraces.
(gdb) thread apply all bt

And post the stacktraces?


We have even tried to reboot the entire server but the problem 
persists. Any suggestions on how to fix this will be really 
appreciated :D



Thanks!

--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org 



--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server version 1.3.5.4

[Noriko Hosoi]

   389 Directory Server 1.3.5.4

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.5.4.


Fedora packages are available from the Fedora 24 and Rawhide repositories.

The new packages and versions are:

 * 389-ds-base-1.3.5.4-1

Source tarballs are available for download at Download 389-ds-base 
Source  and 
Download nunc-stans Source 
.



 Highlights in 1.3.5.4

 * Bug fixes and enhancements.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.org 
as well as 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.5.1-2.fc24 
.


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.5.3

 * Ticket 48836 - replication session fails because of permission denied
 * Ticket 48837 - Replication: total init aborted
 * Ticket 48617 - Server ram checks work in isolation
 * Ticket 48220 - The “repl-monitor” web page does not display “year”
   in date.
 * Ticket 48829 - Add gssapi sasl replication bind test
 * Ticket 48497 - uncomment pytest from CI test
 * Ticket 48828 - db2ldif is not taking into account multiple suffixes
   or backends
 * Ticket 48818 - Fix case where return code is always -1
 * Ticket 48826 - 52updateAESplugin.pl may fail on older versions of perl
 * Ticket 48825 - Configure make generate invalid makefile

--
389-users mailing list
389-users@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Sync problems with AD 2012 R2

[Noriko Hosoi]

Thanks a lot, Alberto!

I've opened a ticket:
https://fedorahosted.org/389/ticket/48841

On 05/17/2016 12:27 PM, Alberto Viana wrote:

Noriko,

/I have one question.  In your first email, you wrote this, in which 
the problem is in 2012R2, but not in 2008R2./


*Sorry, I don't have any 2008 r2 in my lab... I just tested with 2012 
r2 and it failed. *

*
*
*Here's my scenarios*
*
*
*My lab environment:*
*389-ds-base 1.3.4.8 + win 2012 r2*
*
*
*OU just in 389 side with users: Full sync failed, log error:*
*
*
*
[17/May/2016:14:19:44 -0300] - Attempting to add entry cn=mais um 
teste,ou=teste,ou=RNP,dc=homolog,dc=rnp to AD for local entry 
uid=teste.teste,ou=teste,ou=RNP,dc=homolog,dc=rnp
[17/May/2016:14:19:44 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Received result code 32 
(208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT), data 0, 
best match of:   'OU=RNP,DC=homolog,DC=rnp' ) for add operation
[17/May/2016:14:19:44 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): 
windows_process_total_add: Cannot replay add operation.
[17/May/2016:14:19:44 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Beginning linger on the 
connection
[17/May/2016:14:19:44 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): windows_tot_run: failed 
to obtain data to send to the consumer; LDAP error - 1

[17/May/2016:14:19:44 -0300] - Calling dirsync search request plugin
[17/May/2016:14:19:44 -0300] - Sending dirsync search request
[17/May/2016:14:19:45 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Cancelling linger on the 
connection
[17/May/2016:14:19:45 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Disconnected from the 
consumer
[17/May/2016:14:19:45 -0300] NSMMReplicationPlugin - windows sync - 
windows_inc_runs: cancelled dirsync: 7fa660001d60, rval: 1


*
*
*
*OU just in AD side with users: Full sync ok*
*
*

*My production environment:*
*389-ds-base 1.3.2.19 + win 2008 r2 *
*
*
*OU just in 389 side with users: Full sync ok*
*OU just in AD side with users: Full sync ok*
*
*
*
*
*If you need any other info, please let me know.*
*
*
*
*

On Tue, May 17, 2016 at 2:54 PM, Noriko Hosoi <mailto:nho...@redhat.com>> wrote:


Thank you for your input, Alberto.

On 05/17/2016 07:38 AM, Alberto Viana wrote:

Rich,

I'm aware of that, what I'm trying to say is: Is the expected
behavior to sync do not complete or stop because of one or more
OUs does not exists in one of the sides (389 or AD)? Is not
suppose to just generate some error and must go on?

I think so, too.

I have one question.  In your first email, you wrote this, in
which the problem is in 2012R2, but not in 2008R2.
> I'm trying to setup a new scenario with 389 and AD 2012 R2 (So
far I'm using with AD 2008 R2 and everything works fine).

Did you have a chance to run "full sync" against 2008R2, as well? 
Or just against 2012R2 and it failed?


There should not be a difference there, IMO...

Thanks,
--noriko


Thanx

On Tue, May 17, 2016 at 11:26 AM, Rich Megginson
mailto:rmegg...@redhat.com>> wrote:

On 05/17/2016 08:01 AM, Alberto Viana wrote:

Noriko,

Just to let you know, after I replicated/created the exactly
same OU structure on both side, the replication seems to
works fine. I'm still not sure that is the expected behavior:


Yes, it is.  Winsync does _not_ sync the OU structure - you
have to set that up manually so that the OU structure in AD
matches the OU structure in 389.




[17/May/2016:10:56:53 -0300] - windows_conn_connect :
detected Win2k3 or later peer
[17/May/2016:10:56:53 -0300] NSMMReplicationPlugin - windows
sync - agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): No
linger to cancel on the connection
[17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time:
gen state before 573b22010001:1463493115:0:6
[17/May/2016:10:56:54 -0300] - _csngen_adjust_local_time:
gen state after 573b232c:1463493414:0:6
[17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows
sync - windows_acquire_replica returned success (101)
[17/May/2016:10:56:54 -0300] NSMMReplicationPlugin - windows
sync - agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): State:
ready_to_acquire_replica -> sending_updates
[17/May/2016:10:56:54 -0300] - csngen_adjust_time: gen state
before 573b232c0001:1463493414:0:6
[17/May/2016:10:56:54 -0300] NSMMReplicationPlugin -
cha

[389-users] Re: Sync problems with AD 2012 R2

[Noriko Hosoi]

re on both side (for
testing purposes), I created
"**ou=pop-go,ou=POPS,ou=EXTERNOS,ou=RNP,dc=homolog,dc=rnp" on
AD side and started to get error in another OU that I have on
389 side but not in AD.*
*
*
*Is that the expected behavior?*
*
*
*PS: In my production environment we use this strategy that
what we dont want to be replicated, just not create the OU
structure and works fine. I never found a better way to do
that like a "exclude list".*


/Could you also share your Windows Sync agreement?  Do you
happen to have 2 Directory Servers -- one for 2008R2 and
another for 2012R2, could you provide both?/


*Here's my sync agreement:*
*
*
*dn: cn=AD -
DF-GTI-DC01,cn=replica,cn=dc\3Dhomolog\2Cdc\3Drnp,cn=mapping
tree,*
* cn=config*
*objectClass: top*
*objectClass: nsDSWindowsReplicationAgreement*
*description: Sync with HOMOLOG DF-GTI-DC01*
*cn: AD - DF-GTI-DC01*
*nsds7WindowsReplicaSubtree: dc=homolog,dc=rnp*
*nsds7DirectoryReplicaSubtree: dc=homolog,dc=rnp*
*nsds7NewWinUserSyncEnabled: on*
*nsds7NewWinGroupSyncEnabled: on*
*nsds7WindowsDomain: homolog.rnp*
*nsDS5ReplicaRoot: dc=homolog,dc=rnp*
*nsDS5ReplicaHost: gti-df-dc01.homolog.rnp*
*nsDS5ReplicaPort: 636*
*nsDS5ReplicaBindDN: CN=Conta de sincronizacao do AD com LDAP
389,OU=APLICACOES*
* ,DC=homolog,DC=rnp*
*nsDS5ReplicaTransportInfo: SSL*
*nsDS5ReplicaBindMethod: SIMPLE*
*nsDS5ReplicaCredentials:
{AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG*
* 
RERBNEJDUXhNVEZoWmpjMVlTMDVaakkyTXpBNA0KTnkwNVl6RmxOV1UwWXkxaVpHWTBaVEkwWkFBQ*
* 
0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQ0FNQytucnM5R09Pbm*
* IrTGc5Q1BURw==}y3eiY+wIKrDUOvz08JXugA==*
*nsds7DirsyncCookie::
TVNEUwMAAABTrjoAO7DRAQAAWMJLBQAAA*
* 
ADCSwUAAOaoLC8LQH5DrKGkZbG6hSgBAAMAUFu8Kzif9UKPjH3e1siBWw*
* 
A5AQAA5qgsLwtAfkOsoaRlsbqFKMNLBQAAdqnRrgBktU6JZXBssjxeIesdBQAA*
*nsds5replicareapactive: 0*
*nsds5replicaLastUpdateStart: 20160517125737Z*
*nsds5replicaLastUpdateEnd: 20160517125737Z*
*nsds5replicaChangesSentSinceStartup:*
*nsds5replicaLastUpdateStatus: 0 Replica acquired
successfully: Incremental upd*
* ate started*
*nsds5replicaUpdateInProgress: FALSE*
*nsds5replicaLastInitStart: 20160517124301Z*
*nsds5replicaLastInitEnd: 20160517125236Z*
*nsds5replicaLastInitStatus: 1 connection error: operation
failure - Total upda*
* te aborted*
*
*
*
*
*In this testing environment, I just have 2012 r2 (I upgraded
all DCs to 2012). Right now, I don't have any 2008 r2 to test. *
*
*
*In my production environment I have:*
*389-ds-base 1.3.2.19 + Windows 2008 r2*

On Mon, May 16, 2016 at 6:02 PM, Noriko Hosoi
mailto:nho...@redhat.com>> wrote:

On 05/16/2016 01:01 PM, Alberto Viana wrote:

I'm trying to setup a new scenario with 389 and AD 2012
R2 (So far I'm using with AD 2008 R2 and everything
works fine).

Did you use the same version of 389-ds-base against AD on
2008 R2 and 2012 R2?

389-Directory/1.3.4.8 <http://1.3.4.8> B2016.063.1654

Please share the output frpm this command line "rpm -q
389-ds-base"?


Windows 2012 R2 64bits

Both 2008 R2 and 2012 R2 are supported.

:
After configure the AD replication and Initiate a full
sync, it starts to do some entries and I got the
following error:


[16/May/2016:16:36:47 -0300] NSMMReplicationPlugin -
windows sync - agmt="cn=AD - DF-GTI-DC01"
(gti-df-dc01:636): windows_process_total_add: Cannot
replay add operation.

Does this error message follow some other detailed error
messages?  Such as ...

YOUR_AGREEMENT_NAMEFailed to send %s operation: LDAP
error (ERROR_CODE) ERROR_MESSAGE

or

YOUR_AGREEMENT: Received error [%s] when attempting
to %s entry [%s]: Please correct the attribute
specified in the error message.  Refer to the Windows
Active Directory docs for more information.

If not, could you enable the replication log level and
share the error log with us?


And after that:

[16/May/2016:16:36:47 -0300] NSMMReplicationPlugin -
 

[389-users] Re: Sync problems with AD 2012 R2

[Noriko Hosoi]

On 05/16/2016 01:01 PM, Alberto Viana wrote:
I'm trying to setup a new scenario with 389 and AD 2012 R2 (So far I'm 
using with AD 2008 R2 and everything works fine).
Did you use the same version of 389-ds-base against AD on 2008 R2 and 
2012 R2?

389-Directory/1.3.4.8  B2016.063.1654

Please share the output frpm this command line "rpm -q 389-ds-base"?


Windows 2012 R2 64bits

Both 2008 R2 and 2012 R2 are supported.

:
After configure the AD replication and Initiate a full sync, it starts 
to do some entries and I got the following error:



[16/May/2016:16:36:47 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): 
windows_process_total_add: Cannot replay add operation.
Does this error message follow some other detailed error messages? Such 
as ...


   YOUR_AGREEMENT_NAMEFailed to send %s operation: LDAP error
   (ERROR_CODE) ERROR_MESSAGE

or

   YOUR_AGREEMENT: Received error [%s] when attempting to %s entry
   [%s]: Please correct the attribute specified in the error message. 
   Refer to the Windows Active Directory docs for more information.


If not, could you enable the replication log level and share the error 
log with us?


And after that:

[16/May/2016:16:36:47 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Replica has no update 
vector. It has never been initialized.
[16/May/2016:16:36:47 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Replica has no update 
vector. It has never been initialized.
[16/May/2016:16:36:51 -0300] NSMMReplicationPlugin - windows sync - 
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Replica has no update 
vector. It has never been initialized.



I found a really old ticket that seems to be related to same error:

https://fedorahosted.org/389/ticket/47589
This is a regression only affected 389-ds-base-1.3.1.x.  So, 1.3.4.x 
does not need the patch.


but with win2008r2 and fixed.

According to this link -> 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/supported-ad.html


2012 R2 is supported, is that true?
Could you also share your Windows Sync agreement?  Do you happen to have 
2 Directory Servers -- one for 2008R2 and another for 2012R2, could you 
provide both?


Any clues?




--
389-users mailing list
389-users@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
389-users mailing list
389-users@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: POODLE: cve-2014-3566

[Noriko Hosoi]

Hello Derek,

The SSL range setting is supported on RHEL-7.x, but not on RHEL-6.x.

Please use "nsSSL3" and "nsTLS1" to control the SSL versions.

By default (without having nsSSL3 and nsTLS1 in 
cn=encryption,cn=config), the range is TLS1.0 through the highest the 
NSS on the system supports, e.g., TLS1.2.


Currently, there is no way to disable TLS1.0 on RHEL-6.7.  We are adding 
nsTLS1.0 option to allow disabling it.  But it is not ready yet.

Thanks.

On 05/03/2016 12:05 PM, Derek Belcher wrote:

Thank you for Mark.

I am getting a fail message when trying to set the SSL version range 
to enforce TLS1.1 through TLS1.2 When I try and replace the 
"sslversionmin" and "sslversionmax" I receive and error saying that 
the attribute is not allowed? I checked the dse.ldif to see if it was 
in there and it was not. So instead of doing a "replace" I tried an 
"add" and got the same error message.


I am obviously missing or needing something extra, but what?

 # ldapmodify -D "cn=directory manager" -W -f set_TLS_range_enforce.ldif
Enter LDAP Password:
modifying entry "cn=encryption,cn=config"
ldap_modify: Object class violation (65)
additional info: attribute "sslversionmin" not allowed

#
# cat set_TLS_range_enforce.ldif
dn: cn=encryption,cn=config
changetype: modify
replace: sslVersionMin
sslVersionMin: TLS1.1
-
replace: sslVersionMax
sslVersionMax: TLS1.2
#
#
#
# grep "dn: cn=encryption,cn=config" 
/etc/dirsrv/slapd-MY-SERVER/dse.ldif -A18

dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
nsSSL2: off
nsSSL3: off
nsTLS1: on
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=directory manager
createTimestamp: 20160107193818Z
modifyTimestamp: 20160503184243Z
nsSSL3Ciphers: 
-rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,

 +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fo
 rtezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rs
 a_export1024_with_des_cbc_sha
numSubordinates: 1

#
# rpm -qa 389*
389-admin-1.1.35-1.el6.x86_64
389-ds-console-doc-1.2.6-1.el6.noarch
389-ds-console-1.2.6-1.el6.noarch
389-ds-1.2.2-1.el6.noarch
389-admin-console-1.1.8-1.el6.noarch
389-dsgw-1.1.11-1.el6.x86_64
389-console-1.1.7-1.el6.noarch
389-adminutil-1.1.19-1.el6.x86_64
389-admin-console-doc-1.1.8-1.el6.noarch
389-ds-base-1.2.11.15-68.el6_7.x86_64
389-ds-base-libs-1.2.11.15-68.el6_7.x86_64


Thanks for your help!!!


On Tue, May 3, 2016 at 11:25 AM, Mark Reynolds > wrote:




On 05/03/2016 11:38 AM, Derek Belcher wrote:

The 389ds website is down.

We are currently working on getting the site back up.  The hosting
service(openshift) is misbehaving, and we are waiting for assistance.

Here is the contents of that page:


# How to Disable SSLv3
--

With the recent discovery of the Poodlebleed vulnerability bug
(2014/10/15), a minimum of TLS1.1 should be used instead of SSLv3.

### Disable SSLv3 in 389 Directory Server

Here is an example of how to use ldapmodify to disable SSLv3 and
enable TLS

# ldapmodify -D "cn=directory manager" -W
dn: cn=encryption,cn=config
changetype: modify
replace: nsSSL2
nsSSL2: off
-
replace: nsSSL3
nsSSL3: off
-
replace: nsTLS1
nsTLS1: on

Set the SSL version range to enforce TLS1.1 through TLS1.2.

# ldapmodify -D "cn=directory manager" -W
dn: cn=encryption,cn=config
changetype: modify
replace: sslVersionMin
sslVersionMin: TLS1.1
-
replace: sslVersionMax
sslVersionMax: TLS1.2

Note: If sslVersionMax is not explicitly set, the supported
version by the installed NSS is applied to sslVersionMax. If
sslVersionMin is not explicitly set, even if NSS supports SSL3,
TLS1.0 is set to sslVersionMin, by default.

You need to restart the server for this to take effect.

### Disable SSLv3 in favor of TLSv1.1(or higher) in 389
Administration Server

-   Stop the Admin Server
-   Edit /etc/dirsrv/admin-serv/console.conf

Change: NSSProtocol SSLv3,TLSv1
To: NSSProtocol TLSv1.1

-   Start the Admin server


### Enforce TLS verson range in the console

Edit the console preferences file and add the following lines:


# vi ~/.389-console/Console.1.1.12.Login.preferences

sslVersionMin: TLS1.1
sslVersionMax: TLS1.2

### Verify SSLv3 is Disabled

You can use the openssl client tool to verify the SSL Handshake
does NOT take place.

openssl s_client -connect hostname:389 -ssl3   # DS Port
openssl s_client -connect hostname:636 -ssl3   # DS Secure Port
openssl s_client -connect hostname:9830 -ssl3  # Admin Server Port

For more information see

[389-users] Re: CentOS 6 Upgrade and 389DS

[Noriko Hosoi]

Hello Paul,

Could you discribe your problem some more?  nss-3.21.0 is pretty new. 
Although it's tested in house, there could be something slipped...


If you still keep the error/access logs of 389-ds-base and share them 
with us, it'd be a great help, too.


Thanks,
--noriko

On 04/08/2016 05:49 AM, Paul Whitney wrote:
We upgraded our CentOS 6 build yesterday and managed to break our 
389DS service.  We have isolated the problem to a package: 
 nss-3.21.0-0.3.  When we role back the update to a previous version 
the 389ds service works fine.  Has anyone else experienced this?

Paul M. Whitney
E-mail: paul.whit...@mac.com
Sent from my browser.




--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Syntax error in ldap/admin/src/scripts/ns-accountstatus.pl.in

[Noriko Hosoi]

Thank you, Andrey.

I've opened this ticket and attached your patch to it.
https://fedorahosted.org/389/ticket/48783

On 03/31/2016 03:46 AM, Andrey Cherepanov wrote:
Our build system detects syntax error in 
ldap/admin/src/scripts/ns-accountstatus.pl.in:


String found where operator expected at 
/usr/src/tmp/389-ds-base-buildroot/usr/sbin/ns-accountstatus.pl line 
34, near "STDERR "[-i] [-g seconds]\n\n""

  (Do you need to predeclare STDERR?)
syntax error at 
/usr/src/tmp/389-ds-base-buildroot/usr/sbin/ns-accountstatus.pl line 
34, near "print"


See attached patch to fix it.

Small note: ldap/admin/src/scripts/db2index.in use Bash4 syntax 
construction (|&), but use interpreter /bin/sh

Not all Linux distributives have /bin/sh as symlink to /bin/bash4



--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Replication + SSLCLIENTAUTH failure: setup_ol_tls_conn - failed: unable to create new TLS context

[Noriko Hosoi]

How does your Replication Manager on the slave server look like?

ldapsearch -x -h  -p  [...] -b "cn=Replication 
Manager,cn=config"


Also, could you share your certmap.conf on the slave server?  And the 
Subject in the cert?



On 03/30/2016 10:30 AM, Graham Leggett wrote:

Hi all,

I have tried to set up a replication agreement on a 389ds master to send 
updates to a 389ds slave. The master is configure to use client certs for 
authentication.

The 389ds master fails each time it attempts to contact the slave with the 
following message, and tcpdump shows no traffic flowing over the wire:

[30/Mar/2016:17:19:19 +] setup_ol_tls_conn - failed: unable to create new 
TLS context
[30/Mar/2016:17:19:19 +] slapi_ldap_bind - Error: could not configure the 
server for cert auth - error -1 - make sure the server is correctly configured 
for SSL/TLS
[30/Mar/2016:17:19:19 +] NSMMReplicationPlugin - agmt="cn=Agreement 
ldap.example.com" (ldap:636): Replication bind with EXTERNAL auth failed: LDAP error 
0 (Success) ()

The server is correctly configured for SSL/TLS, and I am able to bind to both 
the master and the slave over SSL port 636.

The replication agreement looks as follows:

dn: cn=Agreement 
ldap.example.com,cn=replica,cn=dc\3Dexample\,dc\3Dcom,cn=mapping tree,cn=config
objectClass: nsds5replicationagreement
objectClass: top
cn: Agreement ldap.example.com
description: Replication agreement to ldap.example.com
nsDS5ReplicaBindDN: cn=Replication Manager,cn=config
nsDS5ReplicaBindMethod: SSLCLIENTAUTH
nsds5replicaChangesSentSinceStartup:
nsDS5ReplicaHost: ldap.example.com
nsds5replicaLastInitEnd: 0
nsds5replicaLastInitStart: 20160330162755Z
nsds5replicaLastInitStatus: 255 Replication error acquiring replica: unknown
   error
nsds5replicaLastUpdateEnd: 0
nsds5replicaLastUpdateStart: 0
nsds5replicaLastUpdateStatus: 255 Replication error acquiring replica: unkno
  wn error - Unable to acquire replica
nsDS5ReplicaPort: 636
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaTransportInfo: SSL
nsds5replicaUpdateInProgress: FALSE

Is there anything I can do to coax a useful error message out of the master server? 
"LDAP error 0 (Success)” tells me this is a bug of some kind, as why would it 
fail saying success?

This is 389ds on Ubuntu 14.04:

ii  389-ds-base   1.3.2.16-0ubuntu1amd64
389 Directory Server suite - server

Regards,
Graham
—
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: 389-Console JARs and packaging questions

[Noriko Hosoi]

Thank you for noticing. 389-admin-console-1.1.10-1.el7, 
389-ds-console-1.2.12-1.el7 have been pushed to stable.


On 03/30/2016 08:48 AM, Gordon Messmer wrote:

On 03/30/2016 07:26 AM, Lutz Berger wrote:

Are there any plans to make the RHEL 7 packages available
in the EPEL channel soon? My customer restricts use of
EPEL-TEST packages. 


Do the packages in epel-testing work for you?  If so, then go to bodhi 
and give them karma:

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1199
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-6655
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: nsSSL3 warnings

[Noriko Hosoi]

On 03/30/2016 06:57 AM, Alberto Viana wrote:

Hello,


I installed a new version of 389:

389-Directory/1.3.4.8  B2016.063.1654

And I'm getting these warnings:

[30/Mar/2016:10:47:39 -0300] - SSL alert: Found unsecure 
configuration: nsSSL3: on; We strongly recommend to disable nsSSL3 in 
cn=encryption,cn=config.

This means nsSSL3 is enabled when the server was started.
[30/Mar/2016:10:47:39 -0300] - SSL alert: Configured range: min: 
TLS1.0, max: TLS1.2; but both nsSSL3 and nsTLS1 are on. Respect the 
supported range.

This means sslVersionMin is TLS1.0 and sslVersionMax is TLS1.2.

nsSSL2, nsSSL3, and nsTLS1 are old format to specify the SSL 
version(s).  The new format is sslVersionMin and sslVersionMax. They 
coexist for the backward compatibility.


The default settings are:

 * nsSSL2, nsSSL3: off
 * nsTLS1: on
 * sslVersionMin: TLS1.0
 * sslVersionMax: supported highest TLS version

To prevent the POODLE attack, 389-ds-base disables SSLv3 by default.  To 
enable SSLv3, both nsSSL3 needs to be on and sslVersionMin needs to be 
SSL3.  This is for avoiding the accidental setting SSLv3 (which we don't 
recommend).


In your case, nsSSL3 was on when the server was started.  Please note 
that the SSL configuration is done at the server start up.  If you 
change the config parameters, you have to restart the server.


That said, this message says SSLv3 (nsSSL3: on) was ignored and the 
available range is [TLS1.0 - TLS1.2].
> [30/Mar/2016:10:47:39 -0300] - SSL alert: Configured range: min: 
TLS1.0, max: TLS1.2; but both nsSSL3 and nsTLS1 are on. Respect the 
supported range.




I already disabled nsSSL2 and nsSSL3:

dn: cn=encryption,cn=config
changetype: modify
replace: nsSSL2
nsSSL2: off
-
replace: nsSSL3
nsSSL3: off
-
replace: nsTLS1
nsTLS1: on

and confirmed that my server is only accepting TLS connections

Also tried to delete nsssl3ciphers:
dn: cn=encryption,cn=config
changetype: modify
delete: nsssl3ciphers

But it comes back.


Why I'm still getting these warnings even after to disable nsSSL2 and 
nsSSL3?



Thanks

Alberto Viana


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Unable to connect to Admin server via 389 windows console

[Noriko Hosoi]

On 03/03/2016 11:58 AM, Daniel Franciscus wrote:

SSL3 is disabled. SSL2 is the preferred and then TLS.

Is SSLv2 is enabled on your server?  It should be completely disabled.

What is the version of your server?
$ rpm -q 389-ds-base

Please note that SSL v3 was disabled since 1.3.3.6-1.
- Ticket 47928 - Disable SSL v3, by default.

And so is in the Windows Console.

What does your cn=encryption,cn=config entry look?

Thanks.




Dan Franciscus

Systems Administrator

Information Technology Group

Institute for Advanced Study

609-734-8138




*From: *"Noriko Hosoi" 
*To: *389-users@lists.fedoraproject.org
*Sent: *Wednesday, March 2, 2016 5:03:56 PM
*Subject: *[389-users] Re: Unable to connect to Admin server via 389 
windows console


Could you please double check your Directory Server is configured with 
SSLv3 disabled?

http://www.port389.org/docs/389ds/howto/howto-disable-sslv3.html

On 03/02/2016 01:35 PM, Daniel Franciscus wrote:

OK, new error now after upgrading:

Unable to create ssl socket
org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed:
(-12279) Peer using unsupported version of security protocol.
at org.mozilla.jss.ssl.SSLSocket.forceHandshake(Native Method)
at com.netscape.management.client.comm.HttpsChannel.open(Unknown
Source)
at com.netscape.management.client.comm.CommManager.send(Unknown
Source)
at com.netscape.management.client.comm.HttpManager.get(Unknown Source)
at
com.netscape.management.client.console.Console.invoke_task(Unknown
Source)
at
com.netscape.management.client.console.Console.authenticate_user(Unknown
Source)
at com.netscape.management.client.console.Console.(Unknown
Source)
at com.netscape.management.client.console.Console.main(Unknown Source)
JButtonFactory: button width = 54
JButtonFactory: button height = 20
JButtonFactory: button width = 54
JButtonFactory: button height = 20
JButtonFactory: button width = 54
JButtonFactory: button height = 20
JButtonFactory: button width = 54
JButtonFactory: button height = 20



Dan Franciscus

Systems Administrator

Information Technology Group

Institute for Advanced Study

609-734-8138





--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: ns-slapd memory usage

[Noriko Hosoi]

On 03/03/2016 11:28 AM, Gordon Messmer wrote:

On 03/02/2016 04:01 PM, William Brown wrote:
I believe there is a fix for a memory leak between 1.3.3 and 1.3.4. I 
strongly

advise upgrading to 1.3.4.8 as it fixes a number of issues.


Red Hat is still shipping 1.3.4.0 with RHEL 7.2.   Are those fixes 
included?
Please note that the versions used in Fedora (1.3.4.8, e.g.) and the 
ones in RHEL (1.3.4.0-26, e.g.) are built from the separated branches.  
1.3.4.0-26 contains the necessary fixes.


# rpm -q 389-ds-base 389-ds-base-libs
389-ds-base-1.3.4.0-26.el7_2.x86_64
389-ds-base-libs-1.3.4.0-26.el7_2.x86_64
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Unable to connect to Admin server via 389 windows console

[Noriko Hosoi]

Could you please double check your Directory Server is configured with 
SSLv3 disabled?

http://www.port389.org/docs/389ds/howto/howto-disable-sslv3.html

On 03/02/2016 01:35 PM, Daniel Franciscus wrote:

OK, new error now after upgrading:

Unable to create ssl socket
org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: 
(-12279) Peer using unsupported version of security protocol.

at org.mozilla.jss.ssl.SSLSocket.forceHandshake(Native Method)
at com.netscape.management.client.comm.HttpsChannel.open(Unknown Source)
at com.netscape.management.client.comm.CommManager.send(Unknown Source)
at com.netscape.management.client.comm.HttpManager.get(Unknown Source)
at com.netscape.management.client.console.Console.invoke_task(Unknown 
Source)
at 
com.netscape.management.client.console.Console.authenticate_user(Unknown 
Source)

at com.netscape.management.client.console.Console.(Unknown Source)
at com.netscape.management.client.console.Console.main(Unknown Source)
JButtonFactory: button width = 54
JButtonFactory: button height = 20
JButtonFactory: button width = 54
JButtonFactory: button height = 20
JButtonFactory: button width = 54
JButtonFactory: button height = 20
JButtonFactory: button width = 54
JButtonFactory: button height = 20



Dan Franciscus

Systems Administrator

Information Technology Group

Institute for Advanced Study

609-734-8138




*From: *"Mark Reynolds" 
*To: *"General discussion list for the 389 Directory server project." 
<389-users@lists.fedoraproject.org>, mreyno...@redhat.com

*Sent: *Wednesday, March 2, 2016 11:03:21 AM
*Subject: *[389-users] Re: Unable to connect to Admin server via 389 
windows console




On 03/02/2016 08:29 AM, Daniel Franciscus wrote:

C:\Program Files\389 Management Console>"java"
"-Djava.library.path=." -cp

"./jss4.jar;./ldapjdk.jar;./idm-console-base.jar;./idm-console-mcc.jar;./idm-console-mcc_en.jar;./idm-console-nmclf.jar;./idm-console-nmclf_en.jar;./389-console_en.jar"
-Djava.util.prefs.systemRo
ot=I:\/.389-console -Djava.util.prefs.userRoot=I:\/.389-console
-Djava.net.preferIPv4Stack=true
com.netscape.management.client.console.Console -D 9
java.util.prefs.userRoot=I:\/.389-console
java.runtime.name=Java(TM) SE Runtime Environment
sun.boot.library.path=C:\Program Files\Java\jre7\bin
java.vm.version=23.5-b02
java.vm.vendor=Oracle Corporation
java.vendor.url=http://java.oracle.com/
path.separator=;
java.vm.name=Java HotSpot(TM) 64-Bit Server VM
file.encoding.pkg=sun.io
user.country=US
user.script=
sun.java.launcher=SUN_STANDARD
sun.os.patch.level=
java.vm.specification.name=Java Virtual Machine Specification
user.dir=C:\Program Files\389 Management Console
java.runtime.version=1.7.0_09-b05
java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment
java.endorsed.dirs=C:\Program Files\Java\jre7\lib\endorsed
os.arch=amd64
java.io.tmpdir=C:\Users\hermes\AppData\Local\Temp\
line.separator=

java.vm.specification.vendor=Oracle Corporation
user.variant=
os.name=Windows Server 2012
sun.jnu.encoding=Cp1252
java.library.path=.
java.specification.name=Java Platform API Specification
java.class.version=51.0
java.net.preferIPv4Stack=true
sun.management.compiler=HotSpot 64-Bit Tiered Compilers
os.version=6.2
user.home=C:\Users\hermes
user.timezone=America/New_York
java.awt.printerjob=sun.awt.windows.WPrinterJob
file.encoding=Cp1252
java.specification.version=1.7

java.class.path=./jss4.jar;./ldapjdk.jar;./idm-console-base.jar;./idm-console-mcc.jar;./idm-console-mcc_en.jar;./idm-console-nmclf.jar;./idm-console-nmclf_en.jar;./389-console_en.jar
user.name=hermes
java.vm.specification.version=1.7
sun.java.command=com.netscape.management.client.console.Console -D 9
java.home=C:\Program Files\Java\jre7
sun.arch.data.model=64
java.util.prefs.systemRoot=I:\/.389-console
user.language=en
java.specification.vendor=Oracle Corporation
awt.toolkit=sun.awt.windows.WToolkit
java.vm.info=mixed mode
java.version=1.7.0_09
java.ext.dirs=C:\Program
Files\Java\jre7\lib\ext;C:\Windows\Sun\Java\lib\ext
sun.boot.class.path=C:\Program
Files\Java\jre7\lib\resources.jar;C:\Program
Files\Java\jre7\lib\rt.jar;C:\Program
Files\Java\jre7\lib\sunrsasign.jar;C:\Program
Files\Java\jre7\lib\jsse.jar;C:\Program
Files\Java\jre7\lib\jce.jar;C:\Program Files\Java\jre7\lib\charsets.ja
r;C:\Program Files\Java\jre7\lib\jfr.jar;C:\Program
Files\Java\jre7\classes
java.vendor=Oracle Corporation
file.separator=\
java.vendor.url.bug=http://bugreport.sun.com/bugreport/
sun.io.unicode.encoding=UnicodeLittle
sun.cpu.endian=little
sun.desktop=windows
sun.cpu.isalist=amd64
*389-Management-Console/1.1.14 B2015.147.2124*


You are not on the latest software.  The

[389-users] Re: "manage certificates" broken in admin console after running setup-ds-admin.pl -u

[Noriko Hosoi]

Thank you for your update.

It looks you hit this bug.
https://fedorahosted.org/389/ticket/48409

Sorry for the inconvenience.

On 02/24/2016 08:20 AM, Torgersen, Eric A wrote:

An update on this... after more investigation the cause seems to be that 
setup-ds-admin.pl -u changes the ownership of the key3.db and cert8.db files in 
/etc/dirsrv/admin-serv to root, rather than the user that the admin server is 
set to run as.  Changing the ownership of these back fixes the problem.

Eric Torgersen
Senior Systems Analyst
Information Technology Services
518-250-9725


-Original Message-
From: Torgersen, Eric A [mailto:etorger...@albany.edu]
Sent: Tuesday, February 23, 2016 3:44 PM
To: General discussion list for the 389 Directory server project.
Subject: [389-users] "manage certificates" broken in admin console after 
running setup-ds-admin.pl -u

I am testing upgrading from 1.3.4.0-21.el7_2 to 1.3.4.0-26.el7_2.  After the upgrade, I have 
noticed that "Manage Certificates" no longer works in the admin console.  I receive the 
following error: "NSS shutdown failed: error -8038:unknown."

After doing some additional testing, it appears that just running "setup-ds-admin.pl 
-u" is sufficient to cause this problem, even without upgrading the 389 packages 
using yum update.  Has anyone else run into this problem?

Thanks,
Eric

Eric Torgersen
Senior Systems Analyst
Information Technology Services
518-250-9725

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: ldapdelete not successful

[Noriko Hosoi]

On 02/23/2016 02:28 PM, Joel Levin wrote:
Odd conundrum - deletion has not been successful on a node with 
children, or the children itself.


Previously could delete as expected.

Any guidance would be appreciated.

Version: 389-Directory/1.2.11.29  B2014.094.1833 
(multi-master: 2 providers, 3 consumers)

I'm afraid this is not the supported version.

For el6 (as well as el6_#), 1.2.11.15-## is the supported version format.

For instance, please see this site: 
https://www.rpmfind.net/linux/rpm2html/search.php?query=389-ds-base


389-ds-base-1.2.11.15-69.el6_7.i686.html 
 
	389 Directory Server (base) 	Updates for CentOS 6.7 for i386 
389-ds-base-1.2.11.15-69.el6_7.i686.rpm 
 

389-ds-base-1.2.11.15-69.el6_7.x86_64.html 
 
	389 Directory Server (base) 	Updates for CentOS 6.7 for x86_64 
389-ds-base-1.2.11.15-69.el6_7.x86_64.rpm 
 




We fixed lots of bugs since Apr 4 2014, on that day 
389-ds-base-1.2.11.29 was tagged.  Could you please upgrade your system 
and retry?


Error Log:

[23/Feb/2016:14:13:49 -0800] entryrdn-index - _entryrdn_delete_key: 
Failed to remove ou=vurs; has children
[23/Feb/2016:14:13:49 -0800] - database index operation failed BAD 
1031, err=-1 Unknown error: -1
[23/Feb/2016:14:13:50 -0800] slapi_ldap_bind - Error: could not send 
bind request for id [cn=replication manager,cn=config] mech [SIMPLE]: 
error -1 (Can't contact LDAP server) 0 (unknown) 107 (Transport 
endpoint is not connected)



--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Announcing 389 Windows Console 1.1.15 with the SSL problem fixed

[Noriko Hosoi]

   389 Windows Console 1.1.15

The 389 Directory Server team is proud to announce 389-console-win 
version 1.1.15.


Windows installers are available to download from Download 389 Windows 
Console (32-bit) 
 and 
Download 389 Windows Console (64-bit) 
.



 Highlights in 389-console-win-1.1.15

 * Windows Console now has the same bug fixes and enhancements made for
   the Fedora 389-console.
 * *A connection failure problem over **SSL**/start**TLS**was fixed.*


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install and update, use Programs and Features on Control Panel.


 Feedback

We are very interested in your feedback!

If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelogs

See also 389-console-1.1.19, 389-admin-console-1.1.10 release notes 
 and 
389-ds-console-1.2.12 and idm-console-framework-1.1.14 release notes 
 
for Fedora.


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Can't use local time format on a Generalized Time attribute

[Noriko Hosoi]

On 02/18/2016 01:00 PM, Mark Reynolds wrote:



On 02/18/2016 03:55 PM, Mark Reynolds wrote:



On 02/18/2016 03:43 PM, jfill...@central1.com wrote:
I'm migrating a DS from RHDS 8.2 to 389 DS and i'm having an issue 
attributes of type 'Generalized Time'.


One my old LDAP server, i could set dates in this format: 
20160215133951.842


389 DS 1.2.11 doesn't seem to allow this local time version. Is 
there any way to enable/allow this?
Not that I know of, but "20160215133951.842"  does not seem to comply 
with the LDAP RFC for generalized time:


https://tools.ietf.org/html/rfc4517#section-3.3.13
Actually it does allow for the period, so it should be valid... Please 
open a ticket to have this investigated:


https://fedorahosted.org/389/newticket
Not sure I'm reading this correctly, but according to this notation, 
g-time-zone needs to be there after fraction which contains dot or comma 
and is optional.


  GeneralizedTime = century year month day hour
   [ minute [ second / leap-second ] ]
   [ fraction ]
   g-time-zone

And g-time-zone has to end with Z or g-differential.

  g-time-zone = %x5A  ; "Z"
/ g-differential
  g-differential  = ( MINUS / PLUS ) hour [ minute ]

So, it looks to me the allowed formats are ...

  Examples:
 199412161032Z
 199412160532-0500
 199412160532+0500

as well as

   20141006133000.0Z
   20141006133000.0-0500
   20141006133000.0+0500

Could it be possible to try adding 'Z' at the end of 20160215133951.842 
and see how 389-ds-base-1.2.11.x reacts?


Thanks,
--noriko

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org 


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org 


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server version 1.3.4.8

[Noriko Hosoi]

   389 Directory Server 1.3.4.8

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.4.8.


Fedora packages are available from the Fedora 22, 23 and 
Rawhide repositories.


The new packages and versions are:

 * 389-ds-base-1.3.4.8-1

Source tarballs are available for download at Download 389-ds-base 
Source 
 and 
Download nunc-stans Source 
.



 Highlights in 1.3.4.8

 * Various bugs including a security bug 1299417 are fixed.


 Installation and Upgrade

See Download 
 for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for 
more information about the initial installation, setup, and upgrade


See Source 
 
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.org 
as well as 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.8-1.fc22 
 and 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.8-1.fc23 
.


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.4.5

 * Ticket 47788 - Supplier can skip a failing update, although it
   should retry
 * Ticket 48289 - 389-ds-base: ldclt-bin killed by SIGSEGV
 * Ticket 48305 - perl module conditional test is not conditional when
   checking SELinux policies
 * Ticket 48312 - Crash when doing modrdn on managed entry
 * Ticket 48332 - allow users to specify to relax the FQDN constraint
 * Ticket 48341 - deadlock on connection mutex
 * Ticket 48362 - With exhausted range, part of DNA shared
   configuration is deleted after server restart
 * Ticket 48369 - RFE - Add config setting to always send the password
   expiring time
 * Ticket 48370 - The ‘eq’ index does not get updated properly when
   deleting and re-adding attributes in the same modify operation
 * Ticket 48375 - SimplePagedResults – in the search error case, simple
   paged results slot was not released.
 * Ticket 48388 - db2ldif -r segfaults from time to time
 * Ticket 48406 - Avoid self deadlock by PR_Lock(conn->c_mutex)
 * Ticket 48412 - worker threads do not detect abnormally
   closed connections
 * Ticket 48445 - keep alive entries can break replication
 * Ticket 48448 - dirsrv start-stop fail in certain shell environments.
 * Ticket 48492 - heap corruption at schema replication.
 * Ticket 48536 - Crash in slapi_get_object_extension

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Crash logs

[Noriko Hosoi]

On 01/27/2016 12:33 PM, Todor Petkov wrote:


On 1/27/2016 10:20 PM, Mark Reynolds wrote:

The server is crashing in the NSS library:

Program terminated with signal 4, Illegal instruction.
#0  0x7f82f5bdad60 in ?? () from /usr/lib64/libfreeblpriv3.so

Thread 1 (Thread 0x7f82d7fff700 (LWP 25001)):
#0  0x7f82f5bdad60 in ?? () from /usr/lib64/libfreeblpriv3.so
No symbol table info available.
#1  0x7f82f5bd7998 in ?? () from /usr/lib64/libfreeblpriv3.so
No symbol table info available.
#2  0x7f82f5ba0b36 in ?? () from /usr/lib64/libfreeblpriv3.so
No symbol table info available.
#3  0x7f82f5ba10f3 in ?? () from /usr/lib64/libfreeblpriv3.so
No symbol table info available.
#4  0x7f82f60a9aef in ?? () from /usr/lib64/libsoftokn3.so
No symbol table info available.
#5  0x7f82f60aa504 in ?? () from /usr/lib64/libsoftokn3.so
No symbol table info available.
#6  0x7f8300684dbe in PK11_Decrypt ()
#7  0x7f83009902bd in ssl3_AESGCM (}
#8  0x7f83009952fd in ssl3_HandleRecord ()
#9  0x7f830099669f in ssl3_GatherCompleteHandshake ()
#10 0x7f8300999022 in ssl_GatherRecord1stHandshake ()
#11 0x7f83009a0185 in ssl_Do1stHandshake ()
#12 0x7f83009a13b7 in ssl_SecureRecv ()
#13 0x7f83009a5402 in ssl_Recv ()
...
...


This might be a known issue with NSS.  What version of 389 and NSS are
you using?

rpm -qa | grep 389-ds-base
rpm -qa | grep "^nss"


389-ds-base-1.2.11.15-68.el6_7.x86_64
389-ds-base-debuginfo-1.2.11.15-68.el6_7.x86_64
389-ds-base-libs-1.2.11.15-68.el6_7.x86_64


nss-3.19.1-8.el6_7.x86_64
nss-softokn-freebl-3.14.3-23.el6_7.x86_64
nss-util-3.19.1-2.el6_7.x86_64
nss-softokn-3.14.3-23.el6_7.x86_64
nss-sysinit-3.19.1-8.el6_7.x86_64
nss-debuginfo-3.19.1-8.el6_7.x86_64
nss-tools-3.19.1-8.el6_7.x86_64


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
You might have hit a nss-softokn - processor mismatch issue.  Could you 
please try this workaround?


We would like to know setting the following environment variable(s) changes the 
behavior.
1)
Open /etc/sysconfig/dirsrv and add the following line:
export NSS_DISABLE_HW_GCM=1
Restart the Directory Server.
Does the LDAP/TLS request crash the server?
2)
If the server still crashes, add another variable to /etc/sysconfig/dirsrv:
export NSS_DISABLE_HW_AES=1
Restart the Directory Server.
Does the LDAP/TLS request crash the server?
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: CentOS 7: unable to create AdmldapInfo

[Noriko Hosoi]

> I’m experimenting with upgrading 389DS to 1.3.4.0-21.el7_2 on CentOS 
7 (I neglected to note what version I had previously).


Could you also tell us the version of the 389-admin and adminutil?
rpm -q 389-admin 389-adminutil

There is a known issue that anonymous binds are necessary when the admin 
server is registered.

https://fedorahosted.org/389/ticket/48213
Ticket #48213  - Admin server 
registration requires anonymous binds


Thanks.

On 01/05/2016 07:30 AM, Rich Megginson wrote:

On 01/04/2016 08:50 PM, David Barr wrote:

On Jan 4, 2016, at 07:53, Rich Megginson  wrote:

We'll need to know what platform/version you are upgrading from, because there 
is not supposed to be a missing log directory, and the SELinux labels are 
already supposed to be provided.  In order for us to fix this issue, we need to 
know how to reproduce it.

I’m not going to be able to figure out the previous version, but it turns out 
it doesn’t matter. I have a “Blow It Away And Start Over” script[1], and going 
through that process has been illuminating. The delete and install section for 
CentOS 7 is relevant for the two possible bug write ups:

```
(case statement separating CentOS 6 and CentOS 7)
   7)
 systemctl stop dirsrv.target
 systemctl stop dirsrv-admin

 yum -y remove \
   389-ds-base \
   389-ds-base-libs \
   389-admin \
   389-adminutil

 selinuxenabled \
   && semanage port \
   --delete \
   --proto tcp \
   9830

 rm -rf /etc/dirsrv \
   /usr/lib64/dirsrv \
   /var/lib/dirsrv \
   /var/log/dirsrv \
   /var/run/dirsrv

 yum -y install \
   389-ds-base \
   389-ds-base-libs \
   389-admin \
   389-adminutil

 if [ ! -d /var/log/dirsrv/admin-serv ]
 then
   mkdir -p /var/log/dirsrv/admin-serv
 fi

 # Open the port for the httpd running the admin server.
 selinuxenabled \
   && semanage port \
   --add \
   --type http_port_t \
   --proto tcp \
   9830
 ;;
esac


/usr/sbin/setup-ds-admin.pl --file=${df_389ds_setup} --silent
```

When I run the script with `set -x`, I see the test for the absence of the 
admin-serv log directory return true and the directory gets created. Also, the 
`semanage port —add` returns without error, particularly without the error 
telling me that port 9830 has already been added. I have not tried the 
directory and semanage tests *after* setup-ds-admin.pl. If the directory and 
the port setup are handled in the script, I’m just catching the changes early.


OK.  So it is possible that the problem is that we don't clearly 
document how to blow everything away and start over from scratch. The 
setup-ds-admin.pl --force is supposed to do that, but perhaps it has a 
bug.



Now, on to my original problem, which still appears. First, some `cn=config` setting 
changes in my “BIAASO" script:

```
dn: cn=config
changetype: modify
replace: passwordStorageScheme
passwordStorageScheme: SSHA256
-
replace: nsslapd-security
nsslapd-security: on
-
replace: nsslapd-ssl-check-hostname
nsslapd-ssl-check-hostname: off
-
replace: nsslapd-certdir
nsslapd-certdir: ${d_nssdb}
-
replace: nsslapd-allow-anonymous-access
nsslapd-allow-anonymous-access: off
-
replace: nsslapd-require-secure-binds
nsslapd-require-secure-binds: on
-
replace: nsslapd-listenhost
nsslapd-listenhost: 127.0.0.1
-
replace: nsslapd-securelistenhost
nsslapd-securelistenhost: $(hostname -f)
```


Does it work if you enable anonymous access and/or disable secure binds?


So, I edit `/etc/dirsrv/admin-serv/adm.conf` to change 
`ldapurl:ldaps://$(hostname  -f):636/o=NetscapeRoot`.

Now, I can get tohttp://localhost:9830, and log in with the admin user and 
password. I click through to get to the “Start Config DS” button. Once I click 
on that, I get a “StartConfigDS Error, your request could not be fulfilled.” 
And, my slapd access log shows this (with some obfuscation):

```
[04/Jan/2016:19:15:53 -0800] conn=6 fd=65 slot=65 SSL connection from 
${correct_ip} to ${correct_ip}
[04/Jan/2016:19:15:53 -0800] conn=6 TLS1.2 256-bit AES
[04/Jan/2016:19:15:53 -0800] conn=6 op=0 BIND dn="cn=admin-serv-$(hostname 
-s),cn=389 Administration Server,cn=Server Group,cn=$(hostname -f),ou=$(hostname 
-d),o=NetscapeRoot" method=128 version=3
[04/Jan/2016:19:15:53 -0800] conn=6 op=0 RESULT err=48 tag=97 nentries=0 etime=0
[04/Jan/2016:19:15:53 -0800] conn=6 op=1 UNPROCESSED OPERATION - Anonymous 
access not allowed
[04/Jan/2016:19:15:53 -0800] conn=6 op=1 RESULT err=48 tag=101 nentries=0 
etime=0
[04/Jan/2016:19:15:53 -0800] conn=6 op=2 UNBIND
[04/Jan/2016:19:15:53 -0800] conn=6 op=2 fd=65 closed - U1
```

Now, the contents of `adm.conf`, again with some obfuscation:

```
# cat /etc/dirsrv/admin-serv/adm.conf
AdminDomain: $(hostname -d)
sysuser: nobody
isie: cn=389 Administration Server,cn=Server Group,cn=$(hostname 
-f),ou=$(hostname -d),o=NetscapeRoot
SuiteSpotGroup: nobody
sysgroup:

[389-users] Re: 389 Windows Console

[Noriko Hosoi]

Hello Phil,

We are working on the issue, but not sure what the root cause is yet.

If you could try the new installer I have just uploaded, it would be a 
big help for us.  (Please note that the version remains the same 1.1.15.)

http://www.port389.org/docs/389ds/download.html#windows-console

Thank you,
--noriko

On 01/04/2016 09:22 AM, Phil Daws wrote:

- On 4 Jan, 2016, at 16:45, Rich Megginson rmegg...@redhat.com wrote:


On 01/04/2016 09:23 AM, Phil Daws wrote:

Hello Rich,

Have ran in debug mode and connected to the admin interface which has been
secured with a cert:

{SUBJECT_DN=CN=ads01-admin.lab, SUBJECT={CN=ads01-admin},
SERIAL=8741097289627376099, AFTERDATE=Tue Dec 19 14:05:35 2017,
ISSUER={CN=LAB-CA, O=LAB, C=GB}, SIGNATURE=SHA256withRSA, BEFOREDATE=Sun Dec 20
14:05:35 2015, KEYTYPE=RSA, REASONS={}, VERSION=3, ISSUER_DN=C=GB, O=LAB,
CN=LAB-CA}
JButtonFactory: button width = 54
JButtonFactory: button height = 20
JButtonFactory: button width = 54
JButtonFactory: button height = 20
JButtonFactory: button width = 72
JButtonFactory: button height = 20
JButtonFactory: button width = 72
JButtonFactory: button height = 20
JButtonFactory: button width = 54
JButtonFactory: button height = 20
JButtonFactory: button width = 72certain
HttpsChannel::select(...) - SELECT CERTIFICATE
Unable to create ssl socket
org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-8186)
security library: invalid algorithm.
at org.mozilla.jss.ssl.SSLSocket.forceHandshake(Native Method)
at com.netscape.management.client.comm.HttpsChannel.open(Unknown Source)
at com.netscape.management.client.comm.CommManager.send(Unknown Source)
at com.netscape.management.client.comm.HttpManager.get(Unknown Source)
at com.netscape.management.client.console.Console.invoke_task(Unknown 
Source)
at 
com.netscape.management.client.console.Console.authenticate_user(Unknown
Source)
at com.netscape.management.client.console.Console.(Unknown Source)
at com.netscape.management.client.console.Console.main(Unknown 
Source)certain

So it accepts the admin certificate fine but then shows an empty selection box
for a certificate ?

Not sure what it means by "invalid algorithm" but it looks as though
that is the root cause. The console doesn't know what to do with that
error, so it asks you to select another cert, which is just a
distraction at that point.  Please open a ticket.

Hmm, but that "invalid algorithm" message only appeared when I clicked on 
continue with no certificate showing in the selection dropdown list.  The admin 
certificate was accepted fine and then it showed the empty selection list.





Thanks, Phil

- On 4 Jan, 2016, at 15:50, Rich Megginson rmegg...@redhat.com wrote:


On 01/04/2016 01:11 AM, Phil Daws wrote:

Any thoughts on this please ?

- On 20 Dec, 2015, at 16:02, Phil Daws ux...@splatnix.net wrote:


Hello,

Have now got to the point where it says "Select a certificate to authenticate"
yet the drop down box is empty.

Can you run the console with -D 9 -f console.log, then check console.log
to remove any sensitive information, then post that to this list?  The
easiest way to do this is to make a copy of the .bat file that runs the
console, then add those arguments to the command line in the copy of the
.bat file.

I'm assuming you have not configured the admin server/directory server
to require client cert authentication.  If you don't know, then you
probably haven't.


If I check the NSS database it looks okay ?

D:\Scratch\firefox_add-certs\bin>certutil.exe -d "c:\Documents and
Settings\pmdaws\.389-console" -L

Certificate Nickname Trust Attributes
   
SSL,S/MIME,JAR/XPI

LAB CA Certificate   CT,,
Phil Dawsp,p,p

Seems as though the console is not picking them up :(

Thanks, Phil
- On 15 Dec, 2015, at 20:35, Noriko Hosoi nho...@redhat.com wrote:


On 12/15/2015 11:40 AM, Phil Daws wrote:

Hello,

Unfortunately I do not have a console under Fedora/RHEL.

I can log into the Administration console fine, but when I click on Server
Group, and then double click on the Directory Server it prompts me for the
Distinguished name and password.  The status is showing as:

Server status: Stopped
Port: 636

The ports are listening fine:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State
PID/Program name
tcp0  0 0.0.0.0:22  0.0.0.0:*   LISTEN
301/sshd
tcp0  0 0.0.0.0:98300.0.0.0:*   LISTEN
1261/httpd
tcp6   0  0 :::22   :::*LISTEN
301/sshd
tcp6   0  0 :::636  :::*

[389-users] Re: 389 Windows Console

[Noriko Hosoi]

On 12/15/2015 11:40 AM, Phil Daws wrote:

Hello,

Unfortunately I do not have a console under Fedora/RHEL.

I can log into the Administration console fine, but when I click on Server 
Group, and then double click on the Directory Server it prompts me for the 
Distinguished name and password.  The status is showing as:

Server status: Stopped
Port: 636

The ports are listening fine:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State   
PID/Program name
tcp0  0 0.0.0.0:22  0.0.0.0:*   LISTEN  
301/sshd
tcp0  0 0.0.0.0:98300.0.0.0:*   LISTEN  
1261/httpd
tcp6   0  0 :::22   :::*LISTEN  
301/sshd
tcp6   0  0 :::636  :::*LISTEN  
1196/ns-slapd
tcp6   0  0 :::389  :::*LISTEN  
1196/ns-slapd

So am guessing it's probably due to when I enabled "Secure Connection" in the 
console :(

Any thoughts please ?

Not sure yet, but did you have a chance to see this section?
http://www.port389.org/docs/389ds/howto/howto-ssl.html#admin-server-tlsssl-information


Thanks, Phil



- On 15 Dec, 2015, at 19:01, Noriko Hosoi nho...@redhat.com wrote:


On 12/15/2015 09:51 AM, Phil Daws wrote:

Hello,

I have 389 up and running in my lab, with encryption enabled, but when I connect
too the Administration panel and double click on the Directory Server it just
hangs.  The CA certificate has been imported using:

d:\Scratch\firefox_add-certs\bin>certutil -A -d "C:\Documents and
Settings\phild\.389-console" -n "CA Certificate" -t CT,, -i
d:\Downloads\CA-chain.pem -a

Am I missing something obvious please ?

Thanks, Phil

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

Administration URL starts with https?

If you use Console on Fedora/RHEL, you have no problem?

Thanks.
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server version 1.3.3.14

[Noriko Hosoi]

   389 Directory Server 1.3.3.14

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.3.14.


Fedora packages are available from the Fedora 21 repositories.

The new packages and versions are:

 * 389-ds-base-1.3.3.14-1

A source tarball is available for download at Download Source 




 Highlights in 1.3.3.14

 * Various bugs are fixed.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users as well as 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.3.14-1.fc21 
.


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.3.13

 * Ticket 47553 - Automated the verification procedure
 * Ticket 47957 - Add replication test suite for a wait async feature
 * Ticket 47976 - deadlock in mep delete post op
 * Ticket 47978 - Deadlock between two MODs on the same entry between
   entry cache and backend lock
 * Ticket 48192 - Individual abandoned simple paged results request has
   no chance to be cleaned up
 * Ticket 48208 - CleanAllRUV should completely purge changelog
 * Ticket 48226 - In MMR, double free coould occur under some
   special condition
 * Ticket 48264 - Ticket 47553 tests refactoring
 * Ticket 48266 - Fractional replication evaluates several times the
   same CSN
 * Ticket 48266 - coverity issue
 * Ticket 48266 - do not free repl keep alive entry on error
 * Ticket 48266 - Online init crashes consumer
 * Ticket 48273 - Update lib389 tests for new valgrind functions
 * Ticket 48283 - many attrlist_replace errors in connection
   with cleanallruv
 * Ticket 48284 - free entry when internal add fails
 * Ticket 48299 - pagedresults - when timed out, search results could
   have been already freed.
 * Ticket 48304 - ns-slapd - LOGINFO:Unable to remove file
 * Ticket 48305 - perl module conditional test is not conditional when
   checking SELinux policies
 * Ticket 48325 - Add lib389 test script
 * Ticket 48325 - Replica promotion leaves RUV out of order
 * Ticket 48338 - SimplePagedResults – abandon could happen between the
   abandon check and sending results

http://www.port389.org/docs/389ds/releases/release-1-3-3-14.html

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Announcing 389 Directory Server version 1.3.4.5

[Noriko Hosoi]

   389 Directory Server 1.3.4.5

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.4.5.


Fedora packages are available from the Fedora 22, 23 and 
Rawhide repositories.


The new packages and versions are:

 * 389-ds-base-1.3.4.5-1

Source tarballs are available for download at Download 389-ds-base 
Source  and 
Download nunc-stans Source 
.



 Highlights in 1.3.4.5

 * Various bugs are fixed.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users as well as 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.5-1.fc22 
 and 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.5-1.fc23 
.


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.4.4

 * Ticket 47511 - bashisms in 389-ds-base admin scripts
 * Ticket 47553 - Automated the verification procedure
 * Ticket 47761 - Added a few testcases to the basic testsuite
 * Ticket 47957 - Add replication test suite for a wait async feature
 * Ticket 47976 - deadlock in mep delete post op
 * Ticket 47978 - Deadlock between two MODs on the same entry between
   entry cache and backend lock
 * Ticket 48188 - segfault in ns-slapd due to accessing Slapi_DN freed
   in pre bind plug-in
 * Ticket 48192 - Individual abandoned simple paged results request has
   no chance to be cleaned up
 * Ticket 48204 - update lib389 test scripts for python 3
 * Ticket 48217 - cleanallruv - fix regression with server shutdown
 * Ticket 48226 - In MMR, double free coould occur under some
   special condition
 * Ticket 48227 - rpm.mk doesn’t build srpms for 389-ds and nunc-stans
 * Ticket 48254 - Shell CLI fails with usage errors if an argument
   containing white spaces is given
 * Ticket 48264 - Ticket 47553 tests refactoring
 * Ticket 48266 - Fractional replication evaluates several times the
   same CSN
 * Ticket 48266 - coverity issue
 * Ticket 48266 - do not free repl keep alive entry on error
 * Ticket 48266 - Online init crashes consumer
 * Ticket 48267 - Add config setting to MO plugin to add objectclass
 * Ticket 48273 - Update lib389 tests for new valgrind functions
 * Ticket 48276 - initialize free_flags in reslimit_update_from_entry()
 * Ticket 48279 - Check NULL reference in nssasl_mutex_lock
   etc. (saslbind.c)
 * Ticket 48283 - many attrlist_replace errors in connection
   with cleanallruv
 * Ticket 48284 - free entry when internal add fails
 * Ticket 48298 - ns-slapd crash during ipa-replica-manage del
 * Ticket 48299 - pagedresults - when timed out, search results could
   have been already freed.
 * Ticket 48304 - ns-slapd - LOGINFO:Unable to remove file
 * Ticket 48305 - perl module conditional test is not conditional when
   checking SELinux policies
 * Ticket 48311 - nunc-stans: Attempt to release connection that is
   not acquired
 * Ticket 48316 - Perl-5.20.3-328: Use of literal control characters in
   variable names is deprecated
 * Ticket 48325 - Add lib389 test script
 * Ticket 48325 - Replica promotion leaves RUV out of order
 * Ticket 48338 - SimplePagedResults – abandon could happen between the
   abandon check and sending results
 * Ticket 48339 - Share nsslapd-threadnumber in the case nunc-stans is
   enabled, as well.
 * Ticket 48344 - acl - regression - trailing ‘, (comma)’ in macro
   matched value is not removed.
 * Ticket 48348 - Running /usr/sbin/setup-ds.pl fails with Can’t locate
   bigint.pm, plus two warnings

http://www.port389.org/docs/389ds/releases/release-1-3-4-5.html

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

Re: [389-users] IP Address on ACI

[Noriko Hosoi]

On 10/23/2015 04:12 PM, Joel Levin wrote:

Hi All:

I inserted the first ACI with an IP Address restriction: tested from 
all angles but seems to fail when the IP address restricted added.


ACI template:

(targetattr = "foobar") (version 3.0;acl "redcap-svc REDCap SA Read 
Only";allow (read,compare,search)(userdn = "ldap:///example";) and 
(dns="123.123.123.123");)

What happens if you use "ip" instead of "dns" as in this example?
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Access_Control-Access_Control_Usage_Examples.html


   13.9.6.1. ACI "HostedCompany1"

In LDIF, to grant |HostedCompany1| full access to their own branch of 
the directory under the requisite conditions, write the following 
statement:


aci:(target="ou=HostedCompany1,ou=corporate-clients,dc=example,dc=com")
 (targetattr= "*") (version 3.0; acl "HostedCompany1";allow (all)
 (roledn="ldap:///cn=DirectoryAdmin,ou=HostedCompany1,
 ou=corporate-clients,dc=example,dc=com") and
 (authmethod="ssl") and (dayofweek="Mon,Tues,Wed,Thu") and (timeofday >= 
"0800" and
 timeofday <= "1800") and (ip="255.255.123.234"); )



Is there an additional configuration to set for IP address restriction 
to take hold in 389 DS?


Thanks.


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] WinSync agreement deletes directoryt server users

[Noriko Hosoi]

On 10/22/2015 03:31 AM, Mizrahi, Yair wrote:


I dumped the users to LDIF file but didn’t find anything special 
between the affected and unaffected users


The only clue I found in the replication log is it doesn’t recognize 
the affected users as local (also says uid is -1) and then it deletes 
them.


Can we have the part of the log?  Of course, you could replace the real 
name with something like "#".

Thanks!


*From:*389-users-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@lists.fedoraproject.org] *On Behalf Of 
*Noriko Hosoi

*Sent:* Monday, October 19, 2015 7:35 PM
*To:* General discussion list for the 389 Directory server project.
*Subject:* Re: [389-users] WinSync agreement deletes directoryt server 
users


On 10/19/2015 09:23 AM, Mizrahi, Yair wrote:

i'll do some comparison tomorrow between affected and unaffected
user, hopefully I will find something

Thanks a lot!!

Sent from my Samsung device



 Original message ----
From: Noriko Hosoi  <mailto:nho...@redhat.com>
Date: 19/10/2015 19:04 (GMT+02:00)
To: 389-users@lists.fedoraproject.org 
<mailto:389-users@lists.fedoraproject.org>
Subject: Re: [389-users] WinSync agreement deletes directoryt server 
users


Thank you for the update.

Regarding this symptom:
> they are also gets deleted from directory server (around 200 users 
from 550).
I'm curious what's the difference between the deleted 200 users and 
the rest.


Thanks,
--noriko

On 10/19/2015 12:35 AM, Mizrahi, Yair wrote:

Hi Noriko,

This is the version I have installed:
389-ds-base-1.2.11.15-60.el6.x86_64 on CentOS 6.5

I was able to work around the problem by backing up the group and
people OU to LDIF files , do the sync (which deleted the affected
accounts)and after that importing them back, this caused the LDAP
server to sync them to AD.

BTW I noticed the initial sync is deleting the same accounts.

Thanks,

*From:*389-users-boun...@lists.fedoraproject.org
<mailto:389-users-boun...@lists.fedoraproject.org>
[mailto:389-users-boun...@lists.fedoraproject.org] *On Behalf Of
*Noriko Hosoi
*Sent:* Monday, October 19, 2015 12:23 AM
*To:* 389-users@lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
*Subject:* Re: [389-users] WinSync agreement deletes directoryt
server users

On 10/18/2015 02:06 AM, Mizrahi, Yair wrote:

Hi,

I have setup a sync agreement between directory server and
active directory 2012R2 and I’m getting a very strange
behavior, if I am doing 2 way sync (the default) the sync
completes successfully but not all the users are created in
AD, not only that , they are also gets deleted from directory
server (around 200 users from 550).

I’m syncing to Blank OU in AD

My DS version is 1.2.2-1

 Is it the version of 389-ds-base (not 389-ds)?

rpm -q 389-ds-base

Thanks,

cid:image001.gif@01CE0DED.C3CB64A0XtremIO



*Yair Mizrahi*

Sr Lab IT engineer

Office: + 972 722563243

Mobile: + 972 54 2327687

Email: yair.mizr...@emc.com <mailto:yair.mizr...@emc.com>



**



*EMC² - XtremIO
*Glil Yam 46905,

Herzliya,

Israel
www.emc.com <http://www.emc.com/>



--

389 users mailing list

389-users@lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>

https://admin.fedoraproject.org/mailman/listinfo/389-users



--

389 users mailing list

389-users@lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>

https://admin.fedoraproject.org/mailman/listinfo/389-users





--
389 users mailing list
389-users@lists.fedoraproject.org 
<mailto:389-users@lists.fedoraproject.org>

https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Help with understanding 389-ds, multiple server setup and TLS/SSL

[Noriko Hosoi]

On 10/20/2015 10:02 AM, Tom Fallon wrote:


Hi folks

I've inherited a 389-ds server (let's call that Server1) running 
version 389-Management-Console/1.1.7 B2011.172.2016 on which I've been 
tasked with getting replication working on a second server (Server2). 
I am not new to Linux but am new to System Administration having made 
the jump from Helpdesk recently so please bear with me if these seem 
like stupid questions


I've struck one hurdle already whereby I can no longer log in on the 
Console to Server1 and am getting error:


Error:
Cannot logon because of an incorrect User ID
Incorrect password or Directory problem.
java.io  interruptedIOException: HTTP response timeout

I think this has occurred while I tried to get SSL certs 
copied/exported to a Server2 as log files show the following.


[06/Oct/2015:23:46:46 +0100] attrcrypt - attrcrypt_cipher_init: 
symmetric key failed to unwrap with the private key; Cert might have 
been renewed since the key is wrapped.  To recover the encrypted 
contents, keep the wrapped symmetric key value.
[06/Oct/2015:23:46:46 +0100] attrcrypt - All prepared ciphers are not 
available. Please disable attribute encryption.
[06/Oct/2015:23:46:46 +0100] attrcrypt - attrcrypt_unwrap_key: failed 
to unwrap key for cipher AES
[06/Oct/2015:23:46:46 +0100] attrcrypt - attrcrypt_cipher_init: 
symmetric key failed to unwrap with the private key; Cert might have 
been renewed since the key is wrapped.  To recover the encrypted 
contents, keep the wrapped symmetric key value.
[06/Oct/2015:23:46:46 +0100] attrcrypt - attrcrypt_unwrap_key: failed 
to unwrap key for cipher 3DES
[06/Oct/2015:23:46:46 +0100] attrcrypt - attrcrypt_cipher_init: 
symmetric key failed to unwrap with the private key; Cert might have 
been renewed since the key is wrapped.  To recover the encrypted 
contents, keep the wrapped symmetric key value.
[06/Oct/2015:23:46:46 +0100] attrcrypt - All prepared ciphers are not 
available. Please disable attribute encryption.
[06/Oct/2015:23:46:47 +0100] - Skipping CoS Definition 
cn=nsAccountInactivation_cos,dc=example,dc=com--no CoS Templates 
found, which should be added before the CoS Definition.
[06/Oct/2015:23:46:47 +0100] - slapd started.  Listening on All 
Interfaces port 389 for LDAP requests
[06/Oct/2015:23:46:47 +0100] - Listening on All Interfaces port 636 
for LDAPS requests


So in theory I recreate the SSL certs on Server1 export to Server2 and 
continue on.


I'd appreciate if someone could help in my understanding of how this 
is supposed to work in a multi server environment as despite reading 
the documentation 
here:https://access.redhat.com/documentation/en/red-hat-directory-server/ I'm 
struggling to get my head around things.


My understanding is there are these main components (I'm ignoring SNMP 
bit for now):


- Directory Server located at /etc/dirsrv/slapd-instance and 
containing all the LDAP server pieces and command line tools
- Admin Server located at /etc/dirsrv/admin-serv - docs refer to the 
controlling portals which access LDAP server and refers to "Using the 
Admin server" guide - I'm presuming this is the Administration Guide now
- Directory Server console - various docs I've read refer to this as 
the Directory Server Console or the Admin Console which then 
bamboozles me as to whether its incorporated in Directory Server or 
Admin Server.


I've been trying to follow this guide to multi-master SSL setup 
-http://directory.fedoraproject.org/docs/389ds/howto/howto-walkthroughmultimasterssl.html and 
tweaking for my version of OS (Centos 6.7) and 389-ds but not getting 
very far.


Can anyone point me to a more up to date guide or provide some form of 
idiot-proof guide to get this working? I've been banging my head on 
this for a couple weeks now and despite reading the docs and a load of 
googling I'm not getting very far.


I have the install part down ok including disktuning, file 
descriptors, keepalive, port ranges etc and 389-ds itself of course. 
And on Server2 I can log in to the console using http and a basic LDAP 
test works fine using:


ldapsearch -x -b "dc=example,dc=com"

I think whoever setup the existing Directory Server used a self-signed 
cert as there are pwdfile and noise.txt files in the slapd-instance 
directory so looks like something like this was used to generate the 
CA Cert and Server Cert


certutil -S -n "CA certificate" -s "cn=CAcert" -x -t "CT,," -m 1000 -v 120 -d 
*.* -z noise.txt -f pwdfile.txt
certutil -S -n "Server-Cert" -s "cn=server.example.com 
,cn=Directory Server" -c "CA certificate" -t "u,u,u" -m 1001 -v 120 -d 
*.* -z noise.txt -f pwdfile.txt


What I don't have a note of is the unique numbers entered with the -m 
switch. Is there a way to tell what these are after the fact as I 
believe they need to be unique across servers, correct?


Also can someone explain how I export the CA Cert from server 1 to 
server 2 - the docs don't cover that par

Re: [389-users] WinSync agreement deletes directoryt server users

[Noriko Hosoi]

On 10/19/2015 09:23 AM, Mizrahi, Yair wrote:
i'll do some comparison tomorrow between affected and unaffected user, 
hopefully I will find something

Thanks a lot!!




Sent from my Samsung device


 Original message 
From: Noriko Hosoi 
Date: 19/10/2015 19:04 (GMT+02:00)
To: 389-users@lists.fedoraproject.org
Subject: Re: [389-users] WinSync agreement deletes directoryt server 
users


Thank you for the update.

Regarding this symptom:
> they are also gets deleted from directory server (around 200 users 
from 550).
I'm curious what's the difference between the deleted 200 users and 
the rest.


Thanks,
--noriko

On 10/19/2015 12:35 AM, Mizrahi, Yair wrote:


Hi Noriko,

This is the version I have installed:
389-ds-base-1.2.11.15-60.el6.x86_64 on CentOS 6.5

I was able to work around the problem by backing up the group and 
people OU to LDIF files , do the sync (which deleted the affected 
accounts)and after that importing them back, this caused the LDAP 
server to sync them to AD.


BTW I noticed the initial sync is deleting the same accounts.

Thanks,

*From:*389-users-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@lists.fedoraproject.org] *On Behalf Of 
*Noriko Hosoi

*Sent:* Monday, October 19, 2015 12:23 AM
*To:* 389-users@lists.fedoraproject.org
*Subject:* Re: [389-users] WinSync agreement deletes directoryt 
server users


On 10/18/2015 02:06 AM, Mizrahi, Yair wrote:

Hi,

I have setup a sync agreement between directory server and active
directory 2012R2 and I’m getting a very strange behavior, if I am
doing 2 way sync (the default) the sync completes successfully
but not all the users are created in AD, not only that , they are
also gets deleted from directory server (around 200 users from 550).

I’m syncing to Blank OU in AD

My DS version is 1.2.2-1

 Is it the version of 389-ds-base (not 389-ds)?

rpm -q 389-ds-base

Thanks,

cid:image001.gif@01CE0DED.C3CB64A0XtremIO



*Yair Mizrahi*

Sr Lab IT engineer

Office: + 972 722563243

Mobile: + 972 54 2327687

Email: yair.mizr...@emc.com <mailto:yair.mizr...@emc.com>



**



*EMC² - XtremIO
*Glil Yam 46905,

Herzliya,

Israel
www.emc.com <http://www.emc.com/>




--
389 users mailing list
389-users@lists.fedoraproject.org 
<mailto:389-users@lists.fedoraproject.org>

https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] WinSync agreement deletes directoryt server users

[Noriko Hosoi]

Thank you for the update.

Regarding this symptom:
> they are also gets deleted from directory server (around 200 users 
from 550).
I'm curious what's the difference between the deleted 200 users and the 
rest.


Thanks,
--noriko

On 10/19/2015 12:35 AM, Mizrahi, Yair wrote:


Hi Noriko,

This is the version I have installed:
389-ds-base-1.2.11.15-60.el6.x86_64 on CentOS 6.5

I was able to work around the problem by backing up the group and 
people OU to LDIF files , do the sync (which deleted the affected 
accounts)and after that importing them back, this caused the LDAP 
server to sync them to AD.


BTW I noticed the initial sync is deleting the same accounts.

Thanks,

*From:*389-users-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@lists.fedoraproject.org] *On Behalf Of 
*Noriko Hosoi

*Sent:* Monday, October 19, 2015 12:23 AM
*To:* 389-users@lists.fedoraproject.org
*Subject:* Re: [389-users] WinSync agreement deletes directoryt server 
users


On 10/18/2015 02:06 AM, Mizrahi, Yair wrote:

Hi,

I have setup a sync agreement between directory server and active
directory 2012R2 and I’m getting a very strange behavior, if I am
doing 2 way sync (the default) the sync completes successfully but
not all the users are created in AD, not only that , they are also
gets deleted from directory server (around 200 users from 550).

I’m syncing to Blank OU in AD

My DS version is 1.2.2-1

 Is it the version of 389-ds-base (not 389-ds)?

rpm -q 389-ds-base

Thanks,

cid:image001.gif@01CE0DED.C3CB64A0XtremIO



*Yair Mizrahi*

Sr Lab IT engineer

Office: + 972 722563243

Mobile: + 972 54 2327687

Email: yair.mizr...@emc.com <mailto:yair.mizr...@emc.com>



**



*EMC² - XtremIO
*Glil Yam 46905,

Herzliya,

Israel
www.emc.com <http://www.emc.com/>




--
389 users mailing list
389-users@lists.fedoraproject.org 
<mailto:389-users@lists.fedoraproject.org>

https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] WinSync agreement deletes directoryt server users

[Noriko Hosoi]

On 10/18/2015 02:06 AM, Mizrahi, Yair wrote:


Hi,

I have setup a sync agreement between directory server and active 
directory 2012R2 and I’m getting a very strange behavior, if I am 
doing 2 way sync (the default) the sync completes successfully but not 
all the users are created in AD, not only that , they are also gets 
deleted from directory server (around 200 users from 550).


I’m syncing to Blank OU in AD

My DS version is 1.2.2-1


 Is it the version of 389-ds-base (not 389-ds)?

rpm -q 389-ds-base


Thanks,

cid:image001.gif@01CE0DED.C3CB64A0XtremIO



*Yair Mizrahi***

Sr Lab IT engineer

Office: + 972 722563243

Mobile: + 972 54 2327687

Email: yair.mizr...@emc.com 



**



*EMC² - XtremIO
*Glil Yam 46905,

Herzliya,

Israel
www.emc.com 



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] seeing errors in MM Rep fractional replication

[Noriko Hosoi]

On 10/16/2015 02:55 PM, ghiureai wrote:
Thank you  for pointing the ticket bug to me , is this suppose to be 
fixed in my version:

rpm -qa 389-ds-base
389-ds-base-1.2.11.15-34.el6_5.x86_64

Unfortunately, the fix is not released yet.

or there is a patch or work around ?
The workaround is "to apply periodic dummy updates" which are to be 
replicated to the replicas.  It would be ideal to do the dummy updates 
every 10 fractional updates or so.  If it is hard, it could be once in 
an hour.


Hope it helps...


we had multimaste replication cfg with this system and was fine but  
had to switch to fractional rep to exclude "memeberOf" plugin from and 
this when I start seeing this error.

Thank you !



On 10/16/2015 02:02 PM, ghiureai wrote:


Hi list,
we completed the MMRep Fractional rep excluded  (memberOf pluging) and
on supplier seeing this error:

repl5_inc_wait for_async_results timed out waiting for responses: 15 17
and consumer seeing this :
slapi_ldap_bind - Error: timeout after [0.0] seconds reading bind
response for [uid=rep_user,cn=config] mech [SIMPLE]
[16/Oct/2015:13:46:35 -0700] NSMMReplicationPlugin - agmt="cn=2 to 01"
1:389): Replication bind with SIMPLE auth failed: LDAP error -5 (Timed
out) ((null))
[16/Oct/2015:13:46:59 -0700] slapi_ldap_bind - Error: timeout after
[0.0] seconds reading bind response for [uid=rep_user,cn=config] mech
[SIMPLE]
[16/Oct/2015:13:47:19 -0700] slapi_ldap_bind - Error: timeout after
[0.0] seconds reading bind response for [uid=rep_user,cn=config] mech
[SIMPLE]
[16/Oct/2015:13:47:39 -0700] slapi_ldap_bind - Error: timeout after
[0.0] seconds reading bind response for [uid=rep_user,cn=config] mech
[SIMPLE]
[16/Oct/2015:13:47:59 -0700] slapi_ldap_bind - Error: timeout after
[0.0] seconds reading bind response for [uid=rep_user,cn=config] mech
[SIMPLE]
[16/Oct/2015:13:48:29 -0700] slapi_ldap_bind - Error: timeout after
[0.0] seconds reading bind response for [uid=rep_user,cn=config] mech
[SIMPLE]
[16/Oct/2015:13:50:05 -0700] slapi_ldap_bind - Error: timeout after
[0.0] seconds reading bind response for [uid=rep_user,cn=config] mech
[SIMPLE]


any help much appreciate it
Thank you
Isabella


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] seeing errors in MM Rep fractional replication

[Noriko Hosoi]

On 10/16/2015 02:02 PM, ghiureai wrote:



Hi list,
we completed the MMRep Fractional rep excluded  (memberOf pluging) and 
on supplier seeing this error:


repl5_inc_wait for_async_results timed out waiting for responses: 15 17
and consumer seeing this :
slapi_ldap_bind - Error: timeout after [0.0] seconds reading bind 
response for [uid=rep_user,cn=config] mech [SIMPLE]
[16/Oct/2015:13:46:35 -0700] NSMMReplicationPlugin - agmt="cn=2 to 01" 
1:389): Replication bind with SIMPLE auth failed: LDAP error -5 (Timed 
out) ((null))
[16/Oct/2015:13:46:59 -0700] slapi_ldap_bind - Error: timeout after 
[0.0] seconds reading bind response for [uid=rep_user,cn=config] mech 
[SIMPLE]
[16/Oct/2015:13:47:19 -0700] slapi_ldap_bind - Error: timeout after 
[0.0] seconds reading bind response for [uid=rep_user,cn=config] mech 
[SIMPLE]
[16/Oct/2015:13:47:39 -0700] slapi_ldap_bind - Error: timeout after 
[0.0] seconds reading bind response for [uid=rep_user,cn=config] mech 
[SIMPLE]
[16/Oct/2015:13:47:59 -0700] slapi_ldap_bind - Error: timeout after 
[0.0] seconds reading bind response for [uid=rep_user,cn=config] mech 
[SIMPLE]
[16/Oct/2015:13:48:29 -0700] slapi_ldap_bind - Error: timeout after 
[0.0] seconds reading bind response for [uid=rep_user,cn=config] mech 
[SIMPLE]
[16/Oct/2015:13:50:05 -0700] slapi_ldap_bind - Error: timeout after 
[0.0] seconds reading bind response for [uid=rep_user,cn=config] mech 
[SIMPLE]



any help much appreciate it
Thank you
Isabella
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

You might have hit this bug?

Ticket #48266  - Fractional 
replication evaluates several times the same CSN


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Expired Passwords still work on replica some replica consumers, not on others

[Noriko Hosoi]

On 09/30/2015 12:08 PM, Ryan Langford wrote:

Hello,

I have a curious situation with our LDAP ecosystem at work.  I have 2 
LDAP hosts in one data center (one is a replication supplier, one is a 
consumer) and 1 consumer host in a separate data center(DC-B).



The issue is expired users can still successfully authenticate against 
the consumer host DC-B, even though LDAP shows that the password is 
expired.


I've compiled outputs from each host into the following paste:
https://paste.fedoraproject.org/273218/44362838/

We are using an old version of 389-ds (as you can see from the paste), 
version 1.2.9.9, and as far as I can tell (i'm a relative LDAP 
neophyte) our configuration and replication properties are as 
expected, but I'm not sure if there might be a permissions issue, some 
other issue, or a bug in the old version we're using.


What else should I check next?
[CrunkOps@dc01-server01 ~]$ ldapsearch -x -D"cn=directory manager" -W -b 
"cn=config" -s base nsslapd-pwpolicy-local
[CrunkOps@dc02-server01 ~]$ ldapsearch -x -D"cn=directory manager" -W -b 
"cn=config" -s base nsslapd-pwpolicy-local


[CrunkOps@dc02-server01 ~]$ date
(sorry, this is just to laugh...)

Thanks,
--noriko

Thanks,

Ryan


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Performance with macro acis

[Noriko Hosoi]

On 09/17/2015 10:39 AM, Rich Megginson wrote:

On 09/17/2015 11:33 AM, Noriko Hosoi wrote:

Hello,

There is a known issue in the macro aci performance which is fixed in 
the upstream.  The fix will be included in the next rhel releases 
(6.8 and 7.2).



https://fedorahosted.org/389/ticket/48141

And https://fedorahosted.org/389/ticket/48175



Thanks,
--noriko

On 09/17/2015 09:59 AM, Adrian Damian wrote:

389-ds-base-1.2.11.15-34.el6_5.x86_64

On 09/17/2015 09:56 AM, Rich Megginson wrote:

On 09/17/2015 10:52 AM, Adrian Damian wrote:

Hi Rich,

Sorry for missing this info. It's 1.2.11 running on SL6.
We need the exact version, which is why I asked for the output of 
rpm -q

389-ds-base


Adrian

On 09/17/2015 08:54 AM, Rich Megginson wrote:

On 09/16/2015 03:11 PM, Adrian Damian wrote:

Hi There,

The scenario is simple: we have a subtree in the DIT with a few
thousand
children node. The parent node of the subtree has a few acis
including a
couple of macro acis that apply to each of the child nodes. We've
observed a significant performance degradation when trying to 
list all

the children in the presence of the macro acis.

Profiling on the client code show that although the first few child
nodes were fetched quite fast there is a clear delay buildup as the
retrieval progresses. The buildup is not present when the macro 
acis

are
removed. Also, it is faster to split the list in chunks and 
retrieve

them sequentially.

Is it possible that as the macro acis are resolved they are 
added to

the
list of acis of the parent node so that the last nodes are 
evaluated
against many more acis than the first ones and hence the 
observed delay

in their retrieval? Is there a workaround for this?

What version of 389?  rpm -q 389-ds-base


Thank you,
Adrian

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Performance with macro acis

[Noriko Hosoi]

Hello,

There is a known issue in the macro aci performance which is fixed in 
the upstream.  The fix will be included in the next rhel releases (6.8 
and 7.2).


Thanks,
--noriko

On 09/17/2015 09:59 AM, Adrian Damian wrote:

389-ds-base-1.2.11.15-34.el6_5.x86_64

On 09/17/2015 09:56 AM, Rich Megginson wrote:

On 09/17/2015 10:52 AM, Adrian Damian wrote:

Hi Rich,

Sorry for missing this info. It's 1.2.11 running on SL6.

We need the exact version, which is why I asked for the output of rpm -q
389-ds-base


Adrian

On 09/17/2015 08:54 AM, Rich Megginson wrote:

On 09/16/2015 03:11 PM, Adrian Damian wrote:

Hi There,

The scenario is simple: we have a subtree in the DIT with a few
thousand
children node. The parent node of the subtree has a few acis
including a
couple of macro acis that apply to each of the child nodes. We've
observed a significant performance degradation when trying to list 
all

the children in the presence of the macro acis.

Profiling on the client code show that although the first few child
nodes were fetched quite fast there is a clear delay buildup as the
retrieval progresses. The buildup is not present when the macro acis
are
removed. Also, it is faster to split the list in chunks and retrieve
them sequentially.

Is it possible that as the macro acis are resolved they are added to
the
list of acis of the parent node so that the last nodes are evaluated
against many more acis than the first ones and hence the observed 
delay

in their retrieval? Is there a workaround for this?

What version of 389?  rpm -q 389-ds-base


Thank you,
Adrian

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Announcing 389 Windows Console 1.1.15

[Noriko Hosoi]

   389 Windows Console 1.1.15

The 389 Directory Server team is proud to announce 389-console-win 
version 1.1.15.


Windows installers are available to download from Download 389 Windows 
Console (32-bit) 
 and 
Download 389 Windows Console (64-bit) 
.



 Highlights in 389-console-win-1.1.15

 * Windows Console now has the same bug fixes and enhancements made for
   the Fedora 389-console.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install and update, use Programs and Features on Control Panel.


 Feedback

We are very interested in your feedback!

If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelogs

Please refer 389-console-1.1.19, 389-admin-console-1.1.10 release notes 
 and 
389-ds-console-1.2.12 and idm-console-framework-1.1.14 release notes 
.


http://www.port389.org/docs/389ds/releases/release-windows-console-1-1-15.html

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Announcing 389 Directory Server version 1.3.3.13

[Noriko Hosoi]

   389 Directory Server 1.3.3.13

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.3.13.


Fedora packages are available from the Fedora 21 repositories.

The new packages and versions are:

 * 389-ds-base-1.3.3.13-1

A source tarball is available for download at Download Source 




 Highlights in 1.3.3.13

 * Various bugs are fixed.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users as well as 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.3.13-1.fc21 
.


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.3.12

 * Ticket 48265 - Complex filter in a search request doen’t work as
   expected. (regression)
 * Ticket 47981 - COS cache doesn’t properly mark vattr cache as
   invalid when there are multiple suffixes
 * Ticket 48252 - db2index creates index entry from deleted records
 * Ticket 48228 - wrong password check if passwordInHistory is decreased.
 * Ticket 48252 - db2index creates index entry from deleted records
 * Ticket 48254 - CLI db2index fails with usage errors
 * Ticket 47831 - remove debug logging from retro cl
 * Ticket 48245 - Man pages and help for remove-ds.pl doesn’t display
   “-a” option
 * Ticket 47931 - Fix coverity issues
 * Ticket 47931 - memberOf & retrocl deadlocks
 * Ticket 48228 - wrong password check if passwordInHistory is decreased.
 * Ticket 48215 - update dbverify usage in main.c
 * Ticket 48215 - update dbverify usage
 * Ticket 48215 - verify_db.pl doesn’t verify DB specified by -a option
 * Ticket 47810 - memberOf plugin not properly rejecting updates
 * Ticket 48231 - logconv autobind handling regression caused by 47446
 * Ticket 48232 - winsync lastlogon attribute not syncing between DS
   and AD.
 * Ticket 48206 - Crash during retro changelog trimming
 * Ticket 48224 - redux 2 - logconv.pl should handle *.tar.xz, *.txz,
   *.xz log files
 * Ticket 48226 - In MMR, double free coould occur under some
   special condition
 * Ticket 48224 - redux - logconv.pl should handle *.tar.xz, *.txz,
   *.xz log files
 * Ticket 48224 - redux - logconv.pl should handle *.tar.xz, *.txz,
   *.xz log files
 * Ticket 48224 - logconv.pl should handle *.tar.xz, *.txz, *.xz log files
 * Ticket 48192 - Individual abandoned simple paged results request has
   no chance to be cleaned up
 * Ticket 48212 - Dynamic nsMatchingRule changes had no effect on the
   attrinfo thus following reindexing, as well.
 * Ticket 48195 - Slow replication when deleting large quantities of
   multi-valued attributes
 * Ticket 48175 - Avoid using regex in ACL if possible

http://www.port389.org/docs/389ds/releases/release-1-3-3-13.html

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Announcing 389 Directory Server version 1.3.4.4

[Noriko Hosoi]

   389 Directory Server 1.3.4.4

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.4.4.


Fedora packages are available from the Fedora 22, 23 and 
Rawhide repositories.


The new packages and versions are:

 * 389-ds-base-1.3.4.4-1

Source tarballs are available for download at Download 389-ds-base 
Source  and 
Download nunc-stans Source 
.



 Highlights in 1.3.4.4

 * Various bugs are fixed.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users as well as 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.4-1.fc22 
 and 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.4-1.fc23 
.


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.4.1

 * Ticket 48255 - total update request can be lost
 * Ticket 48263 - allow plugins to detect tombstone operations
 * Ticket 48265 - Complex filter in a search request doen’t work as
   expected. (regression)
 * Ticket 47981 - COS cache doesn’t properly mark vattr cache as
   invalid when there are multiple suffixes
 * Ticket 48204 - Convert all python scripts to support python3
 * Ticket 48258 - dna plugin needs to handle binddn groups
   for authorization
 * Ticket 48252 - db2index creates index entry from deleted records
 * Ticket 48228 - wrong password check if passwordInHistory is decreased.
 * Ticket 48252 - db2index creates index entry from deleted records
 * Ticket 47757 - Unable to dereference unqiemember attribute because
   it is dn [#UID] not dn syntax
 * Ticket 48254 - Shell CLI fails with usage errors if an argument
   containing white spaces is given
 * Ticket 48254 - CLI db2index fails with usage errors
 * Ticket 47831 - remove debug logging from retro cl
 * Ticket 48243 - replica upgrade failed in starting dirsrv service due
   to upgrade scripts did not run
 * Ticket 48233 - Server crashes in ACL_LasFindFlush during shutdown if
   ACIs contain IP addresss restrictions
 * Ticket 48250 - Slapd crashes reported from latest build
 * Ticket 48249 - sync_repl uuid may be invalid
 * Ticket 48245 - Man pages and help for remove-ds.pl doesn’t display
   “-a” option
 * Ticket 47511 - bashisms in 389-ds-base admin scripts
 * Ticket 47686 - removing chaining database links trigger valgrind
   read errors
 * Ticket 47931 - memberOf & retrocl deadlocks
 * Ticket 48228 - wrong password check if passwordInHistory is decreased.
 * Ticket 48215 - update dbverify usage in main.c
 * Ticket 48215 - verify_db.pl doesn’t verify DB specified by -a option
 * Ticket 47810 - memberOf plugin not properly rejecting updates
 * Ticket 48231 - logconv autobind handling regression caused by 47446
 * Ticket 48232 - winsync lastlogon attribute not syncing between DS
   and AD.
 * Ticket 48204 - Add Python 3 compatibility to ds-logpipe
 * Ticket 48010 - winsync range retrieval gets only 5000 values
   upon initialization
 * Ticket 48206 - Crash during retro changelog trimming
 * Ticket 48224 - redux 2 - logconv.pl should handle *.tar.xz, *.txz,
   *.xz log files
 * Ticket 47910 - logconv.pl - check that the end time is greater than
   the start time
 * Ticket 48179 - Starting a replica agreement can lead to deadlock
 * Ticket 48226 - CI test: added test cases for ticket 48226
 * Ticket 48226 - In MMR, double free coould occur under some
   special condition
 * Ticket 48224 - redux - logconv.pl should handle *.tar.xz, *.txz,
   *.xz log files
 * Ticket 48203 - Fix coverity issues - 07/14/2015
 * Ticket 48194 - CI test: fixing test cases for ticket 48194
 * Ticket 48224 - logconv.pl should handle *.tar.xz, *.txz, *.xz log files
 * Ticket 47910 - logconv.pl - validate start and end time args
 * Ticket 48223 - Winsync fails when AD users have multiple spaces
   (two)inside the value of the 

Re: [389-users] 389-DS poor performance retrieving groups

[Noriko Hosoi]

On 08/05/2015 06:41 AM, Mark Reynolds wrote:



On 08/05/2015 08:24 AM, Mark Reynolds wrote:



On 08/04/2015 11:57 AM, ghiureai wrote:
 

We are seeing poor performance from LDAP retrieving 2500-4500 
entries compare with one of our regular RDBMS , here is bellow the 
result for a ldapsearch.
We are questioning if for general cn=(.*..) search string , LDAP has 
to run  a round trip for each  subset result entry ?


What cfg needs tuned to  see some performance improvements beside  
cache mem size ?


ldapsearch -x -s one -H  -b 'ou=Groups,ou=ds,dc=cxxx,dc=net' -W -D 
'uid=xx,ou=Users,ou=ds,dc=cxxxr,dc=net' 'cn=*MT*' 'cn, nsaccountlock'
Okay so this is probably unindexed, and the requested access log 
snipet will confirm this. If you see notes=U or notes=A then we can 
tune the id scan limit for that search:



Assuming this is the only search that is giving you issues:

Example:


# ldapmodify 
|dn: cn=cn,cn=index,cn=userroot,cn=ldbm database,cn=plugins,cn=config
changetype: modify
add:|||nsIndexIDListScanLimit|
nsIndexIDListScanLimit: limit=-1 type=sub values=*mt,mt*



If there are other substring searches around the "cn" attribute you are having 
issues with, you can modify this to be:

|# ldapmodify 

|dn: cn=cn,cn=index,cn=userroot,cn=ldbm database,cn=plugins,cn=config
changetype: modify
add:|||nsIndexIDListScanLimit|
nsIndexIDListScanLimit: limit=-1 type=sub|
I'm on a roll today :-( sorry so this is not going to solve the 
issue.  There is no way to index or improve this type of search 
filter's performance (cn=*mt*).  If this is a reoccurring search 
filter, and your client can be adjusted to use vlv indexes, then that 
might be option.  See the admin guide for more info on VLV 
searches/indexes.
Did you have a chance to try these substring index config params -- in 
this case, "nsSubStrMiddle: 2?  Please note that after setting the 
parameter, you need to reindex "cn".

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/Database_Plug_in_Attributes.html#nssubstrbegin

Thanks,
--noriko


Regards,
Mark



Regards,

Mark

 


# search result
search: 2
result: 0 Success

# numResponses: 2608
# numEntries: 2607

real0m19.284s
user0m0.040s
sys0m0.052s


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] access log error : Resource temporarily unavailable

[Noriko Hosoi]

Are you having any difficulties in using the Directory Server?

The error code 11 is:
#defineEAGAIN11/* Try again */

T1 means SLAPD_DISCONNECT_IDLE_TIMEOUT.

Could you find the value of this configuration parameter: 
nsslapd-idletimeout?


The connection (e.g., conn=143371) passed the idletimeout and was closed?

On 07/31/2015 09:42 AM, ghiureai wrote:


Hi lIst.
we are getting the following in access  files, would like to  know 
wher eto look for clues , what means "Resource temporarily unavailable ?



op=1 RESULT err=0 tag=101 nentries=5514 etime=14 notes=U
[31/Jul/2015:09:37:21 -0700] conn=143371 op=-1 fd=67 closed error 11 
(Resource temporarily unavailable) - T1
[31/Jul/2015:09:37:21 -0700] conn=143369 op=-1 fd=65 closed error 11 
(Resource temporarily unavailable) - T1


op=-1 fd=67 closed error 11 (Resource temporarily unavailable) - T1
[31/Jul/2015:09:37:21 -0700] conn=143369 op=-1 fd=65 closed error 11 
(Resource temporarily unavailable) - T1


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] DNA Plugin Causes 389-DS to Crash if Large Number of Candidates

[Noriko Hosoi]

Unfortunately, your version 1.2.11.29-1.el6 is no longer supported.

Please take a look at this page and install the latest official version 
or its equivalent one.

http://www.port389.org/docs/389ds/releases/end-1-2-11.html

The expected version should look like 1.2.11.15-##.el6.

On 07/16/2015 04:50 PM, Fong, Trevor wrote:
BTW, we were able to artificially make it work by changing the 
dnaFilter to the emplid of our test user:

dnaFilter: (&(employeeNumber=12345)(objectclass=posixAccount))

Trev

From: Trevor Fong mailto:trevor.f...@ubc.ca>>
Date: Thursday, July 16, 2015 at 4:47 PM
To: "389-users@lists.fedoraproject.org 
" 
<389-users@lists.fedoraproject.org 
>

Subject: DNA Plugin Causes 389-DS to Crash if Large Number of Candidates

Hi Guys,


We’re running 389-ds 1.2.11.29-1.el6 and are experimenting with
the DNA plugin.  When trying to set an existing account’s
 uidNumber to the magic regen number of 9, we get the error
message in the errors log:


Allocation of a new value for range cn=uid numbers,cn=distributed
numeric assignment plugin,cn=plugins,cn=config failed! Unable to
proceed.

And then DS becomes unresponsive.


Looking at the debug error logs, it seems that the number of
candidates defined by the combination of dnaScope and dnaFilter is
too large (1389387 ids) for the sort function?  Is there a fix? 
Or is there some error in our setup?



Thanks,

Trev



Our setup is thus:


dn: cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config

objectClass: extensibleObject

objectClass: nsContainer

objectClass: nsSlapdPlugin

objectClass: top

cn: Distributed Numeric Assignment Plugin

nsslapd-pluginDescription: Distributed Numeric Assignment plugin

nsslapd-pluginEnabled: on

nsslapd-pluginId: Distributed Numeric Assignment

nsslapd-pluginInitfunc: dna_init

nsslapd-pluginPath: libdna-plugin

nsslapd-pluginType: bepreoperation

nsslapd-pluginVendor: 389 Project

nsslapd-pluginVersion: 1.2.11.29

nsslapd-plugin-depends-on-type: database



dn: cn=UID numbers,cn=Distributed Numeric Assignment
Plugin,cn=plugins,cn=co

 nfig

objectClass: extensibleObject

objectClass: top

cn: UID numbers

dnaFilter: (&(employeeNumber=*)(objectclass=posixAccount))

dnaMagicRegen: 9

dnaNextValue: 1002

dnaScope: ou=PEOPLE,ou=IDM,dc=dev,dc=example,dc=com

dnaType: uidNumber



Error log:

[16/Jul/2015:15:31:05 -0700] - add_pb

[16/Jul/2015:15:31:05 -0700] - =>
slapi_reslimit_get_integer_limit() conn=0x2907e68, handle=8

[16/Jul/2015:15:31:05 -0700] - <=
slapi_reslimit_get_integer_limit() returning NO VALUE

[16/Jul/2015:15:31:05 -0700] - =>
slapi_reslimit_get_integer_limit() conn=0x2907d30, handle=8

[16/Jul/2015:15:31:05 -0700] - <=
slapi_reslimit_get_integer_limit() returning NO VALUE

[16/Jul/2015:15:31:05 -0700] - --> pagedresults_is_timedout

[16/Jul/2015:15:31:05 -0700] - <-- pagedresults_is_timedout: -

[16/Jul/2015:15:31:05 -0700] - --> pagedresults_is_timedout

[16/Jul/2015:15:31:05 -0700] - <-- pagedresults_is_timedout: -

[16/Jul/2015:15:31:05 -0700] - get_pb

[16/Jul/2015:15:31:05 -0700] - --> pagedresults_in_use

[16/Jul/2015:15:31:05 -0700] - <-- pagedresults_in_use: 0

[16/Jul/2015:15:31:05 -0700] - do_modify

[16/Jul/2015:15:31:05 -0700] - do_modify: dn
(uid=myacct,ou=PEOPLE,ou=IDM,dc=dev,dc=example,dc=com)

[16/Jul/2015:15:31:05 -0700] - => get_ldapmessage_controls

[16/Jul/2015:15:31:05 -0700] - <= get_ldapmessage_controls no controls

[16/Jul/2015:15:31:05 -0700] - modifications:

[16/Jul/2015:15:31:05 -0700] -

replace: uidNumber

[16/Jul/2015:15:31:05 -0700] - => slapi_control_present (looking
for 2.16.840.1.113730.3.4.12)

[16/Jul/2015:15:31:05 -0700] - <= slapi_control_present 0 (NO
CONTROLS)

[16/Jul/2015:15:31:05 -0700] - => slapi_control_present (looking
for 2.16.840.1.113730.3.4.18)

[16/Jul/2015:15:31:05 -0700] - <= slapi_control_present 0 (NO
CONTROLS)

[16/Jul/2015:15:31:05 -0700] - mapping tree selected backend :
userRoot

[16/Jul/2015:15:31:05 -0700] - => slapi_control_present (looking
for 2.16.840.1.113730.3.4.12)

[16/Jul/2015:15:31:05 -0700] - <= slapi_control_present 0 (NO
CONTROLS)

[16/Jul/2015:15:31:05 -0700] - => slapi_control_present (looking
for 2.16.840.1.113730.3.4.18)

[16/Jul/2015:15:31:05 -0700] - <= slapi_control_present 0 (NO
CONTROLS)

[16/Jul/2015:15:31:05 -0700] - mapping tree selected backend :
userRoot

[16/Jul/2015:15:31:05 -0700] - =>
slapi_reslimit_get_integer_limit() conn=0x0, handle=6

[16/Jul/2015:15:31:05 -0700] - <=
slapi_reslimit_get_integer_limit() returning NO VALUE

[16/Jul/2015:15:31:05 

Re: [389-users] winsyncsubtreepair

[Noriko Hosoi]

I guess you configured WinSync with this "multiple subtrees"?

   http://www.port389.org/docs/389ds/design/winsync-rfe.html

Can we see the configuration?

Also, could it be possible to enable the replication log and repeat the 
incremental updates?


On 07/07/2015 09:21 AM, Rich Megginson wrote:

On 07/07/2015 10:07 AM, Mark Boyce wrote:


Good Morning,

Has anyone else seen this behavior; after configuring Winsync I add 
one or perhaps two “pairs” to the sync agreement (ds:AD)




Firstly - what version of 389-ds-base?  rpm -q 389-ds-base
What version of Windows/AD?  2012 R2?

I don't know what you mean by 'two "pairs"'.

and run a full sync successfully.  Upon subsequent attempt to add 
another pair the dirsrv abends (nothing in the logs)




What commands are you running?  How do you know the dirsrv abends?  
That is, if there is nothing in the logs, what commands are you 
running to see the failure?


and the modify operation fails (either via CLI or GUI).  This is 
critical to our org as the AD structure doesn’t lend it’s self to a 
single “in-scope” OU…




Also not sure what you mean by "single in-scope OU".


Thanks,

m.

*Mark L. Boyce*

Senior Identity Management Analyst

University of California, Office of the President

415 20^th Street

Oakland, CA 94612

Office: 510.987.9681

Cell: 209.851.0196



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] changelog configuration in MMR environment

[Noriko Hosoi]

On 07/01/2015 04:55 PM, William wrote:

Do the settings under cn=changelog5,cn=config (such as nsslapd
-changelogmaxage) have an effect on newer MMR environments?

Yes, they do.

Glad to know that.


The
documentation seems to indicate that the values under cn=changelog5
are
only related to the older replication mechanisms.

Which documentation are you reffering?

https://access.redhat.com/documentation/en
-US/Red_Hat_Directory_Server/8.0/html/Configuration_and_Command_Referen
ce/Configuration_Command_File_Reference
-Retro_Changelog_Plug_in_Attributes
-nsslapd_changelogmaxage_Max_Changelog_Age.html

Thank you, William!

Are you running RHDS8?  It is quite old...  I'd recommend the latest 
version which is RHDS 10.

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/index.html


Because it's under the retro_changelog_plugin section, and the
discussions of retro changelog is described as:

"T he Retro Changelog plug-in configures Directory Server to maintain a
changelog that is compatible with
the changelog implemented in Directory Server 4.0, 4.1, and 4.1x.
Maintaining a retro changelog is
essential to maintain a changelog for directory clients that depend on
a Directory Server 4.x-style
changelog."

In the administration guide.
Retro changelog is a separate plug-in.  Despite of the name "retro", it 
is still useful to store the change logs in the database independent 
from new/old replications.


   dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
   objectClass: top
   objectClass: nsSlapdPlugin
   objectClass: extensibleObject
   cn: Retro Changelog Plugin
   nsslapd-pluginPath: libretrocl-plugin
   nsslapd-pluginInitfunc: retrocl_plugin_init
   nsslapd-pluginType: object
   nsslapd-pluginbetxn: on
   nsslapd-pluginEnabled: off
   nsslapd-pluginprecedence: 25
   nsslapd-plugin-depends-on-type: database
   nsslapd-plugin-depends-on-named: Class of Service

cn=changelog5,cn=config is the changelog being used in MMR -- 
cn=Multimaster Replication Plugin,cn=plugins,cn=config.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] changelog configuration in MMR environment

[Noriko Hosoi]

Hi William,

On 07/01/2015 04:38 PM, William wrote:

Hi,

Do the settings under cn=changelog5,cn=config (such as nsslapd
-changelogmaxage) have an effect on newer MMR environments?

Yes, they do.

The
documentation seems to indicate that the values under cn=changelog5 are
only related to the older replication mechanisms.

Which documentation are you reffering?
Thanks,
--noriko


If this is the case, where are the changelog configurations for MMR?



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Paged searches return several pages without any content

[Noriko Hosoi]

On 06/25/2015 08:51 AM, Marcio Costa wrote:


Hello everybody. In our company we have an environment with four 
directory servers (389-ds-base version 1.2.11.15) with multi-master 
replication and every master replicates to other six directory servers 
(389-ds-base version 1.2.11.15) slaves. 

Could you run "rpm -q" and share the output with us?
Our servers have a suffix and several sub-suffixes so that we have a 
root base for the root suffix and several bases and each sub-suffixes 
has its base. We are used Owncloud as cloud storage solution that 
authenticates and searches in the master servers. Certain operations 
for the Ownclould performs paged searches in directory servers. It 
turns out that when we point the Owncloud to the root suffix paged 
searches return several pages without any content and others with 
content. If we point to one of our sub-suffixes the paged search 
return correctly. The nsslapd-pagedsizelimit attributes, 
nsslapd-pagedlookthroughlimit and nsslapd-pagedidlistscanlimit are not 
configured for any base. The configuration of these attributes can 
solve the problem of empty pages in paged searches? If not, is there 
any other configuration that can be done to correct paged searches 
with empty content?


Thanks a lot
--
*Marcio Costa*
DIOPE/SUPOP/OPSPO/OPSIN/*OPSOI*
Rede de Suporte Técnico em Diretório
*Serpro*  - Serviço Federal de Processamento de Dados
☎ (*11*) 2173-*1850*
*
*"Homo homini lupus"*
***


-


"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), 
empresa pública federal regida pelo disposto na Lei Federal nº 5.615, 
é enviada exclusivamente a seu destinatário e pode conter informações 
confidenciais, protegidas por sigilo profissional. Sua utilização 
desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a 
recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, 
esclarecendo o equívoco."


"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) 
-- a government company established under Brazilian law (5.615/70) -- 
is directed exclusively to its addressee and may contain confidential 
data, protected under professional secrecy rules. Its unauthorized use 
is illegal and may subject the transgressor to the law's penalties. If 
you're not the addressee, please send it back, elucidating the failure."



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Announcing 389 Directory Server version 1.3.4.1

[Noriko Hosoi]

   389 Directory Server 1.3.4.1

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.4.1.


Fedora packages are available from the Fedora 22 and Rawhide repositories.

The new packages and versions are:

 * 389-ds-base-1.3.4.1-1

Source tarballs are available for download at Download 389-ds-base 
Source  and 
Download nunc-stans Source 
.



 Highlights in 1.3.4.1

 * Bugs reported by Coverity are fixed.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users as well as 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.1-1.fc22 
.


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.4.0

 * Enable nunc-stans only for x86_64.
 * Ticket 48203 - Fix coverity issues - 06/22/2015
 * Bug 1234277 - distro-wide architecture set overriden by buildsystem;
   Upgrade nunc-stans to 0.1.5.

http://www.port389.org/docs/389ds/releases/release-1-3-4-1.html


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Announcing 389 Directory Server version 1.3.4.0

[Noriko Hosoi]

   389 Directory Server 1.3.4.0

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.4.0.


Fedora packages are available from the Fedora 22 and Rawhide repositories.

The new packages and versions are:

 * 389-ds-base-1.3.4.0-1

Source tarballs are available for download at Download 389-ds-base 
Source  and 
Download nunc-stans Source 
.



 Highlights in 1.3.4.0

 * A new version is available featuring Nunc Stans
   .


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users as well as 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.0-1.fc22 
.


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.3.12

 * Enable nunc-stans in the build.
 * Ticket 47490 - test case failing if 47721 is also fixed
 * Ticket 47640 - Linked attributes transaction not aborted when linked
   entry does not exit
 * Ticket 47669 - CI test: added test cases for ticket 47669
 * Ticket 47669 - Retro Changelog Plugin accepts invalid value in
   nsslapd-changelogmaxage attribute
 * Ticket 47723 - winsync sets AccountUserControl in AD to 544
 * Ticket 47787 - Make the test case more robust
 * Ticket 47833 - TEST CASE only (modrdn fails if renamed entry member
   of a group and is out of memberof scope)
 * Ticket 47878 - Improve setup-ds update logging
 * Ticket 47893 - should use Sys::Hostname instead Net::Domain
 * Ticket 47910 - allow logconv.pl -S/-E switches to work even when
   timestamps not present in access log
 * Ticket 47913 - remove-ds.pl should not remove /var/lib/dirsrv
 * Ticket 47921 - indirect cos does not reflect changes in the
   cos attribute
 * Ticket 47927 - Uniqueness plugin: should allow to exclude some
   subtrees from its scope
 * Ticket 47953 - testcase for removing invalid aci
 * Ticket 47966 - CI test: added test cases for ticket 47966
 * Ticket 47966 - slapd crashes during Dogtag clone reinstallation
 * Ticket 47972 - make parsing of nsslapd-changelogmaxage more
   fault tolerant
 * Ticket 47972 - make parsing of nsslapd-changelogmaxage more fool proof
 * Ticket 47998 - cleanup WINDOWS ifdef’s
 * Ticket 47998 - remove remaining obsolete OS code/files
 * Ticket 47998 - remove “windows” files
 * Ticket 47999 - address several race conditions in tests
 * Ticket 47999 - lib389 individual tests not running correctly when
   run as a whole
 * Ticket 48003 - build “suite” framework
 * Ticket 48008 - db2bak.pl man page should be improved.
 * Ticket 48017 - add script to generate lib389 CI test script
 * Ticket 48019 - Remove refs to constants.py and backup/restore from
   lib389 tests
 * Ticket 48023 - replace old replication check with lib389 function
 * Ticket 48025 - add an option ‘-u’ to dbgen.pl for adding group
   entries with uniquemembers
 * Ticket 48026 - fix invalid write for friendly attribute names
 * Ticket 48026 - Fix memory leak in uniqueness plugin
 * Ticket 48026 - Support for uniqueness plugin to enforce uniqueness
   on a set of attributes.
 * Ticket 48032 - change C code license to GPLv3; change C code license
   to allow openssl
 * Ticket 48035 - nunc-stans - Revise shutdown sequence
 * Ticket 48036 - ns_set_shutdown should call ns_job_done
 * Ticket 48037 - ns_thrpool_new should take a config struct rather
   than many parameters
 * Ticket 48038 - logging should be pluggable
 * Ticket 48039 - nunc-stans malloc should be pluggable
 * Ticket 48040 - preserve the FD when disabling a listener
 * Ticket 48043 - use nunc-stans config initializer
 * Ticket 48103 - update DS for new nunc-stans header file
 * Ticket 48110 - Free all the nunc-stans signal jobs when shutdown
   is detected
 * Ticket 48111 - “make clean” wipes out original files
 * Ticket 48122 - nunc-stans FD leak
 * Ticket 48127 - Using RPM, allows non root

Re: [389-users] _cl5CompactDBs: failed to compact

[Noriko Hosoi]

Hi Andrey,

On 06/18/2015 01:23 AM, Ivanov Andrey (M.) wrote:

Hi,

we are using the branch 1.3.2 on CentOS7 in our production environment 
(version 1.3.2.27 with some additional patches from the git of this 
branch).
There are three MMR replicating servers. It's one month of uptime and 
the servers wanted to trim the replication log. Here is what i've 
found in error log on each of them :


1st server:
[18/Jun/2015:08:04:31 +0200] - libdb: BDB2055 Lock table is out of 
available lock entries
May not matter, but could you please try increasing the value of this db 
config parameter?  The default value is 1.


   dn: cn=config,cn=ldbm database,cn=plugins,cn=config
   nsslapd-db-locks: 1

[18/Jun/2015:08:04:31 +0200] NSMMReplicationPlugin - changelog program 
- _cl5CompactDBs: failed to compact 
a45fa684-f28d11e4-af27aa63-5121b7ef; db error - 12 Cannot allocate memory
I don't thing there is any problem even if the DBs are not compacted.  
It was introduced just to release the free pages in the db files.  But 
I'd also like to learn why the compact fails with ENOMEM here.


Thanks,
--noriko


2nd server:
[18/Jun/2015:08:10:34 +0200] - libdb: BDB2055 Lock table is out of 
available lock entries
[18/Jun/2015:08:10:34 +0200] NSMMReplicationPlugin - changelog program 
- _cl5CompactDBs: failed to compact 
acb7e184-f28d11e4-9b13d240-c66923c8; db error - 12 Cannot allocate memory


3rd server:
[18/Jun/2015:08:18:10 +0200] - libdb: BDB2055 Lock table is out of 
available lock entries
[18/Jun/2015:08:18:10 +0200] NSMMReplicationPlugin - changelog program 
- _cl5CompactDBs: failed to compact 
acb7e184-f28d11e4-8067eff8-b1ca763b; db error - 12 Cannot allocate memory


The changelog itself is not huge :
[root@ldap-ens]# ll -h /Local/dirsrv/var/lib/dirsrv/slapd-ens/changelogdb/
total 390M
-rw--- 1 ldap ldap 390M Jun 18 10:18 
a45fa684-f28d11e4-af27aa63-5121b7ef_5547be41.db
-rw-r--r-- 1 ldap ldap0 May 19 08:02 
a45fa684-f28d11e4-af27aa63-5121b7ef.sema

-rw--- 1 ldap ldap   30 May  4 20:45 DBVERSION

The server are working correctky, the replication is also working

What are the potential consequences of this error? How can we avoid it?

Thank you!


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Announcing 389 Admin Server version 1.1.42

[Noriko Hosoi]

   389 Admin Server 1.1.42

The 389 Directory Server team is proud to announce 389-admin version 
1.1.42 and 389-adminutil version 1.1.22.


Fedora packages are available from the EPEL7, Fedora 21, Fedora 22 and 
Rawhide repositories.


The new packages and versions are:

 * 389-admin-1.1.42-1
 * 389-adminutil-1.1.22-1

Source tarballs are available for download at Download Admin Source 
 and Download 
Adminutil Source 
.



 Highlights in 389-admin-1.1.42 and 389-adminutil-1.1.22

 * Several bugs are fixed.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users and 
following pages:


 * https://admin.fedoraproject.org/updates/389-admin-1.1.42-1.el7
   
 * https://admin.fedoraproject.org/updates/389-admin-1.1.42-1.fc21
   
 * https://admin.fedoraproject.org/updates/389-admin-1.1.42-1.fc22
   
 * https://admin.fedoraproject.org/updates/389-adminutil-1.1.22-1.el7
   
 * https://admin.fedoraproject.org/updates/389-adminutil-1.1.22-1.fc20
   
 * https://admin.fedoraproject.org/updates/389-adminutil-1.1.22-1.fc21
   

If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 389-admin-1.1.38

 * Ticket 47548 - register-ds-admin - silent file incorrectly processed
 * Ticket 47493 - Configuration Tab does not work with FIPS mode enabled
 * Ticket 48186 - register-ds-admin.pl script prints clear text
   password in the terminal
 * Ticket 47548 - register-ds-admin.pl fails to set local bind DN
   and password
 * Ticket 47467 - Improve Add CRL/CKL dialog and errors
 * Ticket 48171 - remove-ds-admin.pl removes files in the rpm
 * Ticket 48153 - [adminserver] support NSS 3.18


 Detailed Changelog since 389-adminutil-1.1.21

 * Ticket 48152 - support NSS 3.18

http://www.port389.org/docs/389ds/releases/release-admin-1-1-42.html
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Announcing 389 Directory Server version 1.3.3.12

[Noriko Hosoi]

   389 Directory Server 1.3.3.12

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.3.12.


Fedora packages are available from the Fedora 21, 22 and 
Rawhide repositories.


The new packages and versions are:

 * 389-ds-base-1.3.3.12-1

A source tarball is available for download at Download Source 




 Highlights in 1.3.3.12

 * Several critical bugs including a security bug were fixed.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users as well as 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.3.12-1.fc21 
 
and https://admin.fedoraproject.org/updates/389-ds-base-1.3.3.12-1.fc22 
.


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.3.10

 * Bug 1232896 - CVE-2015-3230 389-ds-base: nsSSL3Ciphers preference
   not enforced server side (Ticket 48194)
 * Ticket 48192 - Individual abandoned simple paged results request has
   no chance to be cleaned up
 * Ticket 48190 - idm/ipa 389-ds-base entry cache converges to 500 KB
   in dblayer_is_cachesize_sane
 * Ticket 48183 - bind on db chained to AD returns err=32
 * Ticket 47753 - Fix testecase
 * Ticket 47828 - fix testcase “import” issue
 * Ticket 48158 - cleanAllRUV task limit not being enforced correctly
 * Ticket 48158 - Remove cleanAllRUV task limit of 4
 * Ticket 48146 - async simple paged results issue; need to close a
   small window for a pr index competed among multiple threads.
 * Ticket 48146 - async simple paged results issue; log pr index
 * Ticket 48146 - async simple paged results issue
 * Ticket 48109 - substring index with nssubstrbegin: 1 is not being
   used with filters like (attr=x*)
 * Ticket 48177 - dynamic plugins should not return an error when
   modifying a critical plugin
 * Ticket 48151 - fix coverity issues
 * Ticket 48151 - Improve CleanAllRUV logging
 * Ticket 48136 - v2v2 accept auxilliary objectclasse in
   replication agreements
 * Ticket 48132 - modrdn crashes server (invalid read/writes)
 * Ticket 48133 - Non tombstone entry which dn starting with
   “nsuniqueid=…,” cannot be deleted

http://www.port389.org/docs/389ds/releases/release-1-3-3-12.html
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Announcing 389 Ds Console version 1.2.12

[Noriko Hosoi]

   389 Ds Console 1.2.12

The 389 Directory Server team is proud to announce 389-ds-console 
version 1.2.12 and idm-console-framework version 1.1.14.


Fedora packages are available from the EPEL7, Fedora 21, Fedora 22 and 
Rawhide repositories.


The new packages and versions are:

 * 389-ds-console-1.2.12-1
 * idm-console-framework-1.1.14-1

Source tarballs are available for download at Download 389 Ds Console 
Source , 
Download Idm Console Framework Source 
.



 Highlights in 389-ds-console-1.2.12 and idm-console-framework-1.1.14-1

 * Several bugs are fixed.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users and 
following pages:


 * https://admin.fedoraproject.org/updates/389-ds-console-1.2.12-1.el7
   
 * https://admin.fedoraproject.org/updates/389-ds-console-1.2.12-1.fc21
   
 * https://admin.fedoraproject.org/updates/389-ds-console-1.2.12-1.fc22
   
 * https://admin.fedoraproject.org/updates/idm-console-framework-1.1.14-1.el7
   
 * https://admin.fedoraproject.org/updates/idm-console-framework-1.1.14-1.fc21
   
 * https://admin.fedoraproject.org/updates/idm-console-framework-1.1.14-2.fc22
   

If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 389-ds-console-1.2.10

 * Ticket 48139 - drop support for legacy replication
 * Ticket 48130 - Add “+all” and “-TLS_RSA_WITH_AES_128_GCM_SHA256” to
   Console Cipher Preference for TLS


 Detailed Changelog since idm-console-framework-1.1.9

 * Ticket 48187 - Adding an OU from console is throwing missing
   attribute aliasedObjectName error
 * Ticket 47946 - Fix regression with original patch
 * Ticket 47946 - Need to revise console aci syntax checking
 * Ticket 97 - 389-console should provide usage options, help, and
   man pages
 * Ticket 48134 - Directory Server Admin Console: plaintext password
   logged in debug mode
 * Ticket 48130 - Add “+all” and “-TLS_RSA_WITH_AES_128_GCM_SHA256” to
   Console Cipher Preference for TLS

http://www.port389.org/docs/389ds/releases/release-ds-console-1-2-12.html
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Announcing 389 Directory Server version 1.3.3.10

[Noriko Hosoi]

   389 Directory Server 1.3.3.10

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.3.10.


Fedora packages are available from the Fedora 21, 22 and 
Rawhide repositories.


The new packages and versions are:

 * 389-ds-base-1.3.3.10-1

A source tarball is available for download at Download Source 




 Highlights in 1.3.3.10

 * One important security bug was fixed.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users as well as 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.3.10-1.fc21 
 
and https://admin.fedoraproject.org/updates/389-ds-base-1.3.3.10-1.fc22 
.


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.3.8

 * Bug 1216203 - CVE-2015-1854 389ds-base: access control bypass with
   modrdn [fedora-all]


http://www.port389.org/docs/389ds/releases/release-1-3-3-10.html
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Help - changelog-nsencryptionalgorithm-ADD

[Noriko Hosoi]

On 06/05/2013 11:07 AM, Denise Cosso wrote:

Hi,

Anyone know  how to do?

  Stop the server, and add "nsencryptionalgorithm: AES" or
"nsslapd-encryptionalgorithm: 3DES" to the changelog entry.  The current
  supported encryption algorithms are AES and 3DES

dn: cn=changelog5,cn=config
objectClass: top
objectClass: extensibleobject
cn: changelog5
nsslapd-changelogdir: /var/lib/dirsrv/slapd-ID/db/changelog
*nsslapd-encryptionalgorithm: AES*
Thanks,

Denise



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
If you already have configured SSL on your Directory Server, just adding 
"nsslapd-encryptionalgorithm: AES" to cn=changelog5,cn=config turns on 
the changelog encryption.*


*Then, please restart the server.  You'd be able to see this attribute 
in your cn=changelog5.


|nsSymmetricKey:: BASE64_STRING|

And if you run, e.g., strings against to your changelog, the attribute 
values are encrypted as follows:


   # strings 62a1c402-e47611e4-bcd98b6b-27e8b792_55301a330001.db
   ({replicageneration} 55301a330001
   5{replica 1} 55301a440001 55301a440001
   014d
   [...]
   objectClass
   _+7B
   g`nT
   givenName
   userPassword
   @~$a|F
   creatorsName
   h@3Z
   modifiersName
   h@3Z
   [...]

Please note that, the encryption starts on the changes made after the 
changelog encryption is enabled.*

*Thanks,
--noriko*

*
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Valgrind on a slapi plugin

[Noriko Hosoi]

On 03/30/2015 04:47 PM, Prashant Bapat wrote:

Hi,

Is there a documentation on how to run Valgrind on a Slapi plugin for 
389 ds.


Thanks.
--Prashant


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
Are you looking for the way to run Valgrind just on one plug-in? Then, I 
don't have the answer, but this is the way how to run Valgrind on the 
server including all plug-in's.

http://www.port389.org/docs/389ds/FAQ/faq.html#memory-growth
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] 389-admin-1.1.38 setup problems

[Noriko Hosoi]

On 03/22/2015 12:00 PM, Thomas Spuhler wrote:

On Saturday, March 21, 2015 04:46:17 PM Thomas Spuhler wrote:

setup-ds-admin.pl returns an error.

I packaged the new version of 389-admin-1.1.38 for Mageia (security update) and 
when running the
setup script I am getting the error:
httpd: Syntax error on line 136 of /etc/dirsrv/admin-serv/httpd.conf: Cannot 
load
/usr/lib64/dirsrv/modules/mod_admserv.so into server: 
/usr/lib64/dirsrv/modules/mod_admserv.so:
undefined symbol: admldapGetAuthDN

I have not updated 389-adminutil as the fedora spec file doesn't require it.
Could this be the problem?

I have resolved it by upgrading 389-adminutil to vers. 1.1.21. I couldn't find 
this as requirement
anywhere,
Thank you for upgrading to 389-admin-1.1.38.  Sorry about the 
inconvenience.  We released and announced the version of 389-admin and 
adminutil-1.1.21 together, which are to be upgraded at the same time:

http://www.port389.org/docs/389ds/releases/release-admin-1-1-38.html

Thanks,
--noriko



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Review 389-ds install/upgrade procedures and requisites on http://directory.fedoraproject.org/docs/389ds/download.html

[Noriko Hosoi]

Hello,

On 03/09/2015 02:18 PM, Robert Viduya wrote:
I'm in the same boat.  We, as an enterprise, have standardized on 
RHEL6 as our OS, with RHEL7 only on the horizon.  Switching to either 
Fedora or CentOS isn't an option.  But the only "official" 389 release 
for RHEL6 is years old.


I reported a bug about a year ago, 47739, that's been fixed since 
1.2.11.26.  But only 1.2.11.15 is available for RHEL6.  So, yes, 
there's at least one fix that we need that isn't available to us.  But 
really, there's tons of bug fixes and features that have come out 
since then.  The longer we're held back, the harder it will be to get 
our user base to adapt to all the new features once we do upgrade.
The fix for the ticket 47739 is included in 389-ds-base-1.2.11.15-32 and 
newer and released on October 13, 2014 for RHEL-6.6.


Sorry about missing the announcement.  Could it be possible to upgrade 
your RHEL6 bits to the latest 389-ds-base-1.2.11.15-50.el6?


Thanks.


Is compiling from source our only option?  Because, I can do that. 
 I'd just rather not have to.


On Mar 9, 2015, at 10:26 AM, Rich Megginson > wrote:



On 03/09/2015 12:39 AM, Juan Carlos Camargo wrote:
I'd like to see an updated install/upgrade procedure for 389-ds. The 
info on the web page is outdated, links for coprs are not working 
either , maybe they are not valid anymore.


They are not, and have been removed.  It was just too difficult to 
maintain the copr repos.  The recommended versions are now the ones 
provided by your base operating system.

See also http://www.port389.org/docs/389ds/releases/end-1-2-11.html

As a user of Centos6x I'm somehow lost when I see versions of the 
product coming out whereas my servers are stuck with the older ones.


Right.  We are trying to keep EL6 versions stable - they are mostly 
in maintenance mode.  Is there some feature you require that is not 
available in 1.2.11 but is in some later version?  If not, then do 
you really need to upgrade?



Should I make the move to Fedora?


It depends.  Have you considered upgrading to CentOS 7.x instead?  
The only problem is that the admin server and console bits are not 
yet available, but should be shortly.





*Tfn: 957-211157 / 650932877*



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org 


https://admin.fedoraproject.org/mailman/listinfo/389-users




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Announcing 389 Admin Server 1.1.38

[Noriko Hosoi]

   389 Admin Server 1.1.38

The 389 Directory Server team is proud to announce 389-admin version 
1.1.38 and 389-adminutil version 1.1.21.


Fedora packages are available from the EPEL7, Fedora 20, Fedora 21 and 
Rawhide repositories.


The new packages and versions are:

 * 389-admin-1.1.38-1
 * 389-adminutil-1.1.21-1

Source tarballs are available for download at Download Admin Source 
 and Download 
Adminutil Source 
.



 Highlights in 389-admin-1.1.38 and 389-adminutil-1.1.21

 * Several bugs are fixed including security bugs – stop using DES and
   old SSL version.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users and 
following pages:


 * https://admin.fedoraproject.org/updates/389-admin-1.1.38-1.el7
   
 * https://admin.fedoraproject.org/updates/389-admin-1.1.38-1.fc20
   
 * https://admin.fedoraproject.org/updates/389-admin-1.1.38-1.fc21
   
 * https://admin.fedoraproject.org/updates/389-adminutil-1.1.21-2.el7
   
 * https://admin.fedoraproject.org/updates/389-adminutil-1.1.21-1.fc20
   
 * https://admin.fedoraproject.org/updates/389-adminutil-1.1.21-1.fc21
   

If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 389-admin-1.1.35

 * Ticket 48024 - repl-monitor invoked from adminserver cgi fails
 * Ticket 47995 - Admin Server: source code cleaning
 * Ticket 47891 - Admin Server reconfig breaks SSL config
 * Ticket 47929 - Admin Server - disable SSLv3 by default
 * Ticket 201 - nCipher HSM cannot be configured via the console
 * Ticket 47493 - Configuration Tab does not work with FIPS mode enabled
 * Ticket 47697 - Resource leak in lib/libdsa/dsalib_updown.c
 * Ticket 47860 - register-ds-admin.pl problem when following steps to
   replicate o=netscaperoot
 * Ticket 47548 - register-ds-admin does not register into remote config ds
 * Ticket 47893 - Admin Server should use Sys::Hostname instead Net::Domain
 * Ticket 47891 - Admin Server reconfig breaks SSL config
 * Ticket 47300 - Update man page for remove-ds-admin.pl
 * Ticket 47850 - “nsslapd-allow-anonymous-access: rootdse” makes login
   as “admin” fail at the first time
 * Ticket 47497 - Admin Express - remove “Security Level”
 * Ticket 47495 - admin express: wrong instance creation time
 * Ticket 47665 - Create new instance results in setting wrong ACI for
   the “cn=config” entry
 * Ticket 47478 - No groups file? error restarting Admin server
 * Ticket 47300 - [RFE] remove-ds-admin.pl: redesign the behaviour
 * Ticket 434 - admin-serv logs filling with “admserv_host_ip_check:
   ap_get_remote_host could not resolve “
 * Ticket 47563 - cannot restart directory server from console
 * Ticket 222 - Admin Express issues “Internal Server Error” when the
   Config DS is down.
 * Ticket 418 - Error with register-ds-admin.pl
 * Ticket 377 - Unchecked use of SELinux command Reviewed by: rmeggins
 * Ticket 47498 - Error Message for Failed to create the configuration
   directory server


 Detailed Changelog since 389-adminutil-1.1.19

 * Ticket 47929 - adminutil - future proof getSSLVersion
 * Ticket 47929 - Adminutil - do not use SSL3 by default
 * Ticket 47850 - “nsslapd-allow-anonymous-access: rootdse” makes login
   as “admin” fail at the first time
 * Ticket 47881 - crash during debug session in adminutil
 * Ticket 47680 - Upgraded 389-admin rpms and now I can’t
   start dirsrv-admin

http://www.port389.org/docs/389ds/releases/release-admin-1-1-38.html
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.

[389-users] Announcing 389 Console 1.1.9

[Noriko Hosoi]

   389 Console 1.1.9

The 389 Directory Server team is proud to announce 389-console version 
1.1.9, 389-ds-console version 1.2.10, 389-admin-console version 1.1.10, 
and idm-console-framework version 1.1.9.


Fedora packages are available from the EPEL7, Fedora 20, Fedora 21 and 
Rawhide repositories.


The new packages and versions are:

 * 389-console-1.1.9-1
 * 389-ds-console-1.2.10-1
 * 389-admin-console-1.1.10-1
 * idm-console-framework-1.1.9-1

Source tarballs are available for download at Download 389 Console 
Source , 
Download 389 Ds Console Source 
, 
Download 389 Admin Console Source 
 and 
Download Idm Console Framework Source 
.



 Highlights in 389-console-1.1.9, 389-ds-console-1.2.10,
 389-admin-console-1.1.10 and idm-console-framework-1.1.9-1

 * Several bugs are fixed including security bugs – enable TLS version
   1.1 and newer; stop using old SSL version.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users and 
following pages:


 * https://admin.fedoraproject.org/updates/389-console-1.1.9-1.el7
   
 * https://admin.fedoraproject.org/updates/389-console-1.1.9-1.fc20
   
 * https://admin.fedoraproject.org/updates/389-console-1.1.9-1.fc21
   
 * https://admin.fedoraproject.org/updates/389-ds-console-1.2.10-1.el7
   
 * https://admin.fedoraproject.org/updates/389-ds-console-1.2.10-1.fc20
   
 * https://admin.fedoraproject.org/updates/389-ds-console-1.2.10-1.fc21
   
 * https://admin.fedoraproject.org/updates/389-admin-console-1.1.10-1.el7
   
 * https://admin.fedoraproject.org/updates/389-admin-console-1.1.10-1.fc20
   
 * https://admin.fedoraproject.org/updates/389-admin-console-1.1.10-1.fc21
   
 * https://admin.fedoraproject.org/updates/idm-console-framework-1.1.9-2.el7
   
 * https://admin.fedoraproject.org/updates/idm-console-framework-1.1.9-2.fc20
   
 * https://admin.fedoraproject.org/updates/idm-console-framework-1.1.9-1.fc21
   

If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 389-console-1.1.7

 * Ticket 47604 - 389-console: remove versioned jars from %{_javadir}
 * Ticket 97 - 389-console should provide man page


 Detailed Changelog since 389-ds-console-1.2.7

 * Bug 1022104 - Remove versioned jarfiles from
   _javadir (idm-console-framework)
 * Ticket 47994 - DS Console always sets nsSSL3 to “on” when a securty
   setting is adjusted
 * Ticket 47380 - RFE: Winsync loses connection with AD objects when
   they move from the console.
 * Ticket 135 - DS console - right clicking an object does not select
   that object
 * Ticket 47887 - DS Console does not correctly disable SSL
 * Ticket 47485 - DS instance cannot be restored from remote console
 * Ticket 47886 - DS Console - mouse wheel speed very slow
 * Ticket 176 - DS Console should timeout when mismatched port and
   protocol combination is chosen
 * Ticket 47883 - DS Console - java exception when refreshing schema
 * Ti

[389-users] Announcing 389 Directory Server version 1.3.3.9

[Noriko Hosoi]

   389 Directory Server 1.3.3.9

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.3.9.


Fedora packages are available from the Fedora 21, 22 and 
Rawhide repositories.


The new packages and versions are:

 * 389-ds-base-1.3.3.9-1

A source tarball is available for download at Download Source



 Highlights in 1.3.3.9

 * Several bugs are fixed including 2 security bugs


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users as well as 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.3.9-1.fc21 
 and 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.3.9-1.fc22 
.


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.3.8

 * Bug 1199675 - CVE-2014-8112 CVE-2014-8105 389-ds-base: various
   flaws [fedora-all]
 * Ticket 47431 - Duplicate values for the attribute nsslapd-pluginarg
   are not handled correctly
 * Ticket 47451 - dynamic plugins - fix crash caused by invalid
   plugin config
 * Ticket 47728 - compilation failed with ‘ incomplete
   struct/union/enum’ if not set USE_POSIX_RWLOCKS
 * Ticket 47742 - 64bit problem on big endian: auth method not supported
 * Ticket 47801 - RHDS keeps on logging write_changelog_and_ruv: failed
   to update RUV for unknown
 * Ticket 47828 - DNA scope: allow to exlude some subtrees
 * Ticket 47836 - Do not return ‘0’ as empty fallback value of
   nsds5replicalastupdatestart and nsds5replicalastupdatestart
 * Ticket 47901 - After total init, nsds5replicaLastInitStatus can
   report an erroneous error status (like ‘Referral’)
 * Ticket 47936 - Create a global lock to serialize write operations
   over several backends
 * Ticket 47957 - Make ReplicaWaitForAsyncResults configurable
 * Ticket 48001 - ns-activate.pl fails to activate account if it was
   disabled on AD
 * Ticket 48003 - add template scripts
 * Ticket 48003 - build “suite” framework
 * Ticket 48005 - ns-slapd crash in shutdown phase
 * Ticket 48021 - nsDS5ReplicaBindDNGroup checkinterval not
   working properly
 * Ticket 48027 - revise the rootdn plugin configuration validation
 * Ticket 48030 - spec file should run “systemctl stop” against each
   running instance instead of dirsrv.target
 * Ticket 48048 - Fix coverity issues - 2015/2/24
 * Ticket 48048 - Fix coverity issues - 2015/3/1
 * Ticket 48109 - substring index with nssubstrbegin: 1 is not being
   used with filters like (attr=x*)

http://www.port389.org/docs/389ds/releases/release-1-3-3-9.html
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Announcing 389 Directory Server version 1.3.2.27

[Noriko Hosoi]

   389 Directory Server 1.3.2.27

The 389 Directory Server team is proud to announce 389-ds-base version 
1.3.2.27.


Fedora packages are available from the Fedora 20 repository.

The new packages and versions are:

 * 389-ds-base-1.3.2.27-1

A source tarball is available for download at Download Source 




 Highlights in 1.3.2.27

 * Several bugs are fixed including security bugs – stop using old
   SSL version.


 Installation and Upgrade

See Download  for 
information about setting up your yum repositories.


To install, use *yum install 389-ds* yum install 389-ds After install 
completes, run *setup-ds-admin.pl* to set up your directory 
server. setup-ds-admin.pl


To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run 
*setup-ds-admin.pl -u* to update your directory server/admin 
server/console information. setup-ds-admin.pl -u


See Install_Guide 
 for more 
information about the initial installation, setup, and upgrade


See Source  
for information about source tarballs and SCM (git) access.



 Feedback

We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users as well as 
https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.27-1.fc20 
.


If you find a bug, or would like to see a new feature, file it in our 
Trac instance: https://fedorahosted.org/389



 Detailed Changelog since 1.3.2.26

 * Bug 1199675 - CVE-2014-8112 CVE-2014-8105 389-ds-base: various
   flaws [fedora-all]
 * Ticket 48001 - ns-activate.pl fails to activate account if it was
   disabled on AD
 * Ticket 48027 - revise the rootdn plugin configuration validation

http://www.port389.org/docs/389ds/releases/release-1-3-2-27.html
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] error upgrading the server

[Noriko Hosoi]

On 03/04/2015 03:17 PM, Timo Aaltonen wrote:

Hi

   So I've bumped into an issue on my IPA install (debian), where the
package tries to run an offline upgrade when it's updated, but fails:

[15/03/05:01:13:10] - [Setup] Info Error adding entry
'cn=entryusn,cn=default indexes, cn=config,cn=ldbm
database,cn=plugins,cn=config'.  Error: No such object
[15/03/05:01:13:10] - [Setup] Fatal Error: could not update the
directory server.
[15/03/05:01:13:10] - [Setup] Fatal Exiting . . .

any ideas what's wrong?



Could you tell the pre-upgrade version and post-upgrade version?

We are interested in the IPA version pair as well as the underlying 
389-ds-base version pair.

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Cannot delete domain

[Noriko Hosoi]

On 03/04/2015 10:53 AM, Noriko Hosoi wrote:
Well, it is an error message issue... You cannot "delete" your suffix. 
Sorry, please iignore this statement.  I could delete it.  Continue 
investigating...


BTW, could you run this command line again replacing  num*b*subordinates 
with *numsubordinates*?
> ldapsearch -D "cn=Directory Manager" -b "dc=test,dc=mydomain,dc=tld" 
-W "(objectclass=*)" *numsubordinates *


Thanks,
--noriko

To do so, you need to delete the backend togather.

$ ldapsearch -LLLx ... -b "dc=example,dc=com" -s base 
"(objectclass=*)" dn

dn: dc=example,dc=com

$ ldapdelete -x ...
dc=example,dc=com
ldap_delete: Operation not allowed on non-leaf (66)


On 03/04/2015 03:50 AM, Christian Katterl wrote:

Hi,

ldapsearch -D "cn=Directory Manager" -b "dc=test,dc=mydomain,dc=tld" 
"(objectclass=nsTombstone)" -W


# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=nsTombstone)
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1


and...

ldapsearch -D "cn=Directory Manager" -b "dc=test,dc=mydomain,dc=tld" 
-W "(objectclass=*)" numbsubordinates


# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: numbsubordinates
#

# test.mydomain.tld
dn: dc=test,dc=mydomain,dc=tld

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


BR, Christian




Am 04.03.2015 11:59, schrieb German Parente:

Hi Christian,

there has been a bug fixed for your issue but in release 1.2.11.15-34.

https://fedorahosted.org/389/ticket/47367


Could you do this query ?

ldapsearch -D "cn=Directory Manager" -b "dc=test,dc=mydomain,dc=tld"
"(objectclass=nsTombstone)" -W

and also

ldapsearch -D "cn=Directory Manager" -b "dc=test,dc=mydomain,dc=tld"
-W "(objectclass=*)" numbsubordinates

?

Thanks and regards,

German.



- Original Message -

From: "Christian Katterl" 
To: 389-users@lists.fedoraproject.org
Sent: Wednesday, 4 March, 2015 9:30:39 AM
Subject: [389-users] Cannot delete domain

Dear all,

I am using 389-ds version 1.2.11.30-1 (shipped with kolab).
Trying to delete a domain gives the following error: ldap_delete:
Operation not allowed on non-leaf (66)

Is this a (known) bug, or am I doing something wrong?

I tried to delete the domain using:
ldapdelete -c -x -D "cn=Directory Manager" -W -r
"dc=test,dc=mydomain,dc=tld"

When I am looking for entries, there seems to be no remaining element:

ldapsearch -D "cn=Directory Manager" -b "dc=test,dc=mydomain,dc=tld"
"(objectclass=*)" -W

# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# test.mydomain.tld
dn: dc=test,dc=mydomain,dc=tld
dc: test
objectClass: top
objectClass: domain

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

I replaced my real domain-name with test.mydomain.tld

The installation is a single ldap-host with no synchronization or 
so...

Can anyone help?

BR, Christian
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Cannot delete domain

[Noriko Hosoi]

Well, it is an error message issue... You cannot "delete" your suffix.  
To do so, you need to delete the backend togather.


$ ldapsearch -LLLx ... -b "dc=example,dc=com" -s base "(objectclass=*)" dn
dn: dc=example,dc=com

$ ldapdelete -x ...
dc=example,dc=com
ldap_delete: Operation not allowed on non-leaf (66)


On 03/04/2015 03:50 AM, Christian Katterl wrote:

Hi,

ldapsearch -D "cn=Directory Manager" -b "dc=test,dc=mydomain,dc=tld" 
"(objectclass=nsTombstone)" -W


# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=nsTombstone)
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1


and...

ldapsearch -D "cn=Directory Manager" -b "dc=test,dc=mydomain,dc=tld" 
-W "(objectclass=*)" numbsubordinates


# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: numbsubordinates
#

# test.mydomain.tld
dn: dc=test,dc=mydomain,dc=tld

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


BR, Christian




Am 04.03.2015 11:59, schrieb German Parente:

Hi Christian,

there has been a bug fixed for your issue but in release 1.2.11.15-34.

https://fedorahosted.org/389/ticket/47367


Could you do this query ?

ldapsearch -D "cn=Directory Manager" -b "dc=test,dc=mydomain,dc=tld"
"(objectclass=nsTombstone)" -W

and also

ldapsearch -D "cn=Directory Manager" -b "dc=test,dc=mydomain,dc=tld"
-W "(objectclass=*)" numbsubordinates

?

Thanks and regards,

German.



- Original Message -

From: "Christian Katterl" 
To: 389-users@lists.fedoraproject.org
Sent: Wednesday, 4 March, 2015 9:30:39 AM
Subject: [389-users] Cannot delete domain

Dear all,

I am using 389-ds version 1.2.11.30-1 (shipped with kolab).
Trying to delete a domain gives the following error: ldap_delete:
Operation not allowed on non-leaf (66)

Is this a (known) bug, or am I doing something wrong?

I tried to delete the domain using:
ldapdelete -c -x -D "cn=Directory Manager" -W -r
"dc=test,dc=mydomain,dc=tld"

When I am looking for entries, there seems to be no remaining element:

ldapsearch -D "cn=Directory Manager" -b "dc=test,dc=mydomain,dc=tld"
"(objectclass=*)" -W

# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# test.mydomain.tld
dn: dc=test,dc=mydomain,dc=tld
dc: test
objectClass: top
objectClass: domain

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

I replaced my real domain-name with test.mydomain.tld

The installation is a single ldap-host with no synchronization or so...
Can anyone help?

BR, Christian
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Unable to Run 389-console

[Noriko Hosoi]

What platform you are running on?  How did you install the packages?  
E.g., "yum install 389-ds"?  And could you provide the package versions?

$ rpm -q idm-console-framework
$ rpm -qa | egrep 389

On 03/02/2015 10:44 PM, Hadoop Solutions wrote:

Hi,

please let me know if u have any suggestions on this issue???

-Shaik

On 3 March 2015 at 11:07, Hadoop Solutions > wrote:


Hi,

I have installed 389 DS. I am trying to access 389-console,
getting following error.

please help me resolve this issue.


[root@sv2lxdpdsedi01 java]# 389-console
Exception in thread "main" java.lang.NoClassDefFoundError: error:
   at gnu.java.lang.MainThread.run(libgcj.so.10)
Caused by: java.lang.ClassNotFoundException: error: not found in

gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/bin/build-classpath,file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
   at java.net.URLClassLoader.findClass(libgcj.so.10)
   at java.lang.ClassLoader.loadClass(libgcj.so.10)
   at java.lang.ClassLoader.loadClass(libgcj.so.10)
   at gnu.java.lang.MainThread.run(libgcj.so.10)

Thanks,
Shaik




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] DIRSRV restarts - Multiple times today

[Noriko Hosoi]

On 03/02/2015 11:08 AM, Jordan, Phillip wrote:


Today the DIRSRV has crashed twice on each of our two servers.  We 
have been attempting to find the root cause and also in weeks past 
installed the CORE Pack RPM’S. In debugging this in stage we were able 
to create a manual core file but once we upgraded to -48 in stage we 
can no longer do so.  Since in production we were at release .48 and 
the same condition was occurring where we could not create a manual 
core file.   This validated that the update to .48 made the ability to 
create core files inoperable.


Can someone assist in getting us detailed information on how to get a 
CORE so that these can be resolved?



http://www.port389.org/docs/389ds/FAQ/faq.html#debug_crashes

Thanks,
--norik

As I wrote this email two more DIRSRV failures occurred and the 
service was recycled.


OS information:

Oracle Linux Server release 6.6

Red Hat Enterprise Linux Server release 6.6 (Santiago)

Oracle Linux Server release 6.6

DIRSRV information

389-ds-base-devel-1.2.11.15-48.el6_6.x86_64

389-ds-base-libs-1.2.11.15-48.el6_6.x86_64

389-ds-base-1.2.11.15-48.el6_6.x86_64

389-ds-base-debuginfo-1.2.11.15-48.el6.x86_64

**

*Phillip Jordan***

Lead Engineer, Web Hosting

**

555 W. Adams

Chicago, IL 60661

_transunion.com ___

This email including, without limitation, the attachments, if any, 
accompanying this email, may contain information which is confidential 
or privileged and exempt from disclosure under applicable law. The 
information is for the use of the intended recipient. If you are not 
the intended recipient, be aware that any disclosure, copying, 
distribution, review or use of the contents of this email, and/or its 
attachments, is without authorization and is prohibited. If you have 
received this email in error, please notify us by reply email 
immediately and destroy all copies of this email and its attachments.




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Passsync not changing passwords

[Noriko Hosoi]

On 02/24/2015 03:38 PM, Daniel Franciscus wrote:
So I finally figured out the problem in case anyone ever comes across 
this again.


In order for a password filter to register and to actually capture 
password changes on a server, the filename of the DLL must in this 
key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Notification 
Packages. After searching the entire registry on both of my domain 
controllers for the string "passhook" I saw that the one that was 
working had passhook in this key and the one that was not working did 
not. This key is set during installation of passsync, so for whatever 
reason the passsync installation on the non working DC was not able to 
add that value. I added the value manually, rebooted and it works.


Just thought you should know in case you ever see this again.

Thanks again for your help though, it pointed me in the direction I 
needed.

Hello Daniel,

Thank you so much for your investigation and sharing the result with 
us.  Yes, 'passhook' is supposed to be set in the registry, but somehow 
it was not...  I'm going to add your finding to the FAQ/troubleshooting 
on our wiki port389.org.

PassSync.wxs
Key='SYSTEM\ControlSet001\Control\Lsa' ForceCreateOnInstall='yes' >
  Type='multiString' Value='passhook'/>



Thanks!
--noriko




Dan Franciscus

Systems Administrator

Information Technology Group

Institute for Advanced Study

609-734-8138



--------
*From: *"Noriko Hosoi" 
*To: *389-users@lists.fedoraproject.org
*Sent: *Wednesday, February 18, 2015 2:01:41 PM
*Subject: *Re: [389-users] Passsync not changing passwords

On 02/18/2015 05:17 AM, Daniel Franciscus wrote:

Hello,

We have two Windows server 2003 domain controllers and I installed
passsync on both servers in order to sync password changes to our
389 LDAP. On one domain controller, it appears passsync is working
correctly as I can see in the passsync.log when I change a
password through that domain controller. On the other domain
controller, when I change a password I do not see any activity in
the passsync.log at all. I have passsync on both domain
controllers set to verbose logging. I also restarted both domain
controllers after installing passsync.

On the domain controller that is not syncing passwords the log
appears as:

02/18/15 07:52:59: PassSync service initialized
02/18/15 07:52:59: PassSync service running
02/18/15 07:52:59: No entries yet
02/18/15 07:52:59: Password list is empty.  Waiting for passhook event

Does anyone have an idea of what the issue could be?

What is the version of PassSync?  The latest is 1.1.6.
http://www.port389.org/docs/389ds/releases/release-passsync-1-1-6.html

Did yo have a chance to enable passhook log?

In the regedit, go to: HKEY_LOCAK_MACHINE --> SOFTWARE\PasswordSync
then, set 1 to Log Level.

If you add or modify a password on the Windows Server 2003 domain 
cotroller, what do you get?  Any errors?




Dan Franciscus

Systems Administrator

Information Technology Group

Institute for Advanced Study

609-734-8138





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Passsync not changing passwords

[Noriko Hosoi]

On 02/18/2015 11:45 AM, Daniel Franciscus wrote:
Yes, logging is set to 1. No errors at all, as if passsync is not 
detecting a password change.

Sorry, I was not precise about the passhook log.

cd C:\windows\system32
ls passhook*

You should be able to see 3 files: passhook.dat, passhook.dll, and 
passhook.log.


Do you see any logs in the passhook.log file?  For instance, my test 
shows these messages on successful sync.  Do you see them?


   02/18/15 14:16:34 user AD_sync_user6 password changed
   02/18/15 14:16:34 0 entries loaded from file
   02/18/15 14:16:34 1 entries saved to file

If empty even if you update any password on AD, you may need to reboot 
the Windows machine...


I am going to reboot the server after production hours again to see if 
that resolves it.




Dan Franciscus

Systems Administrator

Information Technology Group

Institute for Advanced Study

609-734-8138




*From: *"Noriko Hosoi" 
*To: *389-users@lists.fedoraproject.org
*Sent: *Wednesday, February 18, 2015 2:01:41 PM
*Subject: *Re: [389-users] Passsync not changing passwords

On 02/18/2015 05:17 AM, Daniel Franciscus wrote:

Hello,

We have two Windows server 2003 domain controllers and I installed
passsync on both servers in order to sync password changes to our
389 LDAP. On one domain controller, it appears passsync is working
correctly as I can see in the passsync.log when I change a
password through that domain controller. On the other domain
controller, when I change a password I do not see any activity in
the passsync.log at all. I have passsync on both domain
controllers set to verbose logging. I also restarted both domain
controllers after installing passsync.

On the domain controller that is not syncing passwords the log
appears as:

02/18/15 07:52:59: PassSync service initialized
02/18/15 07:52:59: PassSync service running
02/18/15 07:52:59: No entries yet
02/18/15 07:52:59: Password list is empty.  Waiting for passhook event

Does anyone have an idea of what the issue could be?

What is the version of PassSync?  The latest is 1.1.6.
http://www.port389.org/docs/389ds/releases/release-passsync-1-1-6.html

Did yo have a chance to enable passhook log?

In the regedit, go to: HKEY_LOCAK_MACHINE --> SOFTWARE\PasswordSync
then, set 1 to Log Level.

If you add or modify a password on the Windows Server 2003 domain 
cotroller, what do you get?  Any errors?




Dan Franciscus

Systems Administrator

Information Technology Group

Institute for Advanced Study

609-734-8138





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Passsync not changing passwords

[Noriko Hosoi]

On 02/18/2015 05:17 AM, Daniel Franciscus wrote:

Hello,

We have two Windows server 2003 domain controllers and I installed 
passsync on both servers in order to sync password changes to our 389 
LDAP. On one domain controller, it appears passsync is working 
correctly as I can see in the passsync.log when I change a password 
through that domain controller. On the other domain controller, when I 
change a password I do not see any activity in the passsync.log at 
all. I have passsync on both domain controllers set to verbose 
logging. I also restarted both domain controllers after installing 
passsync.


On the domain controller that is not syncing passwords the log appears as:

02/18/15 07:52:59: PassSync service initialized
02/18/15 07:52:59: PassSync service running
02/18/15 07:52:59: No entries yet
02/18/15 07:52:59: Password list is empty.  Waiting for passhook event

Does anyone have an idea of what the issue could be?

What is the version of PassSync?  The latest is 1.1.6.
http://www.port389.org/docs/389ds/releases/release-passsync-1-1-6.html

Did yo have a chance to enable passhook log?

In the regedit, go to: HKEY_LOCAK_MACHINE --> SOFTWARE\PasswordSync
then, set 1 to Log Level.

If you add or modify a password on the Windows Server 2003 domain 
cotroller, what do you get?  Any errors?





Dan Franciscus

Systems Administrator

Information Technology Group

Institute for Advanced Study

609-734-8138





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Announcing 389 Directory Server version 1.3.3.8 and 1.3.2.26

[Noriko Hosoi]

The 389 Directory Server team is proud to announce 389-ds-base testing 
version 1.3.3.8 for Fedora 21 and 1.3.2.26 for Fedora 20.


Highlights in the versions are supporting the TLS version 1.1 and newer 
and disabling SSL version 3 and many bug fixes.


The SSL/TLS version range in the 389 Directory Server needs to be 
matched with the one in the rest of the 389 family, 389 Directory 
Password Synchronization, 389 Admin Server, and 389 Console.  If you are 
using any of them with 389 Directory Server, please upgrade the package 
to the latest version listed in the Release Notes on port389.org, as well.


http://www.port389.org/docs/389ds/releases/release-notes.html
# 389 Console 1.1.9 
 
/(February 5, 2015)/
# 389 Directory Server 1.3.3.8 
 
/(February 5, 2015)/
# 389 Directory Server 1.3.2.26 
 
/(February 5, 2015)/
# 389 Admin Server 1.1.38 
 
/(February 3, 2015)/
# 389 Directory Password Synchronization 
 
/(January 28 2015)/


We are very interested in your feedback!

Please provide feedback and comments to the 389-users mailing list: 
https://admin.fedoraproject.org/mailman/listinfo/389-users.


Thank you,
389 Directory Server Team


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] 389-console

[Noriko Hosoi]

On 02/02/2015 03:01 PM, warron.french wrote:
I recently installed 389-ds-base-1.2.11.15-48.el6_6.x86_64 on my 
CentOS-6.6 machine.


The installation was a little different from my documentation that I 
personally wrote up.  No problem, I adapted.


Now however, the configuration and setup of DSes on my server don't 
quite work the same way.  I have in my document the command to run 
setup-ds-admin.pl , but that script no 
longer exist.

setup-ds-admin.pl is in a different package "389-admin".

Could you check you have it?
rpm -q 389-admin



No big deal, I ran setup-ds.pl  instead (not 
really knowing the different between the to versions).  But there is 
still no 389-console anywhere to be found with this version running on 
my server.

389-console is in yet another package.

Probably, you should run "yum install 389-ds" to get all the packages?

At least, you need these packages.
389-ds-base-libs
389-ds-base
389-admin
389-adminutil
389-console
389-admin-console
389-ds-console
idm-console-framework



Where is the GUI tool that enables me to build DITs or dirsrv 
instances?  I used to use 389-console (the binary that interacted with 
my server's LDAP instance that I created using setup-ds-admin.pl 
 but I can't seem to find the new version of 
this application. Was the tool entirely disbanded?  Is there no longer 
any support with a GUI tool and everything must be done with command 
line using ldapadd/ldapmodify to insert and create the appropriate OUs?


Please help, I don't want to try and fight and use openldap, I never 
got it working and their user pool is not very helpful at all.  It is 
the major reason why I took the time to write my own installation 
instructions for my organization.


Thank you.
--
Warron French



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] shrink changelogdb - Help

[Noriko Hosoi]

On 01/30/2015 12:54 PM, Jordan, Phillip wrote:


Can someone forward a link on how to shrink down the changelogdb, we 
tried the LDIF method  to create the values but the schema  is not 
present in the directory to create the object.  Does a better document 
exist or someone that has come across this same issue let me know.  
Thanks in advance.


We are running 1.2.11.15 B2013.357.1711

1) Do you happen to have a plan to upgrade to 389-ds-base-1.3.2 or 
1.3.3?  This feature is available on them.


Ticket #197 - BDB backend - clear free page files to reduce 
changelog size

https://fedorahosted.org/389/ticket/197
2 config parameters are introduced to specify the interval of the
compact calls.
Primary DBs (id2entry):
  dn: cn=config,cn=ldbm database,cn=plugins,cn=config
  nsslapd-db-compactdb-interval: 
Changelog DBs:
  dn: cn=changelog5,cn=config
  nsslapd-changelogcompactdb-interval: 
By default, 2592000 seconds (30 days)

2) This config parameter "nsslapd-changelogmaxage (Max Changelog Age)" 
is available in 389-ds-base-1.2.11.  If not set, you may want to 
consider setting it.

Please see this doc section:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnchangelog5-nsslapd_changelogmaxage_Max_Changelog_Age
But please note that the physical size of changelog db is not affected 
by the parameter.


3) If you do export and import back the main data without the state 
information (without -r option for db2ldif) on a master, and do consumer 
initialization against the other servers in the topology, the changelog 
dbs would be regenerated.  But it'd require quite a long down time...


**

*Phillip Jordan***

Lead Engineer, Web Hosting

555 W. Adams

Chicago, IL 60661

_transunion.com ___

This email including, without limitation, the attachments, if any, 
accompanying this email, may contain information which is confidential 
or privileged and exempt from disclosure under applicable law. The 
information is for the use of the intended recipient. If you are not 
the intended recipient, be aware that any disclosure, copying, 
distribution, review or use of the contents of this email, and/or its 
attachments, is without authorization and is prohibited. If you have 
received this email in error, please notify us by reply email 
immediately and destroy all copies of this email and its attachments.




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Permanently Disable SSLv3

[Noriko Hosoi]

Hello,

What is the versions of your server and console?
$ rpm -q 389-ds-base idm-console-framework 389-ds-console 389-ds-admin

On 12/30/2014 02:32 PM, John Trump wrote:
Is there a way to permanently disable SSLv3 in directory server? If I 
modify the dse.ldif file and set nssSSL3

When you made this modification, did you restart the server?
to off this works until an admin goes through the gui and makes a 
change to the encryption cert and saves config. Once this happens 
SSLv3 is enabled again.
If the answer to the above question is "yes", is it possible to repeat 
the operations with the audit log enabled 
("nsslapd-auditlog-logging-enabled: on") and share the audit log 
(/var/log/dirsrv/slapd-YOURID/audit) with us?  Thanks.





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Please review (take 2): [389 Project] #47960: cookie_change_info returns random negative number if there was no change in a tree

[Noriko Hosoi]

https://fedorahosted.org/389/ticket/47960

https://fedorahosted.org/389/attachment/ticket/47960/0001-Ticket-47960-cookie_change_info-returns-random-negat.patch 

git patch file (master) -- fix for the random negative value of 
cookie_change_info


https://fedorahosted.org/389/attachment/ticket/47960/0001-Ticket-47960-cookie_change_info-returns-random-negat.2.patch
git patch file (master) -- additional patch for the type mismatch 
between the change number and cookie_change_info


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users