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 months, 2 weeks
Crash with SEGV after compacting
by Niklas Schmatloch
Hi
My organisation is using a replicated 389-dirsrv. Lately, it has been crashing
each time after compacting.
It is replicable on our instances by lowering the compactdb-interval to
trigger the compacting:
dsconf -D "cn=Directory Manager" ldap://127.0.0.1 -w 'PASSWORD_HERE' backend config set --compactdb-interval 300
This is the log:
[03/Aug/2022:16:06:38.552781605 +0200] - NOTICE - checkpoint_threadmain - Compacting DB start: userRoot
[03/Aug/2022:16:06:38.752592692 +0200] - NOTICE - bdb_db_compact_one_db - compactdb: compact userRoot - 8 pages freed
[03/Aug/2022:16:06:44.172233009 +0200] - NOTICE - bdb_db_compact_one_db - compactdb: compact userRoot - 888 pages freed
[03/Aug/2022:16:06:44.179315345 +0200] - NOTICE - checkpoint_threadmain - Compacting DB start: changelog
[03/Aug/2022:16:13:18.020881527 +0200] - NOTICE - bdb_db_compact_one_db - compactdb: compact changelog - 458 pages freed
dirsrv(a)auth-alpha.service: Main process exited, code=killed, status=11/SEGV
dirsrv(a)auth-alpha.service: Failed with result 'signal'.
dirsrv(a)auth-alpha.service: Consumed 2d 6h 22min 1.122s CPU time.
The first steps are done very quickly, but the step before the 458 pages of the
retro-changelog are freed, takes several minutes. In this time the dirsrv writes
more than 10 G and reads more than 7 G (according to iotop).
After this line is printed the dirsrv crashes within seconds.
What I also noticed is, that even though it said it freed a lot of pages the
retro-changelog does not seem to change in size.
The file `/var/lib/dirsrv/slapd-auth-alpha/db/changelog/id2entry.db` is 7.2 G
before and after the compacting.
Debian 11.4
389-ds-base/stable,now 1.4.4.11-2 amd64
Does someone have an idea how to debug / fix this?
Thanks
8 months, 2 weeks
new dirsrv with RHEL9
by solarflow99
Hi, I am having a problem with a new dirsrv setup, getting a linux client
to authenticate with LDAP. I have done all the usual things to
troubleshoot, if anyone has seen this or knows what can be done I would
sure appreciate any help. Here's what i'm noticing:
- I need to have the bind_dn of Directory Manager specified to lookup
almost anything in LDAP, not sure why this is?
- sssd can find a sample user I created but still there seems to be a
problem, it looks like PAM but I did use authselect to use the sss profile:
$ *ldapsearch -x -LLL -D "cn=Directory Manager" -W -b ou=people,o=solarflow
-H ldap://dev2.local '(uid=john)' cn gidNumber userPassword*
Enter LDAP Password:
dn: uid=john,ou=people,o=solarflow
cn: John Smith
gidNumber: 10001
userPassword:: e1BCS0RGMixxxxxxx...xxx==
*$ sssctl domain-status ldap*
Online status: Online
Active servers:
LDAP: dev2.local
Discovered LDAP servers:
- dev2.local
localhost ~* $ sssctl user-checks john*
user: john
action: acct
service: system-auth
sss_getpwnam_r failed with [0].
User name lookup with [john] failed.
SSSD InfoPipe user lookup result:
- name: john
- uidNumber: 10001
- gidNumber: 10001
- gecos: John Smith
- homeDirectory: /home/john
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: User not known to the underlying authentication module
PAM Environment:
- no env -
localhost ~ *$ getent passwd john*
localhost ~ *$ id john*
id: ‘john’: no such user
*$ authselect current*
Profile ID: sssd
Enabled features:
- with-mkhomedir
- with-pamaccess
- with-sudo
*Here is my sssd.conf:*
[sssd]
config_file_version = 2
domains = LDAP
#services=pam
debug_level = 6
[domain/LDAP]
id_provider = ldap
auth_provider = ldap
#chpass_provider = ldap
ldap_uri = ldap://dev2.local
ldap_search_base = o=solarflow
ldap_default_bind_dn = cn=Directory Manager
ldap_default_authtok = my_secret_password
cache_credentials = True
debug_level = 6
9 months, 1 week
Unable to establish replication with STARTTLS
by John Thurston
I have two hosts with 389-Directory/1.4.4.17 B2021.280.1354 on CentOS
Stream release 8 (4.18.0-448.el8.x86_64)
On a.state.ak.us, there is one instance defined (call this instance #1)
On b.state.ak.us, there are two instances defined (call them #2 and #3)
Instances #1 and #3 have GlobalSign certificates installed. Instance #2
currently has a Let's Encrypt certificate installed. All instances also
have root and intermediate certs in their databases for GlobalSign,
which are marked with Trust Flags "CT,,".
I can define instance #2 as a supplier, and define a replication
agreement which populates #3. This works with both LDAPS and STARTTLS.
If I, instead, try to define the same replication agreement on instance
#1, it fails with:
> slapi_ldap_bind - Error: could not send startTLS request: error -11
> (Connect error)
>
> NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=DS11-1to3"
> (b:389) - Replication bind with SIMPLE auth failed: LDAP error -11
> (Connect error) (error:1416F086:SSL
> routines:tls_process_server_certificate:certificate verify failed
> (unable to get issuer certificate))
>
> slapi_ldap_bind - Error: could not send startTLS request: error -11
> (Connect error)
I am unable to figure out how instances #1 and #2 differ.
Instance #1 has long-established supplier-agreements (using both LDAPS
and STARTTLS) with other instances of 389-Directory. So I know instance
#1 can function correctly as a supplier. Instance #3 demonstrates it can
be a consumer when supplied by instance #2. I can perform LDAPS and
STARTTLS queries from a.state.ak.us to instance #3, so I know it is
listening on the network and not blocked by a host-based firewall.
Any suggestions of where to look, or config-attributes to check, would
be appreciated.
--
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
John.Thurston(a)alaska.gov
Department of Administration
State of Alaska
9 months, 3 weeks
Access to 389-ds in Cockpit without sudo to root
by Brian Mattey (UK)
Hi,
I would like to grant a non-privileged user (cannot sudo to root) access to 389-ds configuration in Cockpit. (I've googled a _lot_ for this and can't find any way to do it).
Thanks,
Brian
9 months, 3 weeks