Q: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
by Ulrich Windl
Hi!
After systemd tearing down one of our LDAP servers I noticed the following message when the server was restarted:
slapd[10525]: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
The next line logged was:
slapd[10525]: olcServerID: value #1: SID=0x002 (listener=ldap://...:389)
(the server is that of SLES12 SP4, 2.4.41 from opensuse-buildservice)
The server is one of three MM servers that all have the same configuration and the same version.
The schema knows in olcAttributeTypes (olcSchemaConfig):
( 1.3.6.1.4.1.4203.666.11.5.1.30 NAME 'auditContext' DESC 'DN of auditContainer' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
What I'l like to know: Is there any thing I could fix in the configuration to make the message go away, or is it some software issue in slapd?
Regards,
Ulrich
2 years, 8 months
Question about OpenLDAP and rwm overlay
by Vandenburgh, Steve Y
I'm attempting to use OpenLDAP as a proxy to an Active Directory domain. Using the ldap backend, I'm able to configure the proxy and that configuration seems to be working well. But account entries are frequently moved from ou to ou in a domain and Microsoft permits the bind DN to be a userPrincipalName attribute value of the entry instead of the full DN of the account; this features avoids having to make many bind DN application configuration changes.
With just the ldap backend configured, OpenLDAP rejects the userPrincipalName (UPN) bind DN as an invalid DN. To work around this error, I was trying to see if I could use the rwm overlay to detect the UPN and convert to the actual domain entry DN using an attribute map. If I use the form
mail=UPN
the map works as expected; however, if I only provide the UPN as the bind DN, OpenLDAP still rejects it as an invalid DN. I suspect that the rwm overlay manipulations to not take effect until after the bind DN syntax is checked. I wanted to confirm my suspicion and see if any one else has been able to get a UPN-based bind to work through OpenLDAP.
For reference my slapd.conf configuration is below:
### Schema includes ###########################################################
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
## Module paths ##############################################################
modulepath /usr/lib64/openldap/
moduleload rwm
# Main settings ###############################################################
loglevel 8
sizelimit unlimited
idletimeout 600
writetimeout 30
allow bind_v2
pidfile /var/openldap/mycompany/var/slapd.pid
argsfile /var/openldap/mycompany/var/slapd.args
logfile /var/openldap/mycompany/logs/access
TLSCertificateFile /var/openldap/mycompany/certs/Server.pem
TLSCertificateKeyFile /var/openldap/mycompany/certs/Server.key
TLSCACertificateFile /var/openldap/mycompany/certs/ServerCA.pem
### Rewrite rules #############################################################
# Bind with UPN instead of full DN: we first need
# an ldap map that turns attributes into a DN (the
# argument used when invoking the map is appended to
# the URI and acts as the filter portion)
overlay rwm
rwm-suffixMassage "" "dc=mycompany,dc=com"
rwm-rewriteMap ldap attr2dn "ldaps://mycompany.com/ou=Domain%20Users,dc=mycompany,dc=com?dn?sub" bindwhen=now version=3 binddn="CN=mybindacct,ou=Domain Users,DC=mycompany,DC=com" credentials=******
# Then we need to detect UPN DN
# note that the rule in case of match stops rewriting
# In case we are mapping virtual
# to real naming contexts, we also need to rewrite
# regular DNs, because the definition of a bindDN
# rewrite context overrides the default definition.
rwm-rewriteContext bindDN
rwm-rewriteRule "^[^=,]+(a)mycompany.com$" "mail=$0" ":"
rwm-rewriteRule "^mail=[^,]+(a)mycompany.com$" "${attr2dn($0)}" ":@"
### Database definition (Proxy to AD) #########################################
database ldap
readonly yes
protocol-version 3
rebind-as-user
uri "ldaps://mycompany.com"
suffix "dc=mycompany,dc=com"
Thanks,
Steve Vandenburgh
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
3 years, 2 months
syncprov overlay and autogroup
by Martin Pittamitz
Good day
I have recently added a syncprov configuration and consumer node to our
OpenLDAP setup. On our master we use the overlays "memberOf" and
"autogroup".
Now a specific error occurs on the consumer node, where "group1" has
objectClass "groupOfURLs":
> Oct 29 16:39:18 user slapd[26309]: autogroup_modify_entry attempted to
> modify group's <cn=group1,ou=groups,dc=example,dc=net> member attribute
> Oct 29 16:39:18 user slapd[26309]: send_ldap_result: conn=-1 op=0 p=3
> Oct 29 16:39:18 user slapd[26309]: send_ldap_result: err=19 matched=""
> text="attempt to modify dynamic group member attribute"
> Oct 29 16:39:18 user slapd[26309]: syncrepl_null_callback : error code
> 0x13
> Oct 29 16:39:18 user slapd[26309]: syncrepl_entry: rid=001 be_modify
> cn=group1,ou=groups,dc=example,dc=net (19)
> Oct 29 16:39:18 user slapd[26309]: syncrepl_entry: rid=001 be_modify
> failed (19)
> Oct 29 16:39:18 user slapd[26309]: do_syncrepl: rid=001 rc 19 quitting
Can anyone point me in the right direction here? Is autogroup simply
incompatible with such a syncprov setup?
Best regards,
Martin
3 years, 4 months
Garbled objectClass
by Saša-Stjepan Bakša
Is there any good reason that I see one of my custom objectClass garbled
like this below. It happens when I am reading content from file. From GUI
tool it looks as it should.
olcObjectClasses:: ezZ9KCAxLjMuNi4xLjQuMS4zNTI2OS4zLjI0NS4yLjcgTkFNRSAncGNyZ
lBhY2thZ2UnIERFU0MgJ0NvbW1vbiBwYWNrYWdlIGRlc2NyaXB0aW9uIOKAkyBzZXJ2aWNlIHBh
cmFtZXRlcnMgZGVmaW5lZCBieSBNTk8nIFNVUCB0b3AgU1RSVUNUVVJBTCBNVVNUICggcGNyZlB
hY2thZ2VUaXRsZSAkIHBhY2thZ2VMaWZldGltZVR5cGUgKSBNQVkgKCBwYWNrYWdlQWN0aXZhdG
lvbkRhdGUgJCBwYWNrYWdlRXhwaXJ5RGF0ZSAkIHBhY2thZ2VDeWNsZSAkIHRvdGFsTWF4aW11b
VZvbHVtZSAkIHRvdGFsTWF4aW11bVRpbWUgJCBtb25pdG9yaW5nS2V5ICQgdG90YWxNYXhpbXVt
QW1vdW50ICQgY3ljbGVNdWx0aXBsaWVyICkgKQ==
Others are normal and human readable.
3 years, 5 months
Antw: Garbled objectClass
by Ulrich Windl
>>> Ulrich Windl schrieb am 24.10.2019 um 08:12 in Nachricht <5DB140BA.E78 :
161 :
60728>:
>>>> Saša-Stjepan Bakša <ssbaksa(a)gmail.com> schrieb am 23.10.2019 um 16:52
in
> Nachricht
> <CANk+c=2QFqT8uNdJDTdv_A_1j-r4H5+w3k+j1XdVhX9iZ3SVXA(a)mail.gmail.com>:
> > Is there any good reason that I see one of my custom objectClass garbled
> > like this below. It happens when I am reading content from file. From GUI
> > tool it looks as it should.
> >
> > olcObjectClasses::
ezZ9KCAxLjMuNi4xLjQuMS4zNTI2OS4zLjI0NS4yLjcgTkFNRSAncGNyZ
> >
lBhY2thZ2UnIERFU0MgJ0NvbW1vbiBwYWNrYWdlIGRlc2NyaXB0aW9uIOKAkyBzZXJ2aWNlIHBh
> >
cmFtZXRlcnMgZGVmaW5lZCBieSBNTk8nIFNVUCB0b3AgU1RSVUNUVVJBTCBNVVNUICggcGNyZlB
> >
hY2thZ2VUaXRsZSAkIHBhY2thZ2VMaWZldGltZVR5cGUgKSBNQVkgKCBwYWNrYWdlQWN0aXZhdG
> >
lvbkRhdGUgJCBwYWNrYWdlRXhwaXJ5RGF0ZSAkIHBhY2thZ2VDeWNsZSAkIHRvdGFsTWF4aW11b
> >
VZvbHVtZSAkIHRvdGFsTWF4aW11bVRpbWUgJCBtb25pdG9yaW5nS2V5ICQgdG90YWxNYXhpbXVt
> > QW1vdW50ICQgY3ljbGVNdWx0aXBsaWVyICkgKQ==
> >
> > Others are normal and human readable.
>
> That BASE64 says:
> {6}( 1.3.6.1.4.1.35269.3.245.2.7 NAME 'pcrbase64: invalid input
Sorry, that was due to indent of BASE64. It says:
{6}( 1.3.6.1.4.1.35269.3.245.2.7 NAME 'pcrfPackage' DESC 'Common package
description – service parameters defined by MNO' SUP top STRUCTURAL MUST (
pcrfPackageTitle $ packageLifetimeType ) MAY ( packageActivationDate $
packageExpiryDate $ packageCycle $ totalMaximumVolume $ totalMaximumTime $
monitoringKey $ totalMaximumAmount $ cycleMultiplier ) )
>
>
3 years, 5 months
LDAP loadbalancer with URL redirect
by Olivier -
Hi,
I have two different LDAP ldap://ldap1 and ldap://ldap2 behind a same public IP 10.0.0.1
Is there a solution to make a reverse proxy with redirection ?
I mean if a LDAP request arrive to 10.0.0.1 with URI target "ldap://ldap1" , the request is redirected to server ldap1.
Thanks.
3 years, 5 months
Retrieve deleted user accounts
by Michael Starling
Is there any OpenLDAP control equivalent to the Microsoft's >> LDAP_SERVER_SHOW_DELETED_OID = "1.2.840.113556.1.4.417" ?
I would like to pull a list of user accounts that have been deleted along with the corresponding date/time.
Mike
3 years, 5 months
TLS Connectivity
by Howard.Gillison＠gvltec.edu
Good morning to you,
I have a question regarding the user of LDAP_* calls while programming in C. I am on an Oracle/Sun Solaris machine running Solaris 11.3. I am writing my code via Oracle Solaris Studio version 12.4. I do have OpenLdap v2.4.30 installed on my machine. ( /user/lib/slapd -VV returns: @(#) $OpenLDAP: slapd 2.4.30 (Feb 9 2017 12:37:50) $
@ul11sru-build:/builds/ul11u3sru-gate/components/openldap/build/sparcv7/servers/slapd)
NOTE: the services are NOT up and running. I have no ldap server running on this machine. I am simply writing code using the LDAP_* service calls.
In previous releases, there were some calls available to the effect of LDAP_START_TLS or LDAP_START_SSL and some others. All of those calls are now gone and as far as I can tell, not available in any form.
With that said, my current code runs correctly and executes if I use port 389 to talk to an Active Directory Server. There is no problem, and I get back a valid response from my code, and I have gone through a pretty substantial set of testing to verify that the code is indeed accurate and valid. I even raided a site that had a sample code set for a bind and copied/modified that and tested it as well. My code and my raided code work correctly.
If, however, I change the default port to be port 636, the code fails when I attempt to bind via LDAP_SIMPLE_BIND_S. The specific error code returned to me is an Error Code 91 and the LDAP_ERR2STRING result is: "Can't connect to the LDAP server". The Error Code implies that the system is down - OR - it is not available. If I change the default port back to 389, the code works. My conclusion is that I am having difficulty with the remote Active Directory Server "trusting" my server.
I have OpenSSL on my machine, and I have the Private Certificate from the remote Active Directory Server installed along with the appropriate CA certificates and L1R chain. If I issue an "openssl s_client -showcerts -connect tbdca.gvl.gtech.pri:636" I do get a valid connection and get the following output result:
CONNECTED(00000004)
depth=2 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms<http://www.entrust.net/legal-terms>, OU = "(c) 2012 Entrust, Inc. - for authorized use only", CN = Entrust Root Certification Authority - G3
verify return:1
depth=1 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms<http://www.entrust.net/legal-terms>, OU = "(c) 2014 Entrust, Inc. - for authorized use only", CN = Entrust Certification Authority - L1R
verify return:1
depth=0 C = US, ST = South Carolina, L = Greenville, O = Greenville Technical College, CN = gtech.pri
verify return:1
The certificate named gtech.pri is the Certificate loaded on the Active Directory Domain Controllers. It is a Private SSL certificate with Subject Alternative Names. I forget precisely where I read this and I've tried to locate the document again - but perhaps one of you may know. It seems that the document was indicating that in order to connect to the Active Directory server, the CN and DN of the certificates had to exactly match. (I can't find the document now, so I can't recall the wording. If that is the case, it makes a private certificate rather worthless and makes a SAN certificate worthless from the outset - but OpenSSL does in fact verify the connection)
Since there are no longer any LDAP_START_* for security, I have a dilemma of sorts. I have noticed in the ldap.conf man pages that it is possible to create a .ldaprc file in a user's local directory. Given that I could do that, will it work? Will that give me the access capability that I'm seeking? (again, I am NOT running an LDAP server on this machine. I'm simply coding a program in C that will make a connection to an Active Directory Server and it must be a secure connection) There are several parameters inside of the ldap.conf file that can point back to the certificate base and the certificate directory. There has to be some sort of mechanism to do this since the LDAP_START_TLS commands and so forth have been removed.
Many thanks for your input and thanks for your patience in reading this!
All the best,
Howard
This electronic mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. To the best of our ability and knowledge, this mail message has been scanned and is free of viruses and malware.
3 years, 5 months
No version information available
by Leo Führinger
Hello,
I've installed the newest version 2.4.48 of openldap on Ubuntu 18.04:
vergrößern
./configure --with-cyrus-sasl --with-tls=openssl --enable-overlays=mod
--enable-backends=mod --disable-perl --disable-ndb --enable-crypt
--enable-modules --enable-dynamic --enable-syslog --enable-debug
--enable-local --enable-spasswd --disable-sql --enable-mdb
make depend
make
#test
make test > test_results.txt
grep '>>>>>.*failed' test_results.txt
#install
make install
If I run the scritp 'sudo sh updateOpenldap.sh' which includes the command
ldapdelete -x -r -D cn=admin,dc=aesettlingen,dc=ddnss,dc=de -w geheim
ou=benutzer,dc=schule,dc=ddnss,dc=de >> updateOpenldap.log 2>>
updateOpenldap.errorlog
everything works fine.
If I use a cronjob via crontab
*/1 * * * * /bin/bash /home/ldap/convertADtoOpenldap/updateOpenldap.sh
I get the errors:
ldapdelete: /usr/local/lib/liblber-2.4.so.2: no version information
available (required by ldapdelete)
ldapdelete: /usr/local/lib/libldap-2.4.so.2: no version information
available (required by ldapdelete)
LDAP vendor version mismatch: library 20448, header 20445
Here the content of /usr/lib/
vergrößern
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
root@ldapserver:/# ls -lah /usr/lib/lib*
lrwxrwxrwx 1 root root 21 Mai 14 09:07 /usr/lib/libDeployPkg.so.0 ->
libDeployPkg.so.0.0.0
-rw-r--r-- 1 root root 31K Mai 14 09:07 /usr/lib/libDeployPkg.so.0.0.0
lrwxrwxrwx 1 root root 15 Dez 19 2018 /usr/lib/libgjs.so.0 -> libgjs.so.0.0.0
-rw-r--r-- 1 root root 820K Dez 19 2018 /usr/lib/libgjs.so.0.0.0
lrwxrwxrwx 1 root root 20 Mai 14 09:07 /usr/lib/libguestlib.so.0 ->
libguestlib.so.0.0.0
-rw-r--r-- 1 root root 23K Mai 14 09:07 /usr/lib/libguestlib.so.0.0.0
lrwxrwxrwx 1 root root 16 Mai 14 09:07 /usr/lib/libhgfs.so.0 ->
libhgfs.so.0.0.0
-rw-r--r-- 1 root root 160K Mai 14 09:07 /usr/lib/libhgfs.so.0.0.0
lrwxrwxrwx 1 root root 31 Sep 16 17:37 /usr/lib/libldap-2.4.so.2 ->
/usr/local/lib/libldap-2.4.so.2
lrwxrwxrwx 1 root root 17 Sep 4 2018 /usr/lib/libnetpbm.so.10 ->
libnetpbm.so.10.0
-rw-r--r-- 1 root root 143K Apr 23 2016 /usr/lib/libnetpbm.so.10.0
lrwxrwxrwx 1 root root 18 Mai 14 09:07 /usr/lib/libvgauth.so.0 ->
libvgauth.so.0.0.0
-rw-r--r-- 1 root root 84K Mai 14 09:07 /usr/lib/libvgauth.so.0.0.0
lrwxrwxrwx 1 root root 19 Mai 14 09:07 /usr/lib/libvmtools.so.0 ->
libvmtools.so.0.0.0
-rw-r--r-- 1 root root 609K Mai 14 09:07 /usr/lib/libvmtools.so.0.0.0
and /usr/local/lib/
vergrößern
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
root@ldapserver:/# ls -lah /usr/local/lib/lib*
lrwxrwxrwx 1 root root 22 Okt 3 18:11
/usr/local/lib/liblber-2.4.so.2 -> liblber-2.4.so.2.10.11
-rw-r--r-- 1 root root 222K Okt 3 18:11 /usr/local/lib/liblber-2.4.so.2.10.11
-rw-r--r-- 1 root root 223K Sep 12 2018 /usr/local/lib/liblber-2.4.so.2.10.8
-rw-r--r-- 1 root root 223K Sep 11 2018 /usr/local/lib/liblber-2.4.so.2.10.9
-rw-r--r-- 1 root root 375K Okt 3 18:11 /usr/local/lib/liblber.a
-rw-r--r-- 1 root root 827 Okt 3 18:11 /usr/local/lib/liblber.la
lrwxrwxrwx 1 root root 22 Okt 3 18:11 /usr/local/lib/liblber.so ->
liblber-2.4.so.2.10.11
lrwxrwxrwx 1 root root 22 Okt 3 18:11
/usr/local/lib/libldap-2.4.so.2 -> libldap-2.4.so.2.10.11
-rw-r--r-- 1 root root 1,4M Okt 3 18:11 /usr/local/lib/libldap-2.4.so.2.10.11
-rw-r--r-- 1 root root 1,4M Sep 12 2018 /usr/local/lib/libldap-2.4.so.2.10.8
-rw-r--r-- 1 root root 1,4M Sep 11 2018 /usr/local/lib/libldap-2.4.so.2.10.9
-rw-r--r-- 1 root root 2,8M Okt 3 18:11 /usr/local/lib/libldap.a
-rw-r--r-- 1 root root 876 Okt 3 18:11 /usr/local/lib/libldap.la
lrwxrwxrwx 1 root root 24 Okt 3 18:11
/usr/local/lib/libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.10.11
-rw-r--r-- 1 root root 1,6M Okt 3 18:11 /usr/local/lib/libldap_r-2.4.so.2.10.11
-rw-r--r-- 1 root root 1,6M Sep 12 2018 /usr/local/lib/libldap_r-2.4.so.2.10.8
-rw-r--r-- 1 root root 1,6M Sep 11 2018 /usr/local/lib/libldap_r-2.4.so.2.10.9
-rw-r--r-- 1 root root 3,1M Okt 3 18:11 /usr/local/lib/libldap_r.a
-rw-r--r-- 1 root root 899 Okt 3 18:11 /usr/local/lib/libldap_r.la
lrwxrwxrwx 1 root root 24 Okt 3 18:11 /usr/local/lib/libldap_r.so
-> libldap_r-2.4.so.2.10.11
lrwxrwxrwx 1 root root 22 Okt 3 18:11 /usr/local/lib/libldap.so ->
libldap-2.4.so.2.10.11
Does somebody has any idea?
Thanks a lot!
Leo
3 years, 5 months
