ldapsearch doesn't return the userpassword field
by Janet Houser
Hi,
I've been looking through the archives for information, but I haven't stumbled on a solution to my problem.
I'm running ds-389 (389-ds-base-1.3.4.0) on a centos 7 box (CentOS Linux release 7.2.1511). I have a centos OS client configured using SSL/TLS
which queries the LDAP server. Per a previous thread, I configured the memeberOf plugin and all seems to be working properly.
I have a php script that will run on the client and change the LDAP password for the user. The problem is, the script looks for the SSHA has
of the password when an ldapsearch is issued.
However, when I issue a general ldapsearch (anonymously) I don't get the userpassword field. I read in your archives that I might have
to be the "directory manager" user in order to see the hashed password. I've been playing around with the ldapsearch syntax, but I can't
quite get it right.
Anyway, my question is, can I set a flag in 389-ds that will display the hashed userpassword? I think that will solve my problem with the php script returning an error that it can't retrieve the old password.
Thanks,
5 years, 11 months
Re: SSL replication error
by Mark Reynolds
On 05/09/2018 05:56 AM, Michal Medvecky wrote:
>> Under cn=config, what is "nsslapd-ssl-check-hostname" set to? Try
>> setting it to "off" to see if it makes a difference.
>
> Ok, this “helped”, but I have no idea why?
The server uses the openldap client libraries for replication
connections. Setting nsslapd-ssl-check-hostname sets these flags on the
connection as follows:
For server authentication it sets this flag:
LDAPSSL_AUTH_CNCHECK --> This checks the hostname in the
certificate subject to that of the host
For SSL client auth it sets this flag:
LDAP_OPT_X_TLS_HARD
So the issue here is either openldap is not finding the correct
hostname, or the hostname in the certificate subject is wrong.
To check the subject of the certificate use certutil. Here is an example:
Get the names of the certificates in the in the security database:
# certutil -L -d /etc/dirsrv/slapd-localhost
Find the server's certificate name (server-cert in this example) and run
the command below:
# certutil -L -d /etc/dirsrv/slapd-localhost -n server-cert | grep Subject
The subject should start with "CN=<FQDN>, ...". Is this host name
complete and correct?
>
> When googling for ‘nsslapd-ssl-check-hostname’, I found this:
>
> > nsslapd-ssl-check-hostname (Verify Hostname for
> OutboundConnections)Specifies whether an SSL-enabled Directory Server
> (with certificate based client authentication turned on) should verify
> authenticity of a request by matching the hostname against the value
> assigned to the Common Name (CN) attributeof the subject name in the
> certificate being presented.
>
> Two arguments:
>
> - I’m _not_ using certificate based client authentications
> - my hostnames are valid
>
> What I’m confused with is the error log on ldap-master-b01:
>
> [09/May/2018:11:27:21 +0200] NSMMReplicationPlugin -
> agmt="cn=rw-to-ldap-master-b02.example.com
> <http://rw-to-ldap-master-b02.example.com>" (ldap-master-b02:636):
> Replication bind with SIMPLE auth resumed
> [09/May/2018:11:27:21 +0200] NSMMReplicationPlugin -
> agmt="cn=rw-to-ldap-master-b02.example.com
> <http://rw-to-ldap-master-b02.example.com>" (ldap-master-b02:636):
> Unable to acquire replica: there is no replicated area
> “dc=example,dc=com" on the consumer server. Replication is aborting.
This means you do not have replication setup for that suffix on the
consumer. Replication will not work until this is done.
> [09/May/2018:11:27:21 +0200] NSMMReplicationPlugin -
> agmt="cn=rw-to-ldap-master-b02.example.com
> <http://rw-to-ldap-master-b02.example.com>" (ldap-master-b02:636):
> Incremental update failed and requires administrator action
> [09/May/2018:11:36:07 +0200] NSMMReplicationPlugin - agmt_delete: begin
> [09/May/2018:11:36:11 +0200] NSMMReplicationPlugin - Beginning total
> update of replica "agmt="cn=rw-to-ldap-master-b02.example.com
> <http://rw-to-ldap-master-b02.example.com>" (ldap-master-b02:636)".
> [09/May/2018:11:36:11 +0200] NSMMReplicationPlugin - Need to create
> replication keep alive entry <cn=repl keep alive 37642,dc=example,dc=com>
> [09/May/2018:11:36:11 +0200] NSMMReplicationPlugin - add dn: cn=repl
> keep alive 37642,dc=example,dc=com
>
> On the fifth line of the log, you can see “ldap-master-b02:636”
> instead of the full hostname “ldap-master-b02.example.com
> <http://ldap-master-b02.example.com>”, but, as seen in my previous
> e-mail, the nsDS5ReplicaHost points to the full hostname.
This is a red herring, the server prints the hostname not the FQDN just
in the logging.
Mark
>
> Michal
5 years, 11 months
ns-slapd segfault
by Bart
Hi all,
I am using 389-ds as a part of FreeIPA setup. I've established trust with AD domain but ds server crashes when I try to authenticate with an AD user on a linux system.
The version I am using is:
389-ds-base.x86_64 1.3.7.10-1.fc27 @updates
389-ds-base-libs.x86_64 1.3.7.10-1.fc27 @updates
Related dmesg output is:
[ 2998.558825] ns-slapd[1019]: segfault at 0 ip 00007f5cfa4aa20b sp 00007f5cca64fab0 error 4 in libtcmalloc.so.4.4.5[7f5cfa483000+46000]
[69484.585785] ns-slapd[5558]: segfault at 0 ip 00007ff7a797620b sp 00007ff773e9dab0 error 4 in libtcmalloc.so.4.4.5[7ff7a794f000+46000]
[70128.856460] ns-slapd[5799]: segfault at 0 ip 00007f5bb28e820b sp 00007f5b83e19cd0 error 4 in libtcmalloc.so.4.4.5[7f5bb28c1000+46000]
[70841.531994] ns-slapd[6687]: segfault at 0 ip 00007f3b26217213 sp 00007f3af9b84b00 error 4 in libtcmalloc.so.4.4.5[7f3b261f0000+46000]
Everything runs on Fedora 27, I use the packages from the upstream repo.
Can anyone point me to the way of fixing this?
Thank you
Bart
5 years, 11 months
SSL replication error
by Michal Medvecky
Hello,
can someone please help me understanding this error:
[07/May/2018:13:51:13 +0200] slapi_ldap_bind - Error: could not send bind request for id [cn=MasterMasterReplicationManager,cn=config] authentication mechanism [SIMPLE]: error -1 (Can't contact LDAP server), system error -5987 (Invalid function argument.), network error 115 (Operation now in progress, host "ldap-master-b02.mydomain.com:636”)
There is no error on the other side, of course the host and port is reachable, and SSL is enabled with a trusted certificate on the other side (what I verified by querying that server using ldapsearch).
This is the full dump of the replica entry:
# rw-to-ldap-master-b02.dev.mydomain.com, replica, dc\3Dmydomain\2C
dc\3Deu, mapping tree, config
dn: cn=rw-to-ldap-master-b02.dev.mydomain.com,cn=replica,cn=dc\3D
mydomain\2Cdc\3Deu,cn=mapping tree,cn=config
nsDS5ReplicaUpdateSchedule: 0001-2359 0123456
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaPort: 636
nsDS5ReplicaTransportInfo: SSL
nsDS5ReplicaBindDN: cn=MasterMasterReplicationManager,cn=config
objectClass: nsds5replicationagreement
objectClass: top
nsDS5ReplicaRoot: dc=mydomain,dc=eu
nsDS5ReplicaHost: ldap-master-b02.dev.mydomain.com
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE authorityRevocationLis
t
description: Agreement between ldap-master-b01.dev.mydomain.com a
nd ldap-master-b02.dev.mydomain.com
cn: rw-to-ldap-master-b02.dev.mydomain.com
nsDS5ReplicaCredentials: {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
RERBNEJDUXhZamN5WXpNeVppMDNPR00zTXpOaA0KTUMxaE1XTmtabUl5WmkwMVpUVmtOR1l5TlFBQ
0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQlFjWk9FZlZBL2xQeG
tMQ2ZRcHZmbw==}OjATeE/K+0qb9fB4HpA1sA==
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 19700101000000Z
nsds5replicaLastUpdateEnd: 19700101000000Z
nsds5replicaChangesSentSinceStartup:
nsds5replicaLastUpdateStatus: -1 Unable to acquire replicaLDAP error: Can't co
ntact LDAP server
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 19700101000000Z
nsds5replicaLastInitEnd: 19700101000000Z
Thanks
Michal
5 years, 11 months
Announcing 389 Directory Server 1.3.6.15
by Mark Reynolds
389 Directory Server 1.3.6.15
The 389 Directory Server team is proud to announce 389-ds-base
version 1.3.6.15
Fedora packages are available from the Fedora 26.
https://koji.fedoraproject.org/koji/taskinfo?taskID=26850712
<https://koji.fedoraproject.org/koji/taskinfo?taskID=26850712>
https://bodhi.fedoraproject.org/updates/FEDORA-2018-bdfd69e662
<https://bodhi.fedoraproject.org/updates/FEDORA-2018-bdfd69e662>
The new packages and versions are:
* 389-ds-base-1.3.6.15-1
Source tarballs are available for download at Download
389-ds-base Source
<https://releases.pagure.org/389-ds-base/389-ds-base-1.3.6.15.tar.bz2>
Highlights in 1.3.6.15
* Security and bug fixes
Installation and Upgrade
See Download <http://www.port389.org/docs/389ds/download.html> 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* if you have 389-admin installed,
otherwise please run *setup-ds.pl* to set up your directory server.
To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run
*setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please
run *setup-ds.pl* to update your directory server/admin
server/console information.
See Install_Guide
<http://www.port389.org/docs/389ds/legacy/install-guide.html> for more
information about the initial installation, setup, and upgrade
See Source <http://www.port389.org/docs/389ds/development/source.html>
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...
If you find a bug, or would like to see a new feature, file it in our
Pagure project: https://pagure.io/389-ds-base
* Bump version to 1.3.6.15
* Ticket 49661 - CVE-2018-1089 - Crash from long search filter
* Ticket 49631 - same csn generated twice
* Ticket 49652 - DENY aci’s are not handled properly
* Ticket 49644 - crash in debug build
* Ticket 49619 - adjustment of csn_generator can fail so next
generated csn can be equal to the most recent one received
5 years, 11 months
Announcing 389 Directory Server 1.3.8.1
by Mark Reynolds
389 Directory Server 1.3.8.1
The 389 Directory Server team is proud to announce 389-ds-base
version 1.3.8.1
Fedora packages are available on Fedora 27.
https://koji.fedoraproject.org/koji/taskinfo?taskID=26850516
<https://koji.fedoraproject.org/koji/taskinfo?taskID=26850516>
https://bodhi.fedoraproject.org/updates/FEDORA-2018-0113049e0c
<https://bodhi.fedoraproject.org/updates/FEDORA-2018-0113049e0c>
The new packages and versions are:
* 389-ds-base-1.3.8.1-1
Source tarballs are available for download at Download
389-ds-base Source
<https://releases.pagure.org/389-ds-base/389-ds-base-1.3.8.1.tar.bz2>
Highlights in 1.3.8.1
* Security and bug fixes
Installation and Upgrade
See Download <http://www.port389.org/docs/389ds/download.html> 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* if you have 389-admin installed,
otherwise please run *setup-ds.pl* to set up your directory server.
To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run
*setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please
run *setup-ds.pl* to update your directory server/admin
server/console information.
See Install_Guide
<http://www.port389.org/docs/389ds/legacy/install-guide.html> for more
information about the initial installation, setup, and upgrade
See Source <http://www.port389.org/docs/389ds/development/source.html>
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...
If you find a bug, or would like to see a new feature, file it in our
Pagure project: https://pagure.io/389-ds-base
* Bump version to 1.3.8.1
* Ticket 49661 - CVE-2018-1089 - Crash from long search filter
* Ticket 49652 - DENY aci’s are not handled properly
* Ticket 49649 - Use reentrant crypt_r()
* Ticket 49644 - crash in debug build
* Ticket 49631 - same csn generated twice
* Ticket 48184 - revert previous patch around unuc-stans shutdown crash
* Rebase to 1.3.8 from 1.3.7.10
5 years, 11 months
Announcing 389 Directory Server 1.4.0.9
by Mark Reynolds
389 Directory Server 1.4.0.9
The 389 Directory Server team is proud to announce 389-ds-base
version 1.4.0.9
Fedora packages are available on Fedora 28 and 29(rawhide).
Rawhide(F29)
https://koji.fedoraproject.org/koji/taskinfo?taskID=26850359
<https://koji.fedoraproject.org/koji/taskinfo?taskID=26850359>
F28
https://koji.fedoraproject.org/koji/taskinfo?taskID=26850367
<https://koji.fedoraproject.org/koji/taskinfo?taskID=26850367>
https://bodhi.fedoraproject.org/updates/FEDORA-2018-9206bf2937
<https://bodhi.fedoraproject.org/updates/FEDORA-2018-9206bf2937>
The new packages and versions are:
* 389-ds-base-1.4.0.9-1
Source tarballs are available for download at Download
389-ds-base Source
<https://releases.pagure.org/389-ds-base/389-ds-base-1.4.0.9.tar.bz2>
Highlights in 1.4.0.9
* Security and Bug fixes
Installation and Upgrade
See Download <http://www.port389.org/docs/389ds/download.html> 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* if you have 389-admin installed,
otherwise please run *setup-ds.pl* to set up your directory server.
To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run
*setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please
run *setup-ds.pl* to update your directory server/admin
server/console information.
See Install_Guide
<http://www.port389.org/docs/389ds/legacy/install-guide.html> for more
information about the initial installation, setup, and upgrade
See Source <http://www.port389.org/docs/389ds/development/source.html>
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...
If you find a bug, or would like to see a new feature, file it in our
Pagure project: https://pagure.io/389-ds-base
* Tue May 8 2018 Mark Reynolds mreynolds(a)redhat.com
<mailto:mreynolds@redhat.com> - 1.4.0.9-1
* Bump version to 1.4.0.9
* Ticket 49661 - CVE-2018-1089 - Crash from long search filter
* Ticket 49652 - DENY aci’s are not handled properly
* Ticket 49650 - lib389 enable_tls doesn’t work on F28
* Ticket 49538 - replace cacertdir_rehash with openssl rehash
* Ticket 49406 - Port backend_test.py test to DSLdapObject implementation
* Ticket 49649 - Use reentrant crypt_r()
* Ticket 49642 - lib389 should generate a more complex password
* Ticket 49612 - lib389 remove_ds_instance() does not remove systemd units
* Ticket 49644 - crash in debug build
5 years, 11 months
New Relic "plugin" for graphing 389-DS server measures
by David Boreham
https://github.com/bozemanpass/newrelic_java_ldap_plugin
New Relic is a popular cloud graphing service. This is a "plugin" in
their parlance (actually it is more of an "agent" since it doesn't plug
into anything) that pushes server counters (including the database
stats) to New Relic. Written in Java so requires a JDK on the machine.
Compatible with New Relic's automated "npi" installer.
The readme has information on installation and configuration, and short
descriptions for the measures. Let me know any issues/questions, or feel
free to use the GitHub issues system.
5 years, 11 months
389 Management Console problems, help!
by Christian Palacios
Hi there,
The Directory Server was working just fine, but now when we try to connect
to it using the Management Console (hosted on a Windows VM), it takes a
very long time to connect. Plus whenever I go to the Directory Server ->
Encryption tab, I get a Connection error.
"java.io.InterruptedIOException: HTTP response timeout"
What should I check on the Directory Server to check why the connection is
so slow?? I need help quickly because this is affecting a major project I
am working on.
Thank you!
-Christian
5 years, 11 months
