openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

Replication persistence
by Nebula WAN 08 Jul '19

08 Jul '19

Hello I have a replication problem between two OpenLDAP 2.44 servers configured as multimasters on CentOS 7.3 : The minimal configuration of both are correct (connection OK with admin credentials), I replicate the config and hdb databases as you can see in the configuration above, I use LDAPAdmin to connect to each of them and check if the replication works by creating a test OU: they replicate well. After a week or more, automatic replication no longer works: I have to restart the slapd service to see the data exchange between the two servers ... I have contextCSN for both but they are fixed at the installation date. Do you have an idea ? Thank you Here are the configuration (the olcServerID change in server2's configuration) : dn: olcDatabase={0}config,cn=config changeType: modify add: olcAccess olcAccess: to * by dn.exact="cn=ldapadm,dc=test,dc=factory" manage by * break dn: olcDatabase={2}hdb,cn=config changeType: modify add: olcAccess olcAccess: to * by dn.exact="cn=ldapadm,dc=test,dc=factory" manage by * break dn: cn=config changetype: modify add: olcServerID olcServerID: 1 dn: olcDatabase={1}monitor,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external, cn=auth" read by dn.base="cn=ldapadm,dc=test,dc=factory" read by * none ### Updating ID ### dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldap://server1.test.factory olcServerID: 2 ldap://server2.test.factory ### Enabling CONFIG Replication ### dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov ### Configuring CONFIG replication ### dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://server1.test.factory binddn="cn=config" bindmethod=simple credentials=password searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldap://server2.test.factory binddn="cn=config" bindmethod=simple credentials=password searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE ### Enabling HDB Replication ### dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov ### Configuring HDB replication ### dn: olcDatabase={2}hdb,cn=config add: olcSyncRepl olcSyncRepl: rid=004 provider=ldap://server1.test.factory binddn="cn=ldapadm,dc=test,dc=factory" bindmethod=simple credentials=password searchbase="dc=test,dc=factory" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 olcSyncRepl: rid=005 provider=ldap://server2.test.factory binddn="cn=ldapadm,dc=test,dc=factory" bindmethod=simple credentials=password searchbase="dc=test,dc=factory" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 - add: olcDbIndex olcDbIndex: entryUUID eq - add: olcDbIndex olcDbIndex: entryCSN eq - add: olcMirrorMode olcMirrorMode: TRUE

2 1

How to configure OpenLDAP on Debian Stretch to support SSLv3.0
by Jeremy Davis 02 Jul '19

02 Jul '19

Hi all, I'm writing on behalf of a user ragrading how to go about configuring LDAPS support for SSLv3.0 certificate under OpenLDAP v2.4.44 - running on Debian 9/Stretch (default Debian 'slapd' package install). I know that SSLv3.0 is insecure and generally a bad option, but a user needs to connect to LDAPS with an old application that only supports SSLv3.0. I understand that a complicating factor may be that the Debian OpenLDAP (slapd) package is compiled against GnuTLS, rather than OpenSSL. Any insight that might head me in the right direction would be greatly appreciated. Also please note that I'm a bit of an OpenLDAP newb and my knowledge of SSL/TLS is more related to web servers/browsers and more about "best practices" rather than tweaking to be more permissive. Regards, Jeremy Davis TurnKey Linux

3 2

Error when try modify olcTLS*
by Igor Sousa 29 Jun '19

29 Jun '19

Hi everyone, I've tried a common proceeded: insert CA and server certificates on cn=config. I've created CA and server certificate in PEM format and I've signed server certificate with CA certificate. Then I've created a 5tls.ldif with following content: dn: cn=config changetype: modify replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/openldap/certs/ldap.local.crt - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.local.key - add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/openldap/certs/ca.cert.pem But server has returned following error when I've ran ldapmodify -Y EXTERNAL -H ldapi:/// -f 5tls.ldif: [root@localhost ldifs]# ldapmodify -Y EXTERNAL -H ldapi:/// -f 5tls.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80) ldap.local.crt, ldap.local.key and ca.cert.pem are /etc/openldap/certs and they own read permission to ldap group. I don't understand this behavior and I have no idea what is wrong. OBS: I've mounted environment on CentOS 7, added symas' repository and install from yum. Here some relevant info below. OpenLDAP version - 2.4.47 [root@localhost ldifs]# slapd -V @(#) $OpenLDAP: slapd 2.4.47 (Mar 11 2019 17:22:04) $ build@c7rpm :/home/build/git/rheldap/RHEL7_x86_64/BUILD/symas-openldap-2.4.47/openldap-2.4.47/servers/slapd STATUS after run ldapmodify [root@localhost ldifs]# systemctl status slapd -l ● slapd.service - OpenLDAP Server Daemon Loaded: loaded (/usr/lib/systemd/system/slapd.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2019-06-28 01:51:50 -03; 1h 36min ago Docs: man:slapd man:slapd-config man:slapd-hdb man:slapd-mdb file:///usr/share/doc/openldap-servers/guide.html Process: 4654 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=0/SUCCESS) Process: 4641 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS) Main PID: 4656 (slapd) CGroup: /system.slice/slapd.service └─4656 /usr/sbin/slapd -u ldap -h ldapi:/// ldap:/// Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 fd=11 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=0 BIND dn="" method=163 Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=0 RESULT tag=97 err=0 text= Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=1 MOD dn="cn=config" Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=1 MOD attr=olcTLSCACertificateFile Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=1 RESULT tag=103 err=80 text= Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 op=2 UNBIND Jun 28 03:10:16 localhost.localdomain slapd[4656]: conn=1008 fd=11 closed Best regards, -- Igor Sousa

2 1

Cluster takes around 48 hours to synchronize after deletion
by x0101 26 Jun '19

26 Jun '19

Dear all, We have an OpenLDAP 2.4 cluster of three nodes configured in multi-master and accessed through a VIP in round-robin. The three machines run RHEL7. We noticed that deletion of an entry (done from a Windows machine onto the first node via Oracle's tool ldapmodify.exe) takes a long time (about 48 hours) to be replicated in the cluster. Here's the relevant extract of cn=config for the first node: olcSyncrepl: {0}rid=001 provider=ldap://mynode2:389/ bindmethod=simple binddn="cn=Replicator,dc=mydomain,dc=org" credentials=1234567890 searchbase="dc=mydomain,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 +" keepalive="60:5:10" olcSyncrepl: {1}rid=002 provider=ldap://mynode3:389/ bindmethod=simple binddn="cn=Replicator,dc=mydomain,dc=org" credentials=1234567890 searchbase="dc=mydomain,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 +" keepalive="60:5:10" olcMirrorMode: TRUE We looked up for the offending entry (thisentry) in all nodes' logs and we found this line on mynode3: Jun 18 14:18:20 mynode3 slapd[8871]: conn=1987936 op=14 DEL dn="dc=thisentry,ou=myou,ou=foobars,dc=mydomain,dc=org" There are no other references to thisentry (apart from SRCH operations) on node1 and node2, even if the entry was originally deleted from node1, as said above. What could be the cause and what could we do to further troubleshoot the issue? Thanks in advance.

2 1

debug incoming modify operations
by Mark Coetser 25 Jun '19

25 Jun '19

Hi changing my loglevel to trace or stats, shows me search queries but I need a way to debug a remote client doing a php ldap modify that is failing? -- Thank you, Mark Adrian Coetser mark(a)pkfnet.co.za

4 7

Invalid DN reported during authentication
by Chris K 25 Jun '19

25 Jun '19

Hello experts, I setup an openLDAP server some time ago and am to create a newer server for TLS 1.3 support. I am using a fully patched CentOS 7 server with OpenLDAP 2.4.44 and am seeing 'invalid DN' when authenticating to the server from my Linux client. I will attempt to supply all the config and tests I have done thus far: ######################################## ldap.conf: # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net URI ldap://openldapsec.brm.acslab.wokyourdog.net #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLSCipherSuite HIGH:MEDIUM:+TLSv1:!SSLv2:+SSLv3 TLS_CACERTDIR /etc/openldap/certs TLS_CACERT /etc/openldap/certs/RootCA.pem TLSCACertificateFile /etc/openldap/certs/RootCA.pem TLSCertificateFile /etc/openldap/certs/Identity.pem TLSCertificateKeyFile /etc/openldap/certs/Identity.key TLSVerifyClient never # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on ######################################## slapd.conf # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema # Added for policy include /etc/openldap/schema/ppolicy.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args moduleload ppolicy.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. TLSCACertificateFile /etc/openldap/certs/RootCA.pem TLSCertificateFile /etc/openldap/certs/Identity.pem TLSCertificateKeyFile /etc/openldap/certs/Identity.key database bdb suffix "dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" rootdn "cn=root,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" rootpw {SSHA}C6RcppHr0rweEVCQW6pio6tnPCIHCGnt # PPolicy Configuration overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" ppolicy_use_lockout ppolicy_hash_cleartext # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub ######################################## ldapsearch output: [root@OpenLDAP_Server openldap]# ldapsearch -H ldap:// openldapsec.brm.acslab.wokyourdog.net -D "cn=root,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" -w Siladmin123 -ZZ # extended LDIF # # LDAPv3 # base <dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # # openldapsec.brm.acslab.wokyourdog.net dn: dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net dc: openldapsec objectClass: top objectClass: domain # people, openldapsec.brm.acslab.wokyourdog.net dn: ou=people,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net objectClass: top objectClass: organizationalUnit ou: people # swadmin3, openldapsec.brm.acslab.wokyourdog.net dn: cn=swadmin3,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net objectClass: person objectClass: uidObject cn: swadmin3 sn: admin user uid: swadmin3 userPassword:: e1NTSEF9WDdRQ2xzallYUDUvWU9sZnJyc3ZWVXhnS0xkbXB2U1o= # search result search: 3 result: 0 Success # numResponses: 4 # numEntries: 3 ######################################## ldapwhoami [root@OpenLDAP_Server openldap]# ldapwhoami -vvv -h openldapsec.brm.acslab.wokyourdog.net -p 389 -D "cn=swadmin3,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net" -x -w Siladmin123 ldap_initialize( ldap://openldapsec.brm.acslab.wokyourdog.net:389 ) dn:cn=swadmin3,dc=openldapsec,dc=brm,dc=acslab,dc=wokyourdog,dc=net Result: Success (0) ######################################## client authentication failure logs ber_dump: buf=0x7fe684117870 ptr=0x7fe684117870 end=0x7fe68411788d len=29 0000: 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 ...w...1.3.6.1.4 0010: 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .1.1466.20037 ber_dump: buf=0x7fe684117870 ptr=0x7fe684117873 end=0x7fe68411788d len=26 0000: 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e w...1.3.6.1.4.1. 0010: 31 34 36 36 2e 32 30 30 33 37 1466.20037 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ ber_dump: buf=0x7fe684115be0 ptr=0x7fe684115be0 end=0x7fe684115c23 len=67 0000: 02 01 02 60 3e 02 01 03 04 2c 73 77 61 64 6d 69 ...`>....,swadmi 0010: 6e 33 40 6f 70 65 6e 6c 64 61 70 73 65 63 2e 62 n3(a)openldapsec.b 0020: 72 6d 2e 62 73 6e 6c 61 62 2e 62 72 6f 61 64 63 rm.acslab.wokyou 0030: 6f 6d 2e 6e 65 74 80 0b 53 69 6c 61 64 6d 69 6e rdog.net..Siladmin 0040: 31 32 33 123 ber_dump: buf=0x7fe684115be0 ptr=0x7fe684115be3 end=0x7fe684115c23 len=64 0000: 60 3e 02 01 03 04 2c 73 77 61 64 6d 69 6e 33 40 `>....,swadmin3@ 0010: 6f 70 65 6e 6c 64 61 70 73 65 63 2e 62 72 6d 2e openldapsec.brm. 0020: 62 73 6e 6c 61 62 2e 62 72 6f 61 64 63 6f 6d 2e acslab.wokyourdog. 0030: 6e 65 74 80 0b 53 69 6c 61 64 6d 69 6e 31 32 33 net..Siladmin123 ber_dump: buf=0x7fe684115be0 ptr=0x7fe684115c16 end=0x7fe684115c23 len=13 0000: 00 0b 53 69 6c 61 64 6d 69 6e 31 32 33 ..Siladmin123 5d10d347 conn=1048 op=1 do_bind: invalid dn ( swadmin3(a)openldapsec.brm.acslab.wokyourdog.net) 0000: 30 16 02 01 02 61 11 0a 01 22 04 00 04 0a 69 6e 0....a..."....in 0010: 76 61 6c 69 64 20 44 4e valid DN ber_dump: buf=0x7fe6841171a0 ptr=0x7fe6841171a0 end=0x7fe6841171a5 len=5 0000: 02 01 03 42 00 ...B. ber_dump: buf=0x7fe684107eb0 ptr=0x7fe684107eb0 end=0x7fe684107ecd len=29 0000: 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 ...w...1.3.6.1.4 0010: 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .1.1466.20037 ber_dump: buf=0x7fe684107eb0 ptr=0x7fe684107eb3 end=0x7fe684107ecd len=26 0000: 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e w...1.3.6.1.4.1. 0010: 31 34 36 36 2e 32 30 30 33 37 1466.20037 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ ber_dump: buf=0x7fe684002250 ptr=0x7fe684002250 end=0x7fe6840022ae len=94 0000: 02 01 02 60 59 02 01 03 04 47 63 6e 3d 73 77 61 ...`Y....Gcn=swa 0010: 64 6d 69 6e 33 2c 63 6e 3d 75 73 65 72 73 2c 64 dmin3,cn=users,d 0020: 63 3d 6f 70 65 6e 6c 64 61 70 73 65 63 2c 64 63 c=openldapsec,dc 0030: 3d 62 72 6d 2c 64 63 3d 62 73 6e 6c 61 62 2c 64 =brm,dc=acslab,d 0040: 63 3d 62 72 6f 61 64 63 6f 6d 2c 64 63 3d 6e 65 c=wokyourdog,dc=ne 0050: 74 80 0b 53 69 6c 61 64 6d 69 6e 31 32 33 t..Siladmin123 ber_dump: buf=0x7fe684002250 ptr=0x7fe684002253 end=0x7fe6840022ae len=91 0000: 60 59 02 01 03 04 47 63 6e 3d 73 77 61 64 6d 69 `Y....Gcn=swadmi 0010: 6e 33 2c 63 6e 3d 75 73 65 72 73 2c 64 63 3d 6f n3,cn=users,dc=o 0020: 70 65 6e 6c 64 61 70 73 65 63 2c 64 63 3d 62 72 penldapsec,dc=br 0030: 6d 2c 64 63 3d 62 73 6e 6c 61 62 2c 64 63 3d 62 m,dc=acslab,dc=w 0040: 72 6f 61 64 63 6f 6d 2c 64 63 3d 6e 65 74 80 0b kyourdog,dc=net.. 0050: 53 69 6c 61 64 6d 69 6e 31 32 33 Siladmin123 ber_dump: buf=0x7fe684002250 ptr=0x7fe6840022a1 end=0x7fe6840022ae len=13 0000: 00 0b 53 69 6c 61 64 6d 69 6e 31 32 33 ..Siladmin123 0000: 30 0c 02 01 02 61 07 0a 01 31 04 00 04 00 0....a...1.... ber_dump: buf=0x7fe684118dd0 ptr=0x7fe684118dd0 end=0x7fe684118dd5 len=5 0000: 02 01 03 42 00 ...B. Please let me know if you can see my mis-configuration or if you have any questions about my setup. Thanks, Chris

2 1

Hide pwdHistory field from anonymous
by Kyle Sloan 21 Jun '19

21 Jun '19

I am able to hide the userPassword and any other single/unique fields on a query, but I cannot figure out the pwdHistory and how to disable it from anonymous queries. I keep getting syntax errors and am unsure what the syntax is. This works for userPassword, but fails when I replace or add pwdHistory access to attrs=userPassword by self write by anonymous auth by * none Here is what my my query looks like /usr/bin/ldapsearch -h 1.2.3.4 -x -b 'ou=People,dc=company,dc=com' '(uid=myuser)' '*' '+' # extended LDIF # # LDAPv3 # base <ou=People,dc=copmany,dc=com> with scope subtree # filter: (uid=myuser) # requesting: * + # # myuser, People, company dn: uid=myuser,ou=People,dc=company,dc=com uidNumber: 31518 gidNumber: 100 shadowExpire: 99999 shadowMax: 90 objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount uid: myuser pwdHistory: 20180718212202Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}bTWu9btdOzp pwdHistory: 20181015214815Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}Ys8LvXcdnsr pwdHistory: 20181016164512Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}nQLIieWGwt7 pwdHistory: 20190114155333Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}j3d+hxGalnC pwdHistory: 20190412183313Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}7r2E2DdryKa pwdHistory: 20190412185409Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}ZbqMWB0x4v+

3 4

How to filter all entries by multi-value attributes?
by Tankman 六四 21 Jun '19

21 Jun '19

Hi everyone Is there a way to find all people whose telephoneNumber is multi-valued through the use of LDAP filter? Searched around there are only ways to search into multiple values but not based on the number of values. Thanks:) Regards

2 1

LDAP with TLS Enable/Disable not working
by Sunkad, Abhilash 21 Jun '19

21 Jun '19

Hi All, I am facing a strange problem. I am using FreeRadius 3.16 version for my Proxy authentication. I have an AD server and I make an authentication request enabling TLS. So the TLS connection passes and authentication is successful. Now I have one more LDAP server where its non TLS. Now if I make a call, even though TLS is disabled on this server, Client tries to make a TLS connection and fails. I have tried freeing connections but with no luck. Please help. Thanks Abhilash

2 1

Re: Extensible filters and ordering searches: filtering shadowExpire by range?
by Côme Chilliet 19 Jun '19

19 Jun '19

Le mardi 18 juin 2019, 12:36:56 CEST Quanah Gibson-Mount a écrit : > > So, there is no way to filter on shadowExpire values which are less than > > today's timestamp? > > shadowExpire is defined as an integer type, not as a timestamp, so no. > > > It sounds crazy that such basic needs are not covered by LDAP protocol, > > have I missed something? > > It's not clear to me what this has to do with the LDAP protocol. The > definition of the "expire" field from /etc/shadow is: > > Expire : days since Jan 1, 1970 that account is disabled i.e. an absolute > date specifying when the login may no longer be used. > > So it's an integer (just as the RFC defines it). I would imagine you could > write something that converts a current timestamp into the number of days, > etc, and then perform a search. Yeah this is what I was calling timestamp sorry, getting the integer for today is easy, but it seems there is no way for writing a search filter with greater-than or lesser-than for this attribute. It has to do with the LDAP protocol that LDAP lets schema define attributes in ways that forbid substring and range filters. We should be able to use extensible filters for these, and specify which ordering or substring rule we want to see used. And if attributes using integer syntax were to default to integerOrdering when not specified, that would seem more sane. Côme

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical