Replication with SSLCLIENTAUTH: server sent no certificate
by Eugen Lamers
I'm trying to setup a replication with a certificate based authentication between supplier and consumer. The certificates in the certdb at /etc/dirsrv/slapd-XXX contain the very same CA with which the respective server certificates in the certdbs have been signed. The certificates all have the 'u' flag, and the CA has the C and T flag.
The replication (on the supplier) has been setup such that TLS and certificate based authentication is used, see extract from the replication agreement object:
objectclass: nsds5ReplicationAgreement
nsds5replicahost: <consumer-hostname>
nsds5replicaport: 389
nsds5replicatransportinfo: TLS
nsds5replicabindmethod: SSLCLIENTAUTH
Trying to initialize the consumer raises this error in the error-log of the supplier (the host sending the starttls connection request):
Replication bind with EXTERNAL auth failed: LDAP error 48 (Inappropriate authentication) (missing client certificate)
The certificate that the server should have sent can, however, be used with the ldap commandline tools as ldapsearch. In this case a wireshark trace clearly shows that the client sends the certificate during the TLS handshake, while in the above case it doesn't.
The TLS handshake defines that the client has to send an "empty certificate" if it does not have a certificate that has been issued by a CA offered by the server during the handshake. I can't see a reason for the client to think the condition isn't met. The certificate with which the server (supplier) is setup is the only one available.
Is it possible that the server does not know which certificate it has to use for authentication with the consumer server? And if so, how do I make the server know?
The 389-ds in use is the version 1.4.1.6~git0.5ac5a8aad. The problem was the same with 1.4.0.3.
Thanks,
Eugen
2 years, 10 months
ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0
by Graham Leggett
Hi all,
We have a long standing 389ds master LDAP server that was found to be unable to contact it’s slaves. Most specifically, the slaves show nothing in their logs about any kind of connection, while the master is logging this:
[12/Nov/2019:21:39:47.212715697 +0000] - ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0 (Unknown error, host “ldap01:636”)
Key is "system error 0 (no error)”, which leaves us stumped. The error is obviously “success”.
Has anyone seen this kind of thing before?
This is 389ds running on CentOS7 as follows:
389-ds-base-1.3.9.1-10.el7.x86_64
Regards,
Graham
—
3 years
Limits for Multi Master Replication?
by Eugen Lamers
Hi,
We use the 389 Directory Server version 1.4.2.15.
In the documentation of the Red Hat Directory Server it says, as many as 20 masters are supported in an MMR. It sounds to be a hardcoded limitation defined to avoid overloaded servers and network. Shouldn't it be depending on the MMR topology, i.e. rather on the total number of replication agreements within the whole scenario? Or does "20 masters" indeed mean that the limitation of the MMR topology is the number of 380 replication agreements as shown in the "fully connected mesh" scenario (https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...) with 20 masters and 20x19 replication agreements?
Is there someone who possibly has experience with scenarios of more than 20 master servers?
Thanks,
Eugen
3 years, 1 month
389 DS on CentOS 8
by Paul Whitney
Hi guys,
I am just now looking into our 389-ds migration strategy from CentOS 7 to 8. I successfully created my first master 389 instance on 8. It took some getting used to doing it on the cockpit plugin. But what I am missing is how do I merge a view where I can manage all of my DS from one view? I recall you saying the there will no longer be a java console, is there an alternative solution, such as an application, that will allow me to view all of my systems in a console (that is deprecated)?
Thanks,
Paul M. Whitney
paul.whitney(a)mac.com
Sent from my Mac Book Pro
3 years, 2 months
Password update fails to Windows Replica
by Mihai Carabas
Hello,
Yesterday I upgraded our Fedora from 29 to 30, implicitly 389ds. We have a
sync agreement with an Active Directory (2012R2).
From yesterday password synchronization from 389DS to AD is not working.
Any other attribute is updated. At [1] is a detailed log of the replication
when changing password for tmp_stud12. Any insight why this is happening?
Thank you,
Mihai
[1]
[30/Sep/2020:19:55:32.233009987 +0300] - DEBUG - _csngen_adjust_local_time
- gen state before 5f74b8640001:1601484900:0:0
[30/Sep/2020:19:55:32.236215746 +0300] - DEBUG - _csngen_adjust_local_time
- gen state after 5f74b8840000:1601484932:0:0
[30/Sep/2020:19:55:32.239259002 +0300] - DEBUG - NSMMReplicationPlugin -
ruv_add_csn_inprogress - Successfully inserted csn 5f74b884000000010000
into pending list
[30/Sep/2020:19:55:32.243457280 +0300] - DEBUG - NSMMReplicationPlugin -
purge_entry_state_information - From entry
uid=tmp_stud12,ou=SystemAccounts,ou=TCNIT,ou=People,dc=hidden,dc=my up to
CSN 5f6b7db1000000010000
[30/Sep/2020:19:55:32.258805964 +0300] - DEBUG - NSMMReplicationPlugin -
write_changelog_and_ruv - Writing change for
uid=tmp_stud12,ou=SystemAccounts,ou=TCNIT,ou=People,dc=hidden,dc=my
(uniqid: 2e5be882-7b1d11e4-a57dd2cd-46fac8b9, optype: 8) to changelog csn
5f74b884000000010000
[30/Sep/2020:19:55:32.262142425 +0300] - DEBUG - NSMMReplicationPlugin -
changelog program - _cl5GetDBFileByReplicaName - found DB object
0x7f178eb62ee0 for database
/var/lib/dirsrv/slapd-ldap/changelogdb/b7808382-fe0211e4-aa4dd2cd-46fac8b9_547f9354000000010000.db
[30/Sep/2020:19:55:32.265014578 +0300] - DEBUG - NSMMReplicationPlugin -
changelog program - cl5WriteOperationTxn - Successfully written entry with
csn (5f74b884000000010000)
[30/Sep/2020:19:55:32.267843731 +0300] - DEBUG - NSMMReplicationPlugin -
changelog program - _cl5GetDBFileByReplicaName - found DB object
0x7f178eb62ee0 for database
/var/lib/dirsrv/slapd-ldap/changelogdb/b7808382-fe0211e4-aa4dd2cd-46fac8b9_547f9354000000010000.db
[30/Sep/2020:19:55:32.270979889 +0300] - DEBUG - NSMMReplicationPlugin -
csnplCommitALL: committing all csns for csn 5f74b884000000010000
[30/Sep/2020:19:55:32.273990444 +0300] - DEBUG - NSMMReplicationPlugin -
csnplCommitALL: processing data csn 5f74b884000000010000
[30/Sep/2020:19:55:32.277450608 +0300] - DEBUG - NSMMReplicationPlugin -
ruv_update_ruv - Successfully committed csn 5f74b884000000010000
[30/Sep/2020:19:55:32.281341980 +0300] - DEBUG - NSMMReplicationPlugin -
ruv_update_ruv - Rolled up to csn 5f74b884000000010000
[30/Sep/2020:19:55:32.284517039 +0300] - DEBUG - replication -
multimaster_mmr_postop - error 0 for operation 561.
[30/Sep/2020:19:55:32.289124924 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - windows_inc_run - agmt="cn=ad.hidden.my" (ad:636): State:
wait_for_changes -> wait_for_changes
[30/Sep/2020:19:55:32.292220081 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - windows_inc_run - agmt="cn=ad.hidden.my" (ad:636): State:
wait_for_changes -> ready_to_acquire_replica
[30/Sep/2020:19:55:32.295262337 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - acquire_replica, supplier RUV:
[30/Sep/2020:19:55:32.298563398 +0300] - DEBUG - NSMMReplicationPlugin -
supplier: {replicageneration} 547f9354000000010000
[30/Sep/2020:19:55:32.301425351 +0300] - DEBUG - NSMMReplicationPlugin -
supplier: {replica 1 ldap://ldap.hidden.my:389} 547f9663000000010000
5f74b884000000010000 5f74b884
[30/Sep/2020:19:55:32.304966716 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - acquire_replica, consumer RUV:
[30/Sep/2020:19:55:32.308563283 +0300] - DEBUG - NSMMReplicationPlugin -
consumer: {replicageneration} 547f9354000000010000
[30/Sep/2020:19:55:32.312999165 +0300] - DEBUG - NSMMReplicationPlugin -
consumer: {replica 1 ldap://ldap.hidden.my:389} 547f9663000000010000
5f74b831000000010000 5f74b831
[30/Sep/2020:19:55:32.316179024 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - acquire_replica, supplier RUV is newer
[30/Sep/2020:19:55:32.319248380 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - windows_conn_cancel_linger - agmt="cn=ad.hidden.my"
(ad:636): Cancelling linger on the connection
[30/Sep/2020:19:55:32.322436639 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - windows_inc_run - windows_acquire_replica returned success
(101)
[30/Sep/2020:19:55:32.326057906 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - windows_inc_run - agmt="cn=ad.hidden.my" (ad:636): State:
ready_to_acquire_replica -> sending_updates
[30/Sep/2020:19:55:32.329492969 +0300] - DEBUG - csngen_adjust_time - gen
state before 5f74b8840002:1601484932:0:0
[30/Sep/2020:19:55:32.333250939 +0300] - DEBUG - NSMMReplicationPlugin -
changelog program - _cl5GetDBFile - found DB object 0x7f178eb62ee0 for
database
/var/lib/dirsrv/slapd-ldap/changelogdb/b7808382-fe0211e4-aa4dd2cd-46fac8b9_547f9354000000010000.db
[30/Sep/2020:19:55:32.337062609 +0300] - DEBUG - NSMMReplicationPlugin -
changelog program - _cl5PositionCursorForReplay - (agmt="cn=ad.hidden.my"
(ad:636)): Consumer RUV:
[30/Sep/2020:19:55:32.340427471 +0300] - DEBUG - NSMMReplicationPlugin -
agmt="cn=ad.hidden.my" (ad:636): {replicageneration} 547f9354000000010000
[30/Sep/2020:19:55:32.343486228 +0300] - DEBUG - NSMMReplicationPlugin -
agmt="cn=ad.hidden.my" (ad:636): {replica 1 ldap://ldap.hidden.my:389}
547f9663000000010000 5f74b831000000010000 5f74b831
[30/Sep/2020:19:55:32.346726488 +0300] - DEBUG - NSMMReplicationPlugin -
changelog program - _cl5PositionCursorForReplay - (agmt="cn=ad.hidden.my"
(ad:636)): Supplier RUV:
[30/Sep/2020:19:55:32.349737943 +0300] - DEBUG - NSMMReplicationPlugin -
agmt="cn=ad.hidden.my" (ad:636): {replicageneration} 547f9354000000010000
[30/Sep/2020:19:55:32.353373311 +0300] - DEBUG - NSMMReplicationPlugin -
agmt="cn=ad.hidden.my" (ad:636): {replica 1 ldap://ldap.hidden.my:389}
547f9663000000010000 5f74b884000000010000 5f74b884
[30/Sep/2020:19:55:32.356297165 +0300] - DEBUG - agmt="cn=ad.hidden.my"
(ad:636) - clcache_get_buffer - found thread private buffer cache
0x7f175aa3e000
[30/Sep/2020:19:55:32.359842730 +0300] - DEBUG - agmt="cn=ad.hidden.my"
(ad:636) - clcache_get_buffer - _pool is 0x7f178eb9cb50
_pool->pl_busy_lists is 0x7f175aae09c0 _pool->pl_busy_lists->bl_buffers is
0x7f175aa3e000
[30/Sep/2020:19:55:32.363000989 +0300] - DEBUG - agmt="cn=ad.hidden.my"
(ad:636) - clcache_initial_anchorcsn - agmt="cn=ad.hidden.my" (ad:636) -
(cscb 0 - state 0) - csnPrevMax () csnMax (5f74b884000000010000) csnBuf
(5f74b831000000010000) csnConsumerMax (5f74b831000000010000)
[30/Sep/2020:19:55:32.366373451 +0300] - DEBUG - clcache_initial_anchorcsn
- anchor is now: 5f74b831000000010000
[30/Sep/2020:19:55:32.370214922 +0300] - DEBUG - NSMMReplicationPlugin -
changelog program - agmt="cn=ad.hidden.my" (ad:636): CSN
5f74b831000000010000 found, position set for replay
[30/Sep/2020:19:55:32.374174595 +0300] - DEBUG - agmt="cn=ad.hidden.my"
(ad:636) - clcache_get_next_change - load=1 rec=1 csn=5f74b884000000010000
[30/Sep/2020:19:55:32.379123586 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - windows_replay_update - agmt="cn=ad.hidden.my" (ad:636)
-Looking at modify operation local
dn="uid=tmp_stud12,ou=SystemAccounts,ou=TCNIT,ou=People,dc=hidden,dc=my"
(ours,user,not group)
[30/Sep/2020:19:55:32.383780572 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - map_entry_dn_outbound - agmt="cn=ad.hidden.my" (ad:636) -
Looking for AD entry for DS
dn="uid=tmp_stud12,ou=SystemAccounts,ou=TCNIT,ou=People,dc=hidden,dc=my"
guid="2b8af7c84d7bc24f9afa7249765ba837"
[30/Sep/2020:19:55:32.387702345 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - windows_search_entry_ext - Calling windows entry search
request plugin
[30/Sep/2020:19:55:32.394396169 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - windows_search_entry_ext - Received 2 messages, 1 entries, 0
references
[30/Sep/2020:19:55:32.398307741 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - map_entry_dn_outbound - agmt="cn=ad.hidden.my" (ad:636) -
Return code 0 from search for AD entry
dn="<GUID=2b8af7c84d7bc24f9afa7249765ba837>" or dn="CN=tmp_stud12
TMP_STUD12 (76196),OU=SystemAccounts,OU=TCNIT,OU=People,dc=hidden,dc=my"
[30/Sep/2020:19:55:32.402116111 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - Windows_replay_update - agmt="cn=ad.hidden.my" (ad:636) -
Processing modify operation local
dn="uid=tmp_stud12,ou=SystemAccounts,ou=TCNIT,ou=People,dc=hidden,dc=my"
remote dn="<GUID=2b8af7c84d7bc24f9afa7249765ba837>"
[30/Sep/2020:19:55:32.405208768 +0300] - DEBUG - agmt="cn=ad.hidden.my"
(ad:636) - clcache_adjust_anchorcsn - agmt="cn=ad.hidden.my" (ad:636) -
(cscb 0 - state 1) - csnPrevMax (5f74b884000000010000) csnMax
(5f74b884000000010000) csnBuf (5f74b884000000010000) csnConsumerMax
(5f74b884000000010000)
[30/Sep/2020:19:55:32.408067021 +0300] - DEBUG - agmt="cn=ad.hidden.my"
(ad:636) - clcache_load_buffer - rc=-30988
[30/Sep/2020:19:55:32.411291281 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - send_updates - agmt="cn=ad.hidden.my" (ad:636): No more
updates to send (cl5GetNextOperationToReplay)
[30/Sep/2020:19:55:32.414409738 +0300] - DEBUG - agmt="cn=ad.hidden.my"
(ad:636) - clcache_return_buffer - session end: state=5 load=1 sent=1
skipped=0 skipped_new_rid=0 skipped_csn_gt_cons_maxcsn=0
skipped_up_to_date=0 skipped_csn_gt_ruv=0 skipped_csn_covered=0
[30/Sep/2020:19:55:32.417788201 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - send_dirsync_search - Calling dirsync search request plugin
[30/Sep/2020:19:55:32.420946359 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - send_dirsync_search - Sending dirsync search request
[30/Sep/2020:19:55:32.425493743 +0300] - DEBUG - replication -
copy_operation_parameters - replica is null.
[30/Sep/2020:19:55:32.437272261 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - windows_conn_start_linger - agmt="cn=ad.hidden.my" (ad:636):
Beginning linger on the connection
[30/Sep/2020:19:55:32.440276716 +0300] - DEBUG - NSMMReplicationPlugin -
windows sync - windows_inc_run - agmt="cn=ad.hidden.my" (ad:636): State:
sending_updates -> wait_for_changes
3 years, 2 months
Account Policy Plugin combined with user policy and "passwordexp: off" impossible?
by Eugen Lamers
We have the following scenario:
We use a "global" password policy at cn=config where a customer of ours defines:
passwordexp: on
passwordmaxage: 7776000
passwordwarning: 7344000
We provide as default configuration "passwordMustChage: on" to force a new user to chage the initial password. In this setup a user whose password expired, i.e. also after this user is created and needs to change its initial password, cannot login to the account, but he can change the password.
The customer now wants a setup which prevents a user whose password expired from changing the password. A plugin "Account Policy Plugin" can therefore be activated by the customer, which uses the following configuration:
dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
cn: config
alwaysrecordlogin: yes
stateAttrName: non_existent_attribute
altStateAttrName: passwordExpirationTime
specattrname: acctPolicySubentry
limitattrname: accountInactivityLimit
As a consequence, the initial password change does not work anymore, thus the customer must change to "passwordMustChange: off". This would probably be acceptable.
A problem is, however, that a user account which has its own user password policy with "passwordexp: off" and "passwordmustchange: off" is affected by the plugin in such a way that the attribute passwordExpirationTime of the user itself is evaluated and the attribute passwordexp of the user password policy is ignored. That means, a user password policy for special user accounts without password expiration cannot be used in combination with the Account Policy Plugin.
Can the plugin be configured to enable this possiblity or is there another way to achieve the desired behaviour?
3 years, 2 months
aci doubt
by Alberto Viana
Hey Guys,
Is it possible to restrict some users to read,search,compare just specific
attributes but still use objectclass=* as a filter?
My aci:
aci: (targetattr="uid || givenName || cn || sn || manager ||
mail")(targetfilter="(objectclass=*)")(version 3.0;aci "Access for app to
specific needed attributes";allow (read,compare,search)
groupdn="ldap:///cn=my-group";)
If I do a ldapsearch with this user (myuser is in the group my-group):
ldapsearch -b "dc=rnp,dc=local" -W -D "uid=myuser" uid=alberto.viana
Returns me the user alberto.viana and the attributes that acis allows
but if I do:
ldapsearch -b "dc=rnp,dc=local" -W -D "uid=myuser" objectclass=*
returns me nothing.
Thanks!!
Alberto Viana
3 years, 2 months
Clarification on passwordMaxSeqSets
by Bryan K. Walton
I'm looking at the RH documentation for passwordMaxSeqSets, found here:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
Their wording seems a little unclear, to me. The paragraph, before the
example states: "If you set the passwordMaxSeqSets parameter to a
value higher than 0, Directory Server rejects passwords with duplicate
monotonic sequences exceeding the length set in the parameter."
But, in their example, they list a password with two sequences of "XYZ".
And they say that setting the value to 2 would prevent that password.
But according to the paragraph before the example, shouldn't it be set
to 1?
I have passwordMaxSequence set to 3. Can somebody clarify how
passwordMaxSeqSets should be set to prevent any duplicate sequences?
Thanks,
Bryan
3 years, 2 months
Change of storage scheme
by Tornóci László
Hi,
I recently upgraded my system from RHEL7 to RHEL8, together with 389ds.
Apparently this has caused to upgrade the storage scheme of the user
passwords to PBKDF2_SHA256. Everything works fine except freeradius does
not support this storage scheme at the moment.
How can I downgrade the storage scheme in 389ds to something that is
supported by freeradius in such a way, that doesn't force my users to
change their passwords?
Thanks: Laszlo
3 years, 2 months
