Hello,
Playing around with 2.6
Was attempting to add lastbind module but get error:
cat <<EOF | ldapadd -D cn=config -w mysecret dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulePath: /opt/symas/lib/openldap/ olcModuleLoad: lastbind.la EOF adding new entry "cn=module,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: <olcModuleLoad> handler exited with 1
I have no issues doing the above with 2.5 rpm rhel8 pkg. Is there something im doing wrong?
Any input is appreciated.
Thank you, Dave
On 11/29/21 19:47, Dave Macias wrote:
Was attempting to add lastbind module but get error:
Maybe you're hitting this one:
https://bugs.openldap.org/show_bug.cgi?id=9725
Ciao, Michael.
Thank you Michael for the link. It probably what im running into. If i understand correctly, the lastbind functionality has been integrated into the main slapd binary. If yes, what do I need to do in order to use it?
Im looking at this: https://git.openldap.org/openldap/openldap/-/blob/6327f45d7de73f669fa438d4f5...
I decided to simply continue building the cn=config and noticed the new olcLastBindPrecision attributes under several DNs.
dn: cn=schema,cn=config olcAttributeTypes: ( OLcfgDbAt:0.22 NAME 'olcLastBind' EQUALITY booleanMatch SYNTAX OMsBoolean SINGLE-VALUE ) olcAttributeTypes: ( OLcfgDbAt:0.23 NAME 'olcLastBindPrecision' EQUALITY integerMatch SYNTAX OMsInteger SINGLE-VALUE ) olcObjectClasses: ( OLcfgGlOc:4 NAME 'olcDatabaseConfig' DESC 'OpenLDAP Database-specific options' SUP olcConfig STRUCTURAL MUST olcDatabase MAY ( olcDisabled $ olcHidden $ olcSuffix $ olcSubordinate $ olcAccess $ olcAddContentAcl $ olcLastMod $ olcLastBind $ olcLastBindPrecision $ olcLimits $ olcMaxDerefDepth $ olcPlugin $ olcReadOnly $ olcReplica $ olcReplicaArgsFile $ olcReplicaPidFile $ olcReplicationInterval $ olcReplogFile $ olcRequires $ olcRestrict $ olcRootDN $ olcRootPW $ olcSchemaDN $ olcSecurity $ olcSizeLimit $ olcSyncUseSubentry $ olcSyncrepl $ olcTimeLimit $ olcUpdateDN $ olcUpdateRef $ olcMultiProvider $ olcMonitoring $ olcExtraAttrs ) )
dn: olcDatabase={-1}frontend,cn=config olcLastBind: TRUE olcLastBindPrecision: 0
dn: olcDatabase={0}config,cn=config olcLastBind: TRUE olcLastBindPrecision: 0
dn: olcDatabase={1}mdb,cn=config olcLastBind: TRUE olcLastBindPrecision: 0
dn: olcDatabase={2}monitor,cn=config olcLastBind: TRUE olcLastBindPrecision: 0
I tried to import my data.ldif but get this error:
slapadd -n 1 -F /opt/symas/etc/openldap/slapd.d -l data.ldif <= str2entry: str2ad(authTimestamp): attribute type undefined slapadd: could not parse entry (line=24) Closing DB...
I'm probably missing a configuration... in my cn=config...
Any input is appreciated!
Thank you, Dave
On Mon, Nov 29, 2021 at 2:25 PM Michael Ströder michael@stroeder.com wrote:
On 11/29/21 19:47, Dave Macias wrote:
Was attempting to add lastbind module but get error:
Maybe you're hitting this one:
https://bugs.openldap.org/show_bug.cgi?id=9725
Ciao, Michael.
--On Wednesday, December 1, 2021 10:06 AM -0500 Dave Macias davama@gmail.com wrote:
Thank you Michael for the link. It probably what im running into. If i understand correctly, the lastbind functionality has been integrated into the main slapd binary. If yes, what do I need to do in order to use it?
Only some of it has been integrated in.
Im looking at this: https://git.openldap.org/openldap/openldap/-/blob/6327f45d7de73f66 9fa438d4f5823e139cf4e6b4/contrib/slapd-modules/lastbind/slapo-lastbind.5
slapadd -n 1 -F /opt/symas/etc/openldap/slapd.d -l data.ldif <= str2entry: str2ad(authTimestamp): attribute type undefined slapadd: could not parse entry (line=24) Closing DB...
You need the fix for ITS#9725 to make use of authTimestamp.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Wed, Dec 01, 2021 at 10:06:11AM -0500, Dave Macias wrote:
slapadd -n 1 -F /opt/symas/etc/openldap/slapd.d -l data.ldif <= str2entry: str2ad(authTimestamp): attribute type undefined slapadd: could not parse entry (line=24) Closing DB...
Hi Dave, the functionality in core uses behera-ppolicy's pwdLastSuccess attribute instead.
Regards,
the functionality in core uses behera-ppolicy's pwdLastSuccess attribute instead.
Thank you for that. I see that attribute:
dn: cn=config pwdLastSuccess: 20211201143557Z
dn: cn=schema,cn=config olcAttributeTypes: ( 1.3.6.1.4.1.42.2.27.8.1.29 NAME 'pwdLastSuccess' DESC 'The timestamp of the last successful authentication' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
Does that mean i will have to change each "authTimestamp" attribute to "pwdLastSuccess" on my data dit ? Of course once the ITS#9725 fix is applied.
Thanks!
--On Wednesday, December 1, 2021 12:22 PM -0500 Dave Macias davama@gmail.com wrote:
the functionality in core uses behera-ppolicy's pwdLastSuccess attribute instead.
Thank you for that. I see that attribute:
dn: cn=config pwdLastSuccess: 20211201143557Z
dn: cn=schema,cn=config
olcAttributeTypes: ( 1.3.6.1.4.1.42.2.27.8.1.29 NAME 'pwdLastSuccess' DESC 'The timestamp of the last successful authentication' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
Does that mean i will have to change each "authTimestamp" attribute to "pwdLastSuccess" on my data dit ? Of course once the ITS#9725 fix is applied.
No.
If you want to use "authTimestamp", you need the fix.
If you don't want to use "authTimestamp" and pwdLastSuccess is sufficient, you don't need the fix nor do you need to load the lastbind contrib module.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 12/1/21 18:43, Quanah Gibson-Mount wrote:
If you want to use "authTimestamp", you need the fix.
If you don't want to use "authTimestamp" and pwdLastSuccess is sufficient, you don't need the fix nor do you need to load the lastbind contrib module.
Even if you want to set 'pwdLastSuccess' in the future but still have 'authTimestamp' in your existing DB you need the fix for not running into strange schema issues.
Ciao, Michael.
Thank you very much for the responses!!
I'm assuming authTimestamp is going the way of the dinosaur, maybe not immediately, but eventually.
How can I migrate my data from authTimestamp to pwdLastSuccess? Is it even possible? Thanks!
On Wed, Dec 1, 2021 at 3:46 PM Michael Ströder michael@stroeder.com wrote:
On 12/1/21 18:43, Quanah Gibson-Mount wrote:
If you want to use "authTimestamp", you need the fix.
If you don't want to use "authTimestamp" and pwdLastSuccess is sufficient, you don't need the fix nor do you need to load the lastbind contrib module.
Even if you want to set 'pwdLastSuccess' in the future but still have 'authTimestamp' in your existing DB you need the fix for not running into strange schema issues.
Ciao, Michael.
On 12/1/21 22:58, Dave Macias wrote:
I'm assuming authTimestamp is going the way of the dinosaur, maybe not immediately, but eventually.
How can I migrate my data from authTimestamp to pwdLastSuccess? Is it even possible?
Without the fix for ITS#9725 you can only export your DB to LDIF and replace authTimestamp by pwdLastSuccess and reload your DB while all your slapd replicas are down.
With the fix for ITS#9725 you can write a script which does appropriate LDAP operations using the relax rules control. That's what I plan to do for Æ-DIR once Symas RPMs are ready for RHEL8 with the patch. (All my own openSUSE/SLE and Debian/Ubuntu packages already have the backport patch.)
After one or the other migration step you can then remove using slapo-lastbind from your configuration.
Ciao, Michael.
Without the fix for ITS#9725 you can only export your DB to LDIF and replace authTimestamp by pwdLastSuccess and reload your DB while all your slapd replicas are down.
Thank you for that. I had tried that and failed but realized what I was doing wrong. Im currently importing my data.ldif no problem! This is great! I can continue with my testing. Thank you very much
openldap-technical@openldap.org
-
Dave Macias -
Michael Ströder -
Ondřej Kuzník -
Quanah Gibson-Mount