slapd not running, not producing useful messages
by Uwe Falke
Hi, I am new to openldap.
I've been searching the internet and this list, but have not found a match
for my issue (though there are several failures of slapd to run reported,
they all appear to differ from my case in that there were some side infos
provided by slapd).
I've built slapd (fairly plain: --enable-bdb=no --enable-hdb=no
--with-tls) , installed it and tried to start it following the
instructions in the admin guide ( chapter 2. A Quick-Start Guide, for that
matter).
modified /usr/local/etc/openldap/slapd.ldif
ran
[root@...]# /usr/local/sbin/slapadd -n 0 -F
/usr/local/etc/openldap/slapd.d -l /usr/local/etc/openldap/slapd.ldif
_#################### 100.00% eta none elapsed none fast!
Closing DB...
[root@...]# chown -R slapd.slapd /usr/local/etc/openldap/
[root@...]# chown -R slapd.slapd /usr/local/var/openldap-data
Then, attempting to start slapd:
# /usr/local/libexec/slapd -u slapd -g slapd -F
/usr/local/etc/openldap/slapd.d -VVVVV -d65535
ldap_url_parse_ext(ldap://localhost/)
ldap_init: trying /usr/local/etc/openldap/ldap.conf
ldap_init: using /usr/local/etc/openldap/ldap.conf
ldap_init: HOME env is /root
ldap_init: trying /root/ldaprc
ldap_init: trying /root/.ldaprc
ldap_init: trying ldaprc
ldap_init: LDAPCONF env is NULL
ldap_init: LDAPRC env is NULL
@(#) $OpenLDAP: slapd 2.4.49 (May 4 2020 11:30:05) $
root@xcat2.meteo:/usr/local/src/openldap-2.4.49/servers/slapd
Included static overlays:
syncprov
Included static backends:
config
ldif
monitor
mdb
relay
5eb2c445 slapd stopped.
5eb2c445 connections_destroy: nothing to destroy.
I've tried to strace the slapd start, but that gave me no clue ...
What can I further do to get useful hints to the cause o slapd's failure
to run?
Why, albeit I submit -F /usr/local/etc/openldap/slapd.d, does slapd /
ldap_init report "using /usr/local/etc/openldap/ldap.conf"?
Mit freundlichen Grüßen / Kind regards
Dr. Uwe Falke
IT Specialist
Global Technology Services / Project Services Delivery / High Performance
Computing
+49 175 575 2877 Mobile
Rathausstr. 7, 09111 Chemnitz, Germany
uwefalke(a)de.ibm.com
IBM Services
IBM Deutschland Business & Technology Services GmbH
Geschäftsführung: Dr. Thomas Wolter, Sven Schooss
Sitz der Gesellschaft: Ehningen
Registergericht: Amtsgericht Stuttgart, HRB 17122
3 years, 4 months
2.4.45 on ubuntu replication issues between peers
by Malcolm Herbert
Apologies if this is not the correct forum for this problem, however I'm having replication issues with a two-node multi-provider setup which I'm trying to diagnose and any help would be appreciated (if there is a replication troubleshooting guide available that I can follow to diagnose these issues myself, I'm more than happy to work through that, please let me know)
I have the following: two ubuntu 18.04 hosts (alpha, bravo); each has 2.4.45+dfsg-1ubuntu1.4; ldaps:// is configured and visible from the other; queries by clients work fine; time is in sync between them; the memberof overlay is present and appears to work; the active configuration is in olc (cn=config) form
Summary:
The replication issue manifests itself this way:
* ldapmodify of a user record attribute on bravo replicates ok to alpha, but the user record there loses the memberof attributes
* ldapmodify of a user record attribute on alpha never replicates to bravo
I can "repair" the memberof attribute for a user across both hosts by removing them from a group and then re-instating them - these ldapmodify changes must occur to bravo however
Other observations are that the root node on each server seems to have different entryuuid attributes but the contextcsn from each server is present and is replicated (as shown at the bottom of this email) ...
I'm also wondering whether I might have the layering of these overlays wrong - I have them in order {0}back_mdb, {1}memberof, {2}refint, {3}syncprov ... should those instead be {0}back_mdb, {1}syncprov, {2}memberof, {3}refint?
Background:
This setup was initially just alpha with a nis/rfc2307 schema, but I copied out all of that data, converted it to rfc2307bis, configured bravo from scratch with an rfc2307bis schema, imported my converted data and successfully migrated my clients to use bravo.
Once the clients (or as many of them as I could) were looking to bravo, I dropped all the data out of alpha and then configured it from scratch to match that on bravo. Unfortunately I know I got bits of this part of the process wrong and this may have soured my result:
* olcServerID was missing on both hosts
* initially olcSyncrepl was explicitly excluding memberof from replication with 'exattr="memberof"'
* because I couldn't get replication working, I eventually manually added the same data to alpha as I'd used to populate bravo
* at some point replication *did* kind of work and my users immediately lost memberof across the board
Since then, I've gradually remediated the config and data across both hosts, but replication still refuses to cooperate (as summarised above). This is the bits of the config that appear to be relevant, and as far as I can tell, they look OK to me:
alpha (slightly edited for brevity) - bravo differs only in the value for olcServerID, olcRootPW hash and olcSyncrepl peer uri:
dn: cn=config
cn: config
objectClass: olcGlobal
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: none
olcPidFile: /var/run/slapd/slapd.pid
olcServerID: 2
olcTLSCACertificateFile: /etc/ldap/sasl2/ca-certificates.crt
olcTLSCertificateFile: /etc/ldap/sasl2/server.crt
olcTLSCertificateKeyFile: /etc/ldap/sasl2/server.key
olcTLSVerifyClient: never
olcToolThreads: 1
dn: cn=module{0},cn=config
cn: module{0}
objectClass: olcModuleList
olcModuleLoad: {0}back_mdb
olcModuleLoad: {1}memberof
olcModuleLoad: {2}refint
olcModuleLoad: {3}syncprov
olcModulePath: /usr/lib/ldap
:
(omitting pages of schema definitions)
:
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read
olcAccess: {3}to * by dn.base="cn=admin,dc=domain,dc=com" read by * break
olcDatabase: {1}mdb
olcDbCheckpoint: 512 30
olcDbDirectory: /var/lib/ldap
olcDbIndex: cn,uid eq
olcDbIndex: member,memberUid eq
olcDbIndex: objectClass eq
olcDbIndex: uidNumber,gidNumber eq
olcDbMaxSize: 1073741824
olcLastMod: TRUE
olcMirrorMode: TRUE
olcRootDN: cn=admin,dc=domain,dc=com
olcRootPW:: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
olcSuffix: dc=domain,dc=com
olcSyncrepl: {0}rid=000 provider=ldaps://bravo.domain.com:636 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=domain,dc=com" attrs="*,+" bindmethod=simple binddn="cn=admin,dc=domain,dc=com" credentials=xxxxxxxxxxxx
dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config
objectClass: olcConfig
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: top
olcMemberOfDangling: ignore
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
olcMemberOfRefInt: TRUE
olcOverlay: {0}memberof
structuralObjectClass: olcMemberOf
dn: olcOverlay={1}refint,olcDatabase={1}mdb,cn=config
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
objectClass: top
olcOverlay: {1}refint
olcRefintAttribute: memberof member manager owner
structuralObjectClass: olcRefintConfig
dn: olcOverlay={2}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcSyncProvConfig
olcOverlay: {2}syncprov
olcSpCheckpoint: 100 10
structuralObjectClass: olcSyncProvConfig
The root dc=domain,dc=com entry on both hosts, for comparison:
# alpha
dn: dc=domain,dc=com
contextCSN: 20200504085236.014362Z#000000#002#000000
contextCSN: 20200504090305.772541Z#000000#001#000000
createTimestamp: 20200429092623Z
creatorsName: cn=admin,dc=domain,dc=com
dc: internal
entryCSN: 20200429092623.624698Z#000000#000#000000
entryUUID: 3cd3ddfe-1e47-103a-9b7c-636addc89a1e
modifiersName: cn=admin,dc=domain,dc=com
modifyTimestamp: 20200429092623Z
o: domain.com
objectClass: dcObject
objectClass: organization
objectClass: top
structuralObjectClass: organization
# bravo
dn: dc=domain,dc=com
contextCSN: 20200504085236.014362Z#000000#002#000000
contextCSN: 20200504090303.909881Z#000000#001#000000
createTimestamp: 20200406074258Z
creatorsName: cn=admin,dc=domain,dc=com
dc: internal
entryCSN: 20200406074258.475068Z#000000#000#000000
entryUUID: fac4ec88-0c25-103a-80b5-470686e83bfd
modifiersName: cn=admin,dc=domain,dc=com
modifyTimestamp: 20200406074258Z
o: domain.com
objectClass: dcObject
objectClass: organization
objectClass: top
structuralObjectClass: organization
Regards,
Malcolm
--
Malcolm Herbert
mjch(a)mjch.net
3 years, 4 months
Re: MDB Backend database definition
by Beker
then in this case I would like to apologize to both of you for wasting your
time.
I assumed dry-run could be used to test the config file before committing
the changes.
note: Quanah, on the file I was using there is a tab after the colon(:)
instead of two spaces.
Thank you and kind regards
On Tue, May 5, 2020 at 4:57 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote:
>
>
> --On Tuesday, May 5, 2020 11:32 PM +0100 Howard Chu <hyc(a)symas.com> wrote:
>
> > In a dry run none of the directives are actually executed. Since the
> > moduleLoad doesn't happen, the back-mdb schema isn't present.
>
> And on the one system where it worked would indicate that back-mdb was
> compiled in vs being a shared object (just to note).
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
3 years, 4 months
Re: MDB Backend database definition
by Beker
I'm using the following config...
Any path is adjusted according to the target OS on which is being used...
for example in Freebsd openldap's modules are located in
/usr/local/libexec/openldap
Thanks in advance
#
# See slapd-config(5) for details on configuration options.
# This file should NOT be world readable.
#
dn: cn=config
objectClass: olcGlobal
cn: config
#
#
# Define global ACLs to disable default read access.
#
olcPidFile: /run/openldap/slapd.pid
olcArgsFile: /run/openldap/slapd.args
#
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#olcReferral: ldap://root.openldap.org
#
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 64-bit encryption for simple bind
#olcSecurity: ssf=1 update_ssf=112 simple_bind=64
#
# Load dynamic backend modules:
#
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulepath: /usr/lib/openldap
olcModuleload: back_mdb.la
#olcModuleload: back_bdb.la
#olcModuleload: back_hdb.la
#olcModuleload: back_ldap.la
#olcModuleload: back_passwd.la
#olcModuleload: back_shell.la
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
include: file:///etc/openldap/schema/core.ldif
include: file:///etc/openldap/schema/cosine.ldif
include: file:///etc/openldap/schema/nis.ldif
include: file:///etc/openldap/schema/inetorgperson.ldif
# Frontend settings
#
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: to * by * read
#
# Sample global access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
#
#olcAccess: to dn.base="" by * read
#olcAccess: to dn.base="cn=Subschema" by * read
#olcAccess: to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: to * by * none
olcRootPW: {SSHA}pCEOC687DNCkuFE+1owDG0QRHoioRqle
#######################################################################
# LMDB database definitions
#######################################################################
#
dn: olcDatabase=mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
olcDbMaxSize: 1073741824
olcSuffix: dc=hlab,dc=lan
olcRootDN: cn=hlabadm,dc=hlab,dc=lan
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd-config(5) for details.
# Use of strong authentication encouraged.
olcRootPW: {SSHA}dZlyVv5cR432HIzRmnbTq3O6TNOVM6rx
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
olcDbDirectory: /var/lib/openldap/openldap-data
# Indices to maintain
olcDbIndex: objectClass eq
On Tue, May 5, 2020 at 11:16 AM Quanah Gibson-Mount <quanah(a)symas.com>
wrote:
>
>
> --On Tuesday, May 5, 2020 12:02 PM -0500 Beker <fzfq3m(a)gmail.com> wrote:
>
> > Yep, that was an error I made when I redacted the email and changed the
> > the rootdn to not leak info about my environment (which might be stupid
> > since this is just a home lab)
>
> I would suggest you provide the full, unredacted slapd.ldif file you were
> loading.
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
3 years, 4 months
OpenLDAP, systemd and EL 7.7
by Abdelkader Chelouah
Hello,
Since the upgrade to RHEL 7.7, my openldap service with property
|Type=forking| and property |PIDFile| defined doesn't start and its
status shows the following error messages:
May 02 20:02:57 systemd[1]: New main PID 445254 does not belong to
service, and PID file is not owned by root. Refusing.
Actually, slapd is started with -u ldap -g ldap options, so the owner of
the pid file slapd.pid is ldap. The problem was introduced by
|systemd-219-67| to fix the security issue CVE-2018-16888. See
https://access.redhat.com/solutions/4420581 for more details.
Is there a way to overcome this issue ?
Regards
3 years, 4 months
MDB Backend database definition
by Beker
Hello
I'm getting an error while trying to use MDB backend. The section that's
giving issue is the following one:
#######################################################################
# LMDB database definitions
#######################################################################
#
dn: olcDatabase=mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
olcDbMaxSize: 1073741824
olcSuffix: dc=test,dc=local
olcRootDN: cn=mdbadm,test,dc=local
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd-config(5) for details.
# Use of strong authentication encouraged.
olcRootPW: {SSHA}XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
olcDbDirectory: /var/db/openldap-data
# Indices to maintain
olcDbIndex: objectClass eq
with this section added to the end of slapd.ldif i get the error *5ea9641d
<= str2entry: str2ad(olcDbMaxSize): attribute type undefined* while testing
the import using *slapadd -v -n0 -F /etc/openldap/slapd.d -l
/etc/openldap/slapd.ldif*
if i comment the offending line *olcDbMaxSize: 1073741824* then I just get
an error with another line in the same section.
This is a fresh install, the slapd.d folder is empty and I'm using the
example slapd.ldif.sample that comes with the software (it has mdb lodaded
as module by default)
#
# Load dynamic backend modules:
#
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulepath: /usr/lib/openldap
#olcModuleload: back_bdb.so
#olcModuleload: back_hdb.so
#olcModuleload: back_ldap.so
olcModuleload: back_mdb.so
#olcModuleload: back_passwd.so
#olcModuleload: back_shell.so
Thanks in dvance for any hint or help you can provide
Best regards
3 years, 4 months
OpenLDAP help - Import issue
by Pranjit Biswas
HI ,
We are trying to install openldap.x86_64 - 2.4.44-21.el7_6 on an Linux RHEL 7.7 on AWS .
We have installed and made changes to the config files and did a slaptest of the config file as shown below .
[root@efg-ac cn=config]# slaptest -u
5ea6064f ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif"
5ea6064f ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={2}hdb.ldif"
config file testing succeeded
Now we are importing the ldif file from our current on-prem server .
Even though we were getting different errors earlier , after all the changes we have made to the config , the error that we are getting now is ldap_bind error for the credentials .
[root@efg-dev cn=config]# ldapadd -w xxxxxxxx -x -D "cn=Manager,dc=bpost,dc=be" -f ldap_dump-27042020-DEV.ldif
ldap_bind: Invalid credentials (49)
We are not sure which password to give here .
We have given the same credentials in the config file : olcDatabase={2}hdb.ldif
olcRootDN: cn=Manager,dc=bpost,dc=be
olcRootPW: xxxxxxxx
Regards,
Pranjit | Lead Consultant |B2B
Cell:- +91-9573080955
pranjit_biswas(a)infosys.com<mailto:pranjit_biswas@infosys.com>
PTO Plan :- None
3 years, 4 months
Can not find object by attribute value
by xaled＠web.de
Hi,
Could someone help me with this one? I have a user1 with inetUserStatus:
active and user2 inetUserStatus: inactive. If I search for a user with a
inetUserStatus=(in)active I don't get any results:
# ldapsearch -x -H ldap://127.0.0.1:389 -D
'cn=admin,dc=gal,dc=example,dc=com' -w secret -LLL -b
ou=people,dc=gal,dc=example,dc=com '(inetUserStatus=active)'
# ldapsearch -x -H ldap://127.0.0.1:389 -D
'cn=admin,dc=gal,dc=example,dc=com' -w secret -LLL -b
ou=people,dc=gal,dc=example,dc=com '(inetUserStatus=inactive)'
What is wrong with my search or slapd config?
If I search for a * as attribute value I get both users.
# ldapsearch -x -H ldap://127.0.0.1:389 -D
'cn=admin,dc=gal,dc=example,dc=com' -w secret -LLL -b
ou=people,dc=gal,dc=example,dc=com '(inetUserStatus=*)'
dn: uid=user2,ou=people,dc=gal,dc=example,dc=com
shadowWarning: 0
gidNumber: 100
shadowMax: 0
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetUser
loginShell: /bin/bash
userPassword:: e1NTSEF9TVk0WW432UzRxYjRBNWN1TFlTaXZCVFBHRFN3MzdoYWs=
uid: user2
shadowLastChange: 0
cn: user2
homeDirectory: /home/user2
uidNumber: 1006
gecos: user2
inetUserStatus: inactive
dn: uid=user1,ou=people,dc=gal,dc=example,dc=com
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetUser
cn: user1
uid: user1
uidNumber: 1005
gidNumber: 100
homeDirectory: /home/user1
loginShell: /bin/bash
userPassword:: e1NTSEF9TVk0WW1HU231xYjRBNWN1TFlTaXZCVFBHRFN3MzdoYWs=
shadowLastChange: 0
shadowMax: 0
shadowWarning: 0
inetUserStatus: active
gecos: user1
# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=schema,cn=config dn
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: cn={4}ldapab,cn=schema,cn=config
dn: cn={5}openxchange,cn=schema,cn=config
dn: cn={6}evolutionperson,cn=schema,cn=config
dn: cn={7}inetUser,cn=schema,cn=config
s# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -o ldif-wrap=no -b
cn={7}inetUser,cn=schema,cn=config
dn: cn={7}inetUser,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: {7}inetUser
olcAttributeTypes: {0}( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group
that the entry belongs to' EQUALITY distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'Netscape Delegated Administrator' )
olcAttributeTypes: {1}( 2.16.840.1.113730.3.1.692 NAME 'inetUserStatus' DESC
'"active", "inactive", or "deleted" status of a user' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape subscriber
interoperability' )
olcAttributeTypes: {2}( 2.16.840.1.113730.3.1.693 NAME 'inetUserHttpURL'
DESC 'A users Web addresses' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN
'Netscape subscriber interoperability' )
olcObjectClasses: {0}( 2.16.840.1.113730.3.2.130 NAME 'inetUser' DESC
'Auxiliary class which must be present in an entry for delivery of
subscriber services' SUP top AUXILIARY MAY ( uid $ inetUserStatus $
inetUserHTTPURL $ userPassword $ memberOf ) X-ORIGIN 'Netscape subscriber
interoperability' )
Thanks
3 years, 4 months
Antw: [EXT] Can not find object by attribute value
by Ulrich Windl
>>> <xaled(a)web.de> schrieb am 04.05.2020 um 23:10 in Nachricht
<3418_1588627588_5EB08884_3418_88_1_1c5701d62258$69c28330$3d478990$(a)web.de>:
> Hi,
>
>
>
> Could someone help me with this one? I have a user1 with inetUserStatus:
> active and user2 inetUserStatus: inactive. If I search for a user with a
> inetUserStatus=(in)active I don't get any results:
>
>
>
> # ldapsearch ‑x ‑H ldap://127.0.0.1:389 ‑D
> 'cn=admin,dc=gal,dc=example,dc=com' ‑w secret ‑LLL ‑b
> ou=people,dc=gal,dc=example,dc=com '(inetUserStatus=active)'
>
> # ldapsearch ‑x ‑H ldap://127.0.0.1:389 ‑D
> 'cn=admin,dc=gal,dc=example,dc=com' ‑w secret ‑LLL ‑b
> ou=people,dc=gal,dc=example,dc=com '(inetUserStatus=inactive)'
>
>
>
> What is wrong with my search or slapd config?
>
>
>
> If I search for a * as attribute value I get both users.
>
>
>
> # ldapsearch ‑x ‑H ldap://127.0.0.1:389 ‑D
> 'cn=admin,dc=gal,dc=example,dc=com' ‑w secret ‑LLL ‑b
> ou=people,dc=gal,dc=example,dc=com '(inetUserStatus=*)'
>
> dn: uid=user2,ou=people,dc=gal,dc=example,dc=com
>
> shadowWarning: 0
>
> gidNumber: 100
>
> shadowMax: 0
>
> objectClass: top
>
> objectClass: account
>
> objectClass: posixAccount
>
> objectClass: shadowAccount
>
> objectClass: inetUser
>
> loginShell: /bin/bash
>
> userPassword:: e1NTSEF9TVk0WW432UzRxYjRBNWN1TFlTaXZCVFBHRFN3MzdoYWs=
>
> uid: user2
>
> shadowLastChange: 0
>
> cn: user2
>
> homeDirectory: /home/user2
>
> uidNumber: 1006
>
> gecos: user2
>
> inetUserStatus: inactive
>
>
>
> dn: uid=user1,ou=people,dc=gal,dc=example,dc=com
>
> objectClass: top
>
> objectClass: account
>
> objectClass: posixAccount
>
> objectClass: shadowAccount
>
> objectClass: inetUser
>
> cn: user1
>
> uid: user1
>
> uidNumber: 1005
>
> gidNumber: 100
>
> homeDirectory: /home/user1
>
> loginShell: /bin/bash
>
> userPassword:: e1NTSEF9TVk0WW1HU231xYjRBNWN1TFlTaXZCVFBHRFN3MzdoYWs=
>
> shadowLastChange: 0
>
> shadowMax: 0
>
> shadowWarning: 0
>
> inetUserStatus: active
>
> gecos: user1
>
>
>
> # ldapsearch ‑LLLQY EXTERNAL ‑H ldapi:/// ‑b cn=schema,cn=config dn
>
> dn: cn=schema,cn=config
>
> dn: cn={0}core,cn=schema,cn=config
>
> dn: cn={1}cosine,cn=schema,cn=config
>
> dn: cn={2}nis,cn=schema,cn=config
>
> dn: cn={3}inetorgperson,cn=schema,cn=config
>
> dn: cn={4}ldapab,cn=schema,cn=config
>
> dn: cn={5}openxchange,cn=schema,cn=config
>
> dn: cn={6}evolutionperson,cn=schema,cn=config
>
> dn: cn={7}inetUser,cn=schema,cn=config
>
>
>
> s# ldapsearch ‑LLLQY EXTERNAL ‑H ldapi:/// ‑o ldif‑wrap=no ‑b
> cn={7}inetUser,cn=schema,cn=config
>
> dn: cn={7}inetUser,cn=schema,cn=config
>
> objectClass: olcSchemaConfig
>
> cn: {7}inetUser
>
> olcAttributeTypes: {0}( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group
> that the entry belongs to' EQUALITY distinguishedNameMatch SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.12 X‑ORIGIN 'Netscape Delegated Administrator' )
>
> olcAttributeTypes: {1}( 2.16.840.1.113730.3.1.692 NAME 'inetUserStatus'
DESC
> '"active", "inactive", or "deleted" status of a user' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 SINGLE‑VALUE X‑ORIGIN 'Netscape subscriber
> interoperability' )
There's no EQUALITY. Does slapd log any message when you try to compare?
>
> olcAttributeTypes: {2}( 2.16.840.1.113730.3.1.693 NAME 'inetUserHttpURL'
> DESC 'A users Web addresses' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X‑ORIGIN
> 'Netscape subscriber interoperability' )
>
> olcObjectClasses: {0}( 2.16.840.1.113730.3.2.130 NAME 'inetUser' DESC
> 'Auxiliary class which must be present in an entry for delivery of
> subscriber services' SUP top AUXILIARY MAY ( uid $ inetUserStatus $
> inetUserHTTPURL $ userPassword $ memberOf ) X‑ORIGIN 'Netscape subscriber
> interoperability' )
>
>
>
> Thanks
3 years, 4 months
Antw: [EXT] RE: OpenLDAP help - Import issue
by Ulrich Windl
>>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am 04.05.2020 um 19:27 in
Nachricht
<31908_1588613249_5EB05081_31908_246_1_24A29F72442AE6729B2A09EC(a)[192.168.1.144]>
>
> ‑‑On Monday, May 4, 2020 10:51 AM +0000 Pranjit Biswas
> <Pranjit_Biswas(a)infosys.com> wrote:
>
>
>> This SSHA PW has been updated in olcDatabase={2}hdb.ldif.
>>
>> olcRootPW: {SSHA}wbMAL
>
> Each file in the cn=config DATABASE has this line at the start:
>
> # AUTO‑GENERATED FILE ‑ DO NOT EDIT!! Use ldapmodify.
>
> You may wish to read that line and understand what it's telling you.
Maybe "Use ldapmodify." could be a bit more verbose ;-)
>
> Regards,
> Quanah
>
> ‑‑
>
> Quanah Gibson‑Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
3 years, 4 months
