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
—
4 months, 1 week
Lock table is out of available lock entries
by Kees Bakker
Hi,
When my dirsrv was trying to compact the databases I was getting this error
[07/Aug/2021:23:59:02.715984489 +0200] - NOTICE - bdb_compact - Compacting databases ...
[07/Aug/2021:23:59:02.765932397 +0200] - NOTICE - bdb_compact - Compacting DB start: userRoot
[07/Aug/2021:23:59:03.518175414 +0200] - NOTICE - bdb_compact - compactdb: compact userRoot - 417 pages freed
[07/Aug/2021:23:59:03.576427786 +0200] - NOTICE - bdb_compact - Compacting DB start: ipaca
[07/Aug/2021:23:59:03.659941533 +0200] - NOTICE - bdb_compact - compactdb: compact ipaca - 419 pages freed
[07/Aug/2021:23:59:03.718445310 +0200] - NOTICE - bdb_compact - Compacting DB start: changelog
[08/Aug/2021:00:00:40.807571334 +0200] - NOTICE - NSMMReplicationPlugin - changelog program - cl5CompactDBs - compacting replication changelogs...
[08/Aug/2021:00:00:54.309357211 +0200] - ERR - libdb - BDB2055 Lock table is out of available lock entries
[08/Aug/2021:00:00:54.726504736 +0200] - ERR - bdb_compact - compactdb: failed to compact changelog; db error - 12 Cannot allocate memory
[08/Aug/2021:00:00:54.801571421 +0200] - ERR - libdb - BDB2055 Lock table is out of available lock entries
[08/Aug/2021:00:00:54.876618702 +0200] - ERR - NSMMReplicationPlugin - changelog program - cl5CompactDBs - Failed to compact a797bb0b-be1d11eb-88c0b677-613aa2ad; db error - 12 Cannot allocate memory
[08/Aug/2021:00:00:57.253006449 +0200] - NOTICE - bdb_compact - Compacting databases finished.
There are about 402k entries in cn=changelog.
I have a few questions
1) is it normal to have so many entries in cn=changelog? On another replica I have almost 3M entries Isn't this cleaned up?
2) the number of locks is 50000 (there are two config items). Should I increase that number? If so, increase to what?
3) is there maybe something else going on, causing the exhaustion of the locks?
--
Kees Bakker
2 years, 6 months
passwordAdminDN help
by Morgan Jones
May I have a sanity check here? I am attempting to add pre-hashed passwords to users. If I’ve read the documentation correctly this should work. I’ve also tried putting uid=selectivesync389,ou=svc_accts,dc=domain,dc=org directly in passwordAdminDN:
morgan@woodrow-2 ~ % ldapsearch -H ldaps://tstds21.domain.org -x -w pass -D cn=directory\ manager -LLLb cn=config -s base objectclass=\* passwordAdminDN
dn: cn=config
passwordAdminDN: cn=Passwd Admins,ou=groups,dc=domain,dc=org
morgan@woodrow-2 ~ %
morgan@woodrow-2 ~ % ldapsearch -H ldaps://tstds21.domain.org -x -w pass -D cn=directory\ manager -LLLb dc=domain,dc=org cn=passwd\ admins
dn: cn=Passwd Admins,ou=groups,dc=domain,dc=org
description: password admins
objectClass: top
objectClass: groupofuniquenames
cn: Passwd Admins
uniqueMember: uid=selectivesync389,ou=svc_accts,dc=domain,dc=org
morgan@woodrow-2 ~ %
morgan@woodrow-2 ~ % ldapmodify -a -w pass -D uid=selectivesync389,ou=svc_accts,dc=domain,dc=org -H ldaps://tstds21.domain.org
dn: uid=zimbratest06,ou=employees,dc=domain,dc=org
changetype: modify
replace: userpassword
userpassword: {SHA}hrJ6x38+yn2LiTm1qqkGjNXAh8I=
modifying entry "uid=zimbratest06,ou=employees,dc=domain,dc=org"
ldap_modify: Constraint violation (19)
additional info: invalid password syntax - passwords with storage scheme are not allowed
morgan@woodrow-2 ~ %
We’re running 1.3.10 on CentOS 7.9:
[root@tstds21 morgan]# cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)
[root@tstds21 morgan]# rpm -qa|grep 389
389-adminutil-1.1.22-2.el7.x86_64
389-ds-base-1.3.10.2-10.el7_9.x86_64
389-ds-console-doc-1.2.16-1.el7.noarch
389-ds-base-libs-1.3.10.2-10.el7_9.x86_64
389-console-1.1.19-6.el7.noarch
389-ds-console-1.2.16-1.el7.noarch
389-dsgw-1.1.11-5.el7.x86_64
389-admin-console-1.1.12-1.el7.noarch
389-ds-1.2.2-6.el7.noarch
389-admin-console-doc-1.1.12-1.el7.noarch
389-admin-1.1.46-4.el7.x86_64
[root@tstds21 morgan]#
Am I missing something?? thank you!
-morgan
2 years, 6 months
DSIDM/TLS: certificate verify failed (unable to get local issuer certificate)
by Daniel
Hello, currently i am a bit stuck with getting 389- Server working and
would appreciate any help... I have followed
https://directory.fedoraproject.org/docs/389ds/howto/howto-ssl.html
and a guide to import certificates and keys from letsencrypt, which
seems to work accordingly.
but whenever i make a secure connection, i get the error above. i.e.
using dsidm:
obel1x:/ # dsidm -v ldaps://obel1x.de:636 -b 'dc=obel1x,dc=de' -D
'cn=Directory Manager' client_config sssd.conf server_admins
DEBUG: The 389 Directory Server Identity Manager
DEBUG: Inspired by works of: ITS, The University of Adelaide
DEBUG: dsrc path: /root/.dsrc
DEBUG: dsrc container path: /data/config/container.inf
DEBUG: dsrc instances: ['obel1x']
DEBUG: dsrc no such section: slapd-ldaps://obel1x.de:636
DEBUG: Called with: Namespace(allowed_group='server_admins',
basedn='dc=obel1x,dc=de', binddn='cn=Directory Manager', bindpw=None,
func=<function sssd_conf at 0x7fbd8cd3a6a8>,
instance='ldaps://obel1x.de:636', json=False, prompt=False,
pwdfile=None, starttls=False, verbose=True)
DEBUG: Instance details: {'uri': 'ldaps://obel1x.de:636', 'basedn':
'dc=obel1x,dc=de', 'binddn': 'cn=Directory Manager', 'bindpw': None,
'saslmech': None, 'tls_cacertdir': None, 'tls_cert': None, 'tls_key':
None, 'tls_reqcert': None, 'starttls': False, 'prompt': False,
'pwdfile': None, 'args': {'ldapurl': 'ldaps://obel1x.de:636', 'root-dn':
'cn=Directory Manager'}}
DEBUG: SER_SERVERID_PROP not provided, assuming non-local instance
DEBUG: Allocate <class 'lib389.DirSrv'> with ldaps://obel1x.de:636
DEBUG: Allocate <class 'lib389.DirSrv'> with obel1x:389
DEBUG: Allocate <class 'lib389.DirSrv'> with obel1x:389
Enter password for cn=Directory Manager on ldaps://obel1x.de:636:
DEBUG: SER_SERVERID_PROP not provided, assuming non-local instance
DEBUG: Allocate <class 'lib389.DirSrv'> with ldaps://obel1x.de:636
DEBUG: Allocate <class 'lib389.DirSrv'> with obel1x:389
DEBUG: Allocate <class 'lib389.DirSrv'> with obel1x:389
DEBUG: open(): Connecting to uri ldaps://obel1x.de:636
DEBUG: Using dirsrv ca certificate /etc/dirsrv/slapd-{instance_name}
DEBUG: Using external ca certificate /etc/dirsrv/slapd-{instance_name}
DEBUG: Using external ca certificate /etc/dirsrv/slapd-{instance_name}
DEBUG: Using /etc/openldap/ldap.conf certificate policy
DEBUG: ldap.OPT_X_TLS_REQUIRE_CERT = 2
DEBUG: Cannot connect to 'ldaps://obel1x.de:636'
DEBUG: {'desc': "Can't contact LDAP server", 'info': 'error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed
(unable to get local issuer certificate)'}
Traceback (most recent call last):
File "/usr/sbin/dsidm", line 129, in <module>
inst = connect_instance(dsrc_inst=dsrc_inst, verbose=args.verbose,
args=args)
File "/usr/lib/python3.6/site-packages/lib389/cli_base/__init__.py",
line 152, in connect_instance
starttls=dsrc_inst['starttls'], connOnly=True)
File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line
1074, in open
raise e
File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line
1070, in open
self.simple_bind_s(ensure_str(self.binddn), self.bindpw,
escapehatch='i am sure')
File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 175,
in inner
return f(*args, **kwargs)
File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line
443, in simple_bind_s
msgid = self.simple_bind(who,cred,serverctrls,clientctrls)
File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 175,
in inner
return f(*args, **kwargs)
File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line
437, in simple_bind
return
self._ldap_call(self._l.simple_bind,who,cred,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls))
File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 175,
in inner
return f(*args, **kwargs)
File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line
329, in _ldap_call
reraise(exc_type, exc_value, exc_traceback)
File "/usr/lib64/python3.6/site-packages/ldap/compat.py", line 44, in
reraise
raise exc_value
File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line
313, in _ldap_call
result = func(*args,**kwargs)
ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server", 'info':
'error:1416F086:SSL routines:tls_process_server_certificate:certificate
verify failed (unable to get local issuer certificate)'}
ERROR: Error: Can't contact LDAP server - error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed
(unable to get local issuer certificate)
This also affects sssd and ldapsearch of course.
Testing SSL looks ok for me
obel1x:~ #openssl s_client -connect obel1x.de:636 -showcerts </dev/null
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = obel1x.de
verify return:1
---
Certificate chain
0 s:CN = obel1x.de
i:C = US, O = Let's Encrypt, CN = R3
-----BEGIN CERTIFICATE-----
xxx
-----END CERTIFICATE-----
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
-----BEGIN CERTIFICATE-----
xxx
-----END CERTIFICATE-----
---
Server certificate
subject=CN = obel1x.de
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3107 bytes and written 375 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE
and the keystore is:
obel1x:/etc/dirsrv/slapd-obel1x #certutil -K -d .
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private
Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":
< 0> rsa 88a40a16c8cee80cda1804e08f3f87eea6f6a2ab Server-Cert
obel1x:/etc/dirsrv/slapd-obel1x #certutil -L -d .
Certificate Nickname Trust
Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u
ca_cert C,,
where Server-Cert corresponds to cert.pem and ca_cert is chain.pem in
letsencrypt.
I have only found a small difference in the docs, which do say the key
should read like:
|< 0> rsa 79187d744c73cd2f098edc80ce261e5ad94c4db2 NSS Certificate
DB:Server-Cert|
to define that the key matches the certificate. I have not found a way
to "bind" the key to the certificate or to link them, but the
certificate should the one of the key, as it has been derived from it
and was imported with pk12util in the database.
What can be is wrong with dsidm connecting - is it the key? why is
openssl not complaining then? and if so, how to import it the rigth way?
--
Mit freundlichen Grüßen,
Daniel
2 years, 6 months
Re: Password lockout policy max failure.
by Mark Reynolds
On 9/24/21 9:47 AM, Michael Starling wrote:
>
>
> ------------------------------------------------------------------------
> *From:* Mark Reynolds <mreynolds(a)redhat.com>
> *Sent:* Friday, September 24, 2021 9:38 AM
> *To:* General discussion list for the 389 Directory server project.
> <389-users(a)lists.fedoraproject.org>; Michael Starling
> <mlstarling31(a)hotmail.com>
> *Subject:* Re: [389-users] Password lockout policy max failure.
>
>
> On 9/24/21 9:23 AM, Michael Starling wrote:
>> Hello.
>>
>> I'm having an issue where we have passwordMaxFailure set to "5" in
>> the global policy but users are getting locked out after 3 attempts.
>
> This is because you have a mix of global and local policies. Local
> policies override the global policy.
>
> In the local policy you did NOT set passwordMaxFailure, so it uses the
> default of 3. If you don't need separate policies then just use the
> global policy for everything and remove he local policies.
>
>
> On a side note, if you are using dsconf on the same system as the
> directory server you can simplify the cli usage to use LDAPI, and it's
> much less to type:
>
>
> dsconf -W -D cn=manager ldaps://dsa101.mydomain.com:636 pwpolicy get
>
>
> This can become:
>
>
> # dsconf slapd-YOUR_INSTANCE_NAME pwpolicy get
>
You can even shorten this by removing the "slapd-" prefix:
# dsconf YOUR_INSTANCE_NAME pwpolicy get
It's just easier to explain this the first time by using the "slapi-",
but it's completely optional. So on my system my hostname and instance
name are localhost. So I use all the CLI tools like this:
# dsconf localhost pwpolicy get
>
> This only works if you run dsconf on the DS machine, and you need to
> run it as root. This works for all the CLI tools (dsidm, dsctl, and
> dsconf)
>
>
> HTH,
>
> Mark
>
>
> Once again, great information Mark.
>
> So essentially, I need to set passwordMaxFailure 5 in the local
> policy as well?
Correct, or remove the local policy (unless you need it).
Mark
>
> Thanks
>> Right now, when a user is locked out the only way I can tell is by
>> looking at the attributes below.
>> One is likely to assume that once the "accountUnlockTime" attribute
>> has been set on an account, the account is indeed locked out.
>> accountUnlockTime: 20210920190503Z *passwordRetryCount: 3
>> *retryCountResetTime: 20210920181413Z
>>
>>
>> [mstarling@dsa101 ~]$ dsconf -W -D cn=manager
>> ldaps://dsa101.mydomain.com:636 pwpolicy get
>> Global Password Policy: cn=config
>> ------------------------------------
>> nsslapd-pwpolicy-local: on
>> passwordstoragescheme: SSHA512
>> passwordchange: on
>> passwordmustchange: off
>> passwordhistory: on
>> passwordinhistory: 10
>> passwordadmindn:
>> cn=Generic_PasswordPolicy_Override,ou=LDAPadmin,dc=mydomain,dc=com
>> passwordtrackupdatetime: on
>> passwordwarning: 86400
>> passwordisglobalpolicy: on
>> passwordexp: on
>> passwordmaxage: 7776000
>> passwordminage: 86400
>> passwordgracelimit: 0
>> passwordsendexpiringtime: off
>> passwordlockout: on
>> passwordunlock: on
>> passwordlockoutduration: 600
>> *passwordmaxfailure: 5*
>> passwordresetfailurecount: 600
>> passwordchecksyntax: off
>> passwordminlength: 48
>> passwordmindigits: 0
>> passwordminalphas: 0
>> passwordminuppers: 0
>> passwordminlowers: 0
>> passwordminspecials: 0
>> passwordmin8bit: 0
>> passwordmaxrepeats: 0
>> passwordpalindrome: off
>> passwordmaxsequence: 0
>> passwordmaxseqsets: 0
>> passwordmaxclasschars: 0
>> passwordmincategories: 5
>> passwordmintokenlength: 3
>> passwordbadwords: athena health interface
>> passworduserattributes: cn uid sn givenName mail gecos homeDirectory
>> passworddictcheck: on
>> passworddictpath: /usr/lib64/security/pam_cracklib.so
>> nsslapd-allow-hashed-passwords: on
>> nsslapd-pwpolicy-inherit-global: on
>>
>>
>> dsconf -W -D cn=manager ldaps://dsa101.mydomain.com:636 localpwp get
>> "ou=People,dc=mydomain,dc=com"
>> Local Subtree Policy Policy for "ou=People,dc=mydomain,dc=com":
>> cn=cn\3DnsPwPolicyEntry_subtree\2Cou\3DPeople\2Cdc\3Dmydomain\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=mydomain,dc=com
>> ------------------------------------
>> passwordstoragescheme: SSHA512
>> passwordmustchange: off
>> passwordhistory: on
>> passwordtrackupdatetime: on
>> passwordexp: on
>> passwordmaxage: 7776000
>> passwordlockout: on
>> passwordchecksyntax: on
>> passwordminlength: 14
>> passwordmincategories: 4
>> passworddictcheck: on
>>
>> _______________________________________________
>> 389-users mailing list --389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>
>> To unsubscribe send an email to389-users-leave(a)lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org>
>> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
>> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines>
>> List Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fe... <https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...>
>> Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure <https://pagure.io/fedora-infrastructure>
> --
> Directory Server Development Team
--
Directory Server Development Team
2 years, 6 months
Re: Password lockout policy max failure.
by Mark Reynolds
On 9/24/21 9:23 AM, Michael Starling wrote:
> Hello.
>
> I'm having an issue where we have passwordMaxFailure set to "5" in the
> global policy but users are getting locked out after 3 attempts.
This is because you have a mix of global and local policies. Local
policies override the global policy.
In the local policy you did NOT set passwordMaxFailure, so it uses the
default of 3. If you don't need separate policies then just use the
global policy for everything and remove he local policies.
On a side note, if you are using dsconf on the same system as the
directory server you can simplify the cli usage to use LDAPI, and it's
much less to type:
dsconf -W -D cn=manager ldaps://dsa101.mydomain.com:636 pwpolicy get
This can become:
# dsconf slapd-YOUR_INSTANCE_NAME pwpolicy get
This only works if you run dsconf on the DS machine, and you need to run
it as root. This works for all the CLI tools (dsidm, dsctl, and dsconf)
HTH,
Mark
>
> Right now, when a user is locked out the only way I can tell is by
> looking at the attributes below.
> One is likely to assume that once the "accountUnlockTime" attribute
> has been set on an account, the account is indeed locked out.
> accountUnlockTime: 20210920190503Z *passwordRetryCount: 3
> *retryCountResetTime: 20210920181413Z
>
>
> [mstarling@dsa101 ~]$ dsconf -W -D cn=manager
> ldaps://dsa101.mydomain.com:636 pwpolicy get
> Global Password Policy: cn=config
> ------------------------------------
> nsslapd-pwpolicy-local: on
> passwordstoragescheme: SSHA512
> passwordchange: on
> passwordmustchange: off
> passwordhistory: on
> passwordinhistory: 10
> passwordadmindn:
> cn=Generic_PasswordPolicy_Override,ou=LDAPadmin,dc=mydomain,dc=com
> passwordtrackupdatetime: on
> passwordwarning: 86400
> passwordisglobalpolicy: on
> passwordexp: on
> passwordmaxage: 7776000
> passwordminage: 86400
> passwordgracelimit: 0
> passwordsendexpiringtime: off
> passwordlockout: on
> passwordunlock: on
> passwordlockoutduration: 600
> *passwordmaxfailure: 5*
> passwordresetfailurecount: 600
> passwordchecksyntax: off
> passwordminlength: 48
> passwordmindigits: 0
> passwordminalphas: 0
> passwordminuppers: 0
> passwordminlowers: 0
> passwordminspecials: 0
> passwordmin8bit: 0
> passwordmaxrepeats: 0
> passwordpalindrome: off
> passwordmaxsequence: 0
> passwordmaxseqsets: 0
> passwordmaxclasschars: 0
> passwordmincategories: 5
> passwordmintokenlength: 3
> passwordbadwords: athena health interface
> passworduserattributes: cn uid sn givenName mail gecos homeDirectory
> passworddictcheck: on
> passworddictpath: /usr/lib64/security/pam_cracklib.so
> nsslapd-allow-hashed-passwords: on
> nsslapd-pwpolicy-inherit-global: on
>
>
> dsconf -W -D cn=manager ldaps://dsa101.mydomain.com:636 localpwp get
> "ou=People,dc=mydomain,dc=com"
> Local Subtree Policy Policy for "ou=People,dc=mydomain,dc=com":
> cn=cn\3DnsPwPolicyEntry_subtree\2Cou\3DPeople\2Cdc\3Dmydomain\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=mydomain,dc=com
> ------------------------------------
> passwordstoragescheme: SSHA512
> passwordmustchange: off
> passwordhistory: on
> passwordtrackupdatetime: on
> passwordexp: on
> passwordmaxage: 7776000
> passwordlockout: on
> passwordchecksyntax: on
> passwordminlength: 14
> passwordmincategories: 4
> passworddictcheck: on
>
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
Directory Server Development Team
2 years, 6 months
Password lockout policy max failure.
by Michael Starling
Hello.
I'm having an issue where we have passwordMaxFailure set to "5" in the global policy but users are getting locked out after 3 attempts.
Right now, when a user is locked out the only way I can tell is by looking at the attributes below.
One is likely to assume that once the "accountUnlockTime" attribute has been set on an account, the account is indeed locked out.
accountUnlockTime: 20210920190503Z
passwordRetryCount: 3
retryCountResetTime: 20210920181413Z
[mstarling@dsa101 ~]$ dsconf -W -D cn=manager ldaps://dsa101.mydomain.com:636 pwpolicy get
Global Password Policy: cn=config
------------------------------------
nsslapd-pwpolicy-local: on
passwordstoragescheme: SSHA512
passwordchange: on
passwordmustchange: off
passwordhistory: on
passwordinhistory: 10
passwordadmindn: cn=Generic_PasswordPolicy_Override,ou=LDAPadmin,dc=mydomain,dc=com
passwordtrackupdatetime: on
passwordwarning: 86400
passwordisglobalpolicy: on
passwordexp: on
passwordmaxage: 7776000
passwordminage: 86400
passwordgracelimit: 0
passwordsendexpiringtime: off
passwordlockout: on
passwordunlock: on
passwordlockoutduration: 600
passwordmaxfailure: 5
passwordresetfailurecount: 600
passwordchecksyntax: off
passwordminlength: 48
passwordmindigits: 0
passwordminalphas: 0
passwordminuppers: 0
passwordminlowers: 0
passwordminspecials: 0
passwordmin8bit: 0
passwordmaxrepeats: 0
passwordpalindrome: off
passwordmaxsequence: 0
passwordmaxseqsets: 0
passwordmaxclasschars: 0
passwordmincategories: 5
passwordmintokenlength: 3
passwordbadwords: athena health interface
passworduserattributes: cn uid sn givenName mail gecos homeDirectory
passworddictcheck: on
passworddictpath: /usr/lib64/security/pam_cracklib.so
nsslapd-allow-hashed-passwords: on
nsslapd-pwpolicy-inherit-global: on
dsconf -W -D cn=manager ldaps://dsa101.mydomain.com:636 localpwp get "ou=People,dc=mydomain,dc=com"
Local Subtree Policy Policy for "ou=People,dc=mydomain,dc=com": cn=cn\3DnsPwPolicyEntry_subtree\2Cou\3DPeople\2Cdc\3Dmydomain\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=mydomain,dc=com
------------------------------------
passwordstoragescheme: SSHA512
passwordmustchange: off
passwordhistory: on
passwordtrackupdatetime: on
passwordexp: on
passwordmaxage: 7776000
passwordlockout: on
passwordchecksyntax: on
passwordminlength: 14
passwordmincategories: 4
passworddictcheck: on
2 years, 6 months
Re: dsidm utility inconsistencies
by Mark Reynolds
On 9/23/21 11:59 AM, Michael Starling wrote:
>
>
> ------------------------------------------------------------------------
> *From:* Michael Starling <mlstarling31(a)hotmail.com>
> *Sent:* Thursday, September 23, 2021 10:10 AM
> *To:* Mark Reynolds <mreynolds(a)redhat.com>; General discussion list
> for the 389 Directory server project. <389-users(a)lists.fedoraproject.org>
> *Subject:* Re: [389-users] dsidm utility inconsistencies
>
>
> ------------------------------------------------------------------------
> *From:* Mark Reynolds <mreynolds(a)redhat.com>
> *Sent:* Wednesday, September 22, 2021 8:14 PM
> *To:* Michael Starling <mlstarling31(a)hotmail.com>; General discussion
> list for the 389 Directory server project.
> <389-users(a)lists.fedoraproject.org>
> *Subject:* Re: [389-users] dsidm utility inconsistencies
>
>
> On 9/22/21 5:11 PM, Michael Starling wrote:
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Mark Reynolds <mreynolds(a)redhat.com>
>> <mailto:mreynolds@redhat.com>
>> *Sent:* Wednesday, September 22, 2021 3:38 PM
>> *To:* General discussion list for the 389 Directory server project.
>> <389-users(a)lists.fedoraproject.org>
>> <mailto:389-users@lists.fedoraproject.org>; Michael Starling
>> <mlstarling31(a)hotmail.com> <mailto:mlstarling31@hotmail.com>
>> *Subject:* Re: [389-users] dsidm utility inconsistencies
>>
>>
>> On 9/22/21 2:58 PM, Michael Starling wrote:
>>>
>>> Unless I'm interpreting the man pages, and documentation wrong there
>>> seems to be some issues with the dsidm utility. Perhaps I'm doing
>>> something wrong?
>>>
>>>
>>> This works.
>>>
>>>
>>> dsidm -W -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
>>> dc=mydomain,dc=com account get-by-dn
>>> uid=mstarlingt,ou=People,dc=mydomain,dc=com
>>>
>>> dn: uid=mstarlingt,ou=People,dc=mydomain,dc=com
>>>
>>> cn: Mike Starling
>>>
>>> gecos: Mike Starling test account
>>>
>>> gidNumber: 100
>>>
>>> givenName: Mike
>>>
>>> homeDirectory: /home/mstarlingt
>>>
>>> loginShell: /bin/ksh
>>>
>>> mail: mstarling(a)mydomain.com <mailto:mstarling@mydomain.com>
>>>
>>> objectClass: person
>>>
>>> objectClass: organizationalPerson
>>>
>>> objectClass: inetOrgPerson
>>>
>>> objectClass: posixAccount
>>>
>>> objectClass: top
>>>
>>> objectClass: shadowAccount
>>>
>>> shadowExpire: 99999
>>>
>>> shadowLastChange: 18857
>>>
>>> shadowMax: 33
>>>
>>> shadowWarning: 1
>>>
>>> sn: Starling
>>>
>>> uid: mstarlingt
>>>
>>> uidNumber: 25574
>>>
>>>
>>> #Password reset works
>>>
>>>
>>> dsidm -W -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
>>> dc=mydomain,dc=com account reset_password
>>> "uid=mstarlingt,ou=People,dc=mydomain,dc=com"
>>>
>>> Enter new password for uid=mstarlingt,ou=People,dc=mydomain,dc=com :
>>>
>>> CONFIRM - Enter new password for
>>> uid=mstarlingt,ou=People,dc=mydomain,dc=com :
>>>
>>> reset password for uid=mstarlingt,ou=People,dc=mydomain,dc=com
>>>
>>>
>>>
>>> #Unable to lock the account.
>>>
>>>
>>> dsidm -W -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
>>> dc=mydomain,dc=com account lock uid=mstarlingt
>>>
>>> *Error: No such object *
>>>
>>> *
>>> *
>>>
>>> *I consult the help which says to specify the dn*
>>>
>>> *
>>> *
>>>
>>> dsidm -W -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
>>> dc=mydomain,dc=com account lock -h
>>>
>>> usage: dsidm instance account lock [-h] [dn]
>>>
>>> positional arguments:
>>>
>>> dnThe dn to lock
>>>
>>> optional arguments:
>>>
>>> -h, --helpshow this help message and exit
>>>
>>>
>>> dsidm -W -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
>>> dc=mydomain,dc=com account lock
>>> uid=mstarlingt,ou=People,dc=mydomain,dc=com
>>>
>>> Error: search_ext() argument 1 must be str, not None
>>>
>> I think this is a known bug (which was fixed). What version of
>> python-lib389 is installed?
>>
>>
>> Thanks Mark.
>>
>>
>> python3-lib389-1.4.3.17-1.module_el8+10764+2b5f8656.noarch is installed
> Yes this is a old version, and the fix (Issue 4912) was recently
> made. We will have to do new builds...
>>>
>>>
>>> dsidm -W -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
>>> dc=mydomain,dc=com account lock
>>> "uid=mstarlingt,ou=People,dc=mydomain,dc=com"
>>>
>>> Error: search_ext() argument 1 must be str, not None
>>>
>>>
>>> dsidm -W -D cn=manager -Z ldaps://labdsa101.athenahealth.com -b
>>> dc=mydomain,dc=com account lock "uid=mstarlingt"
>>>
>>>
>>> I tried changing the base to the People OU where the account lives
>>>
>>>
>>> dsidm -W -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
>>> ou=People,dc=mydomain,dc=com account lock
>>> "uid=mstarlingt,ou=People,dc=mydomain,dc=com"
>>>
>>> Error: search_ext() argument 1 must be str, not None
>>>
>>>
>>> dsidm -W -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
>>> dc=mydomain,dc=com user get
>>>
>>> Enter uid to retrieve : mstarlingt
>>>
>>> Error: No object exists given the filter criteria mstarlingt
>>>
>> What is in the access log?
>>
>>
>>
>> Here's what I see in the logs.
>>
>>
>> 22/Sep/2021:17:09:28.515626170 -0400] conn=3947 op=2 SRCH
>> base="ou=people,dc=mydomain,dc=com" scope=2
>> filter="(&(&(objectClass=nsPerson)(objectClass=nsAccount)(objectClass=nsOrgPerson)(objectClass=posixAccount))(|(uid=mstarlingt)(displayName=mstarlingt)(cn=mstarlingt)))"
>> attrs="distinguishedName"
>
> So dsidm is pretty opinionated about how it looks for users (which
> might need to change). It only looks for entries that have all of
> these objectclasses: nsPerson, nsAccount, nsOrgPerson, posixAccount.
> What objectclasses are in your user entry?
>
>
> Mark
>
>
> Ahh. That's it. The mstarlingt account was created with an LDIF and
> does not have the "ns" object classes.
>
>
> I notice when I go to create an account with dsidm I have limited
> ability to specify attributes.
>
>
> Is the best way to create an account still with an LDIF file? When I
> create an account with dsidm it has no loginShell. Is there a default
> template dsidm pulls from that needs to be updated with the other
> possible user attributes that are set as the default and not covered
> by the dsidm utility?
>
>
> dsidm -W -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
> dc=mydomain,dc=com user create --uid="dstest" --cn="Test dsidm"
> --gidNumber="100" --homeDirectory="/home/dstest" --displayName="Test
> Account" --uidnumber="25941" --mail="mstarling(a)mydomain.com"
> --loginShell="/bin/bash"
>
> usage: dsidm [-h] [-b BASEDN] [-v] [-D BINDDN] [-w BINDPW] [-W] [-W
> PWDFILE]
>
> [-Z] [-j]
>
> instance
>
> {account,group,initialise,organizationalunit,posixgroup,user,client_config,role}
>
>
> ...
>
> dsidm: error: unrecognized arguments: --uidnumber=25941
> --mail=mstarling(a)mydomain.com --loginShell=/bin/bash
>
>
> dsidm -W -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
> dc=mydomain,dc=com user create -h
>
> usage: dsidm instance user create [-h] [--uid [UID]] [--cn [CN]]
>
> [--displayName [DISPLAYNAME]]
>
> [--uidNumber [UIDNUMBER]]
>
> [--gidNumber [GIDNUMBER]]
>
> [--homeDirectory [HOMEDIRECTORY]]
>
> optional arguments:
>
> -h, --helpshow this help message and exit
>
> --uid [UID]Value of uid
>
> --cn [CN]Value of cn
>
> --displayName [DISPLAYNAME]
>
> Value of displayName
>
> --uidNumber [UIDNUMBER]
>
> Value of uidNumber
>
> --gidNumber [GIDNUMBER]
>
> Value of gidNumber
>
> --homeDirectory [HOMEDIRECTORY]
>
> Value of homeDirectory
>
You used the wrong argument (--uidnumber), it is case sensitive, and the
usage says to use "--uidNumber".
As for setting other attributes, dsidm can do it - after the entry is
created. Please see:
dsidm -b o=mark localhost user modify --help
So you just can't set those custom attributes at creation time :-/ But
I think that sounds like a good RFE for dsidm, something like:
--attr="attr:value"
>
>
> So if I create a user with dsidm and it adds the "ns" object classes I
> still can't run some of the dsidm commands against that account
>
>
> dsidm -W -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
> dc=mydomain,dc=com user get dstest
>
> dn: uid=dstest,ou=People,dc=mydomain,dc=com
>
> cn: Test Dsconf
>
> displayName: Test Account
>
> employeeNumber: 25429
>
> gidNumber: 100
>
> homeDirectory: /home/dstest
>
> loginShell: /bin/bash
>
> mail: mstarling(a)mydomain.com
>
> objectClass: top
>
> objectClass: nsPerson
>
> objectClass: nsAccount
>
> objectClass: nsOrgPerson
>
> objectClass: posixAccount
>
> uid: dstest
>
> uidNumber: 25941
>
> dsidm -W -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
> dc=mydomain,dc=com account lock dstest
>
> Error: dstest is not a valid DN
>
This is expected since you did not provide a DN
>
>
> dsidm -W -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
> dc=mydomain,dc=com account lock uid=dstest,ou=People,dc=mydomain,dc=com
>
> Error: search_ext() argument 1 must be str, not None
>
Right, like I said, this is known bug that was recently fixed, so new
builds need to done to pick that fix up. I'm not sure what platform you
are on, I know it takes time for our builds to land in other distros
like centOS, etc.
Mark
>
> dsidm -W .slaplab -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
> dc=mydomain,dc=com account entry-status
> uid=dstest,ou=People,dc=mydomain,dc=com
>
> Error: search_ext() argument 1 must be str, not None
>
>
> dsidm -W .slaplab -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
> dc=mydomain,dc=com account entry-status dstest
>
> Error: dstest is not a valid DN
>
>
> dsidm -W .slaplab -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
> dc=mydomain,dc=com account entry-status
>
> Enter dn to check : uid=dstest,ou=People,dc=mydomain,dc=com
>
> Error: search_ext() argument 1 must be str, not None
>
>
>> Thanks,
>>
>> Mark
>>
>>>
>>> dsidm -W -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
>>> dc=mydomain,dc=com user get
>>>
>>> Enter uid to retrieve : uid=mstarlingt,ou=People,dc=mydomain,dc=com
>>>
>>> Error: No object exists given the filter criteria
>>> uid=mstarlingt,ou=People,dc=mydomain,dc=com
>>>
>>>
>>> dsidm -W -D cn=manager -Z ldaps://labdsa101.mydomain.com -b
>>> dc=mydomain,dc=com user get
>>>
>>> Enter uid to retrieve : uid=mstarlingt
>>>
>>> Error: No object exists given the filter criteria uid=mstarlingt
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 389-users mailing list --389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>
>>> To unsubscribe send an email to389-users-leave(a)lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org>
>>> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
>>> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines>
>>> List Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fe... <https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...>
>>> Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure <https://pagure.io/fedora-infrastructure>
>> --
>> Directory Server Development Team
> --
> Directory Server Development Team
--
Directory Server Development Team
2 years, 6 months
Insufficient Access Rights
by Xinhuan Zheng
I set up Self Service Password Tool. https://ltb-project.org/documentation/self-service-password. I configured a bind DN for password reset.
$ldap_binddn = "cn=proxyagent,ou=profile,dc=mycompany,dc=com";
$ldap_bindpw = "mypassword";
I'm getting "Password was refused by the LDAP directory (Insufficient access rights )" error when resetting a user's password. If I change the $ldap_binddn to "Directory Manager", it works.
I then added the "cn=proxyagent,ou=profile,dc=mycompany,dc=com" to "PD Managers" group with ACI:
ldapsearch -x -LLL -H ldap://server.mycompany.com:389 -s base -b 'ou=People,dc=mycompany,dc=com' aci
dn: ou=People,dc=mycompnay,dc=com
aci: (targetattr=*")(targetfilter ="(ou=People)")(version 3.0;acl "Engineering
Group Permissions";allow (write)(groupdn = "ldap:///cn=PD Managers,ou=groups
,dc=mycompany,dc=com");)
ldapsearch -x -LLL -H ldap://server.mycompnay.com:389 -s base -b 'cn=PD Managers,ou=Groups,dc=mycompany,dc=com' uniquemember
dn: cn=PD Managers,ou=Groups,dc=mycompany,dc=com
uniquemember: cn=Directory Manager
uniquemember: cn=proxyagent,ou=profile,dc=mycompany,dc=com
The "PD Managers" group has ACI to allow write for ou=People for all attributes. The proxyagent is member of the group. Why binding proxyagent results in "Insufficient Access Right"?
2 years, 6 months
