Dear all,
We are facing 'UNKNOWN attributeDescription' errors in our infrastructure, caused by two different reasons. I realized those only by using `slapcat` which prints the following error/warning message to STDERR: ``` UNKNOWN attributeDescription "..." inserted. ``` In both cases, this issue does not degrade the production of our system. All operations including syncreplication are working in normal parameter.
Case A: In our production, a dedicated slapd syncrepl consumer has the totp module from contrib enabled and ldapbind calls against '{TOTP1}' are performed. This module introduces a new attribute "authTimestamp". IIUC, `slapcat` cannot know about this attribute, because it is not in the config. But attributes of that type are stored in the MDB. I'd like to ask: - How should we deal with this situation? - Is it safe to continue as is or should we define the attribute "authTimestamp" in our schema extension as well?
Case B: We are about to remove some attribute definitions from our schema extension. These are obsolete and not in use in the DB anymore. On the testbed slapd+syncrepl works as expected. But here as well, even though that the DB does not contain any of the obsolete attributes in any entry, `slapcat` throws the same error/warning for all removed attributes from the schema file. My first approach was to re-index the database (even with truncate mode), which did not solve the situation. Stopping the consumer slapd, removing the mdb files and restarting the syncrepl solves it. But on production I would not want to do re-sync everything unnecessarily (it would be possible though). I'd like to ask here: - Is there a way to cleanup MDB from obsolete attributes? - Where/how are those attributes referenced in MDB? - Would it harm to ignore those errors? - Is the removal of attribute definitions from the schema not supported/suggested at all?
Btw, we are running slapd 2.6.3 with mdb backend. (Upgrade to 2.6.7 is in planning now).
During the composition of this mail, further issues came up with slapd-totp and I would like to add some follow-up questions here. If you prefer, I'll write another mail or I could open an issue on bugzilla.
1. By reading some code in slapd-totp.c I recognized that the introduced attribute authTimestamp is SINGLE-VALUE. But slapcat reveals that entries have multiple values of authTimestamp. This sounds not correct to me. 2. In slapd-totp.c: line 856 and 873 both call `ch_calloc` for the same structm, shadowing the same pointer. This looks like a memory leak to me, because also only one free is called. (I might be wrong though).
Many thanks in advance,
Bastian Tweddell wrote:
Dear all,
We are facing 'UNKNOWN attributeDescription' errors in our infrastructure, caused by two different reasons. I realized those only by using `slapcat` which prints the following error/warning message to STDERR:
UNKNOWN attributeDescription "..." inserted.
In both cases, this issue does not degrade the production of our system. All operations including syncreplication are working in normal parameter.
Case A: In our production, a dedicated slapd syncrepl consumer has the totp module from contrib enabled and ldapbind calls against '{TOTP1}' are performed. This module introduces a new attribute "authTimestamp". IIUC, `slapcat` cannot know about this attribute, because it is not in the config. But attributes of that type are stored in the MDB. I'd like to ask:
- How should we deal with this situation?
File a bug against the totp module. If it is using this attribute, it should be registering it in the schema during module initialization.
- Is it safe to continue as is or should we define the attribute "authTimestamp" in our schema extension as well?
It's mostly safe, unless you configured an index on authtimestamp and needed to run slapindex on it.
Case B: We are about to remove some attribute definitions from our schema extension. These are obsolete and not in use in the DB anymore. On the testbed slapd+syncrepl works as expected. But here as well, even though that the DB does not contain any of the obsolete attributes in any entry, `slapcat` throws the same error/warning for all removed attributes from the schema file. My first approach was to re-index the database (even with truncate mode), which did not solve the situation. Stopping the consumer slapd, removing the mdb files and restarting the syncrepl solves it. But on production I would not want to do re-sync everything unnecessarily (it would be possible though). I'd like to ask here:
- Is there a way to cleanup MDB from obsolete attributes?
Generally no, the DB records every attribute type you have ever used.
- Where/how are those attributes referenced in MDB?
Internal lookup tables.
- Would it harm to ignore those errors?
They're just warnings. If they were errors, slapd would not start up.
- Is the removal of attribute definitions from the schema not supported/suggested at all?
Never recommended, no. If you're retiring a definition, just add OBSOLETE to it.
Btw, we are running slapd 2.6.3 with mdb backend. (Upgrade to 2.6.7 is in planning now).
During the composition of this mail, further issues came up with slapd-totp and I would like to add some follow-up questions here. If you prefer, I'll write another mail or I could open an issue on bugzilla.
Open a separate issue in bugzilla.
- By reading some code in slapd-totp.c I recognized that the introduced attribute authTimestamp is SINGLE-VALUE. But slapcat reveals that entries have multiple values of authTimestamp. This sounds not correct to me.
- In slapd-totp.c: line 856 and 873 both call `ch_calloc` for the same structm, shadowing the same pointer. This looks like a memory leak to me, because also only one free is called. (I might be wrong though).
Note that contrib modules are explicitly not maintained by the Project. You'll need to find someone in the community to fix these issues for you.
Many thanks in advance,
--On Wednesday, January 31, 2024 4:16 PM +0000 Howard Chu hyc@symas.com wrote:
Note that contrib modules are explicitly not maintained by the Project. You'll need to find someone in the community to fix these issues for you.
I'd also wonder why you're not using the official OTP overlay:
which is maintained by the project.
Regards, Quanah
On 31Jan24 09:01-0800, Quanah Gibson-Mount wrote:
Note that contrib modules are explicitly not maintained by the Project. You'll need to find someone in the community to fix these issues for you.
I'd also wonder why you're not using the official OTP overlay:
which is maintained by the project.
The reason was, that we use it as a TOTP-only solution. I had a testsetup with slapo-otp as well, but this module required userPassword + TOTP, IIRC; where we cannot not have userPassword.
Our setup is to use TOTP as 2FA for ssh logins against the centralized LDAP infrstructure. The ssh-login 1FA is ssh pubkey (also in LDAP) and 2FA is TOTP. To achieve this we use a PAM module which does an ldapbind against the user-DN which has the userPassword schema '{TOTP1}'.
Maybe I wrong or outdated here and slapo-opt also supports TOTP-only authentication now?
Cheers,
--On Thursday, February 1, 2024 10:55 AM +0100 Bastian Tweddell b.tweddell@fz-juelich.de wrote:
Our setup is to use TOTP as 2FA for ssh logins against the centralized LDAP infrstructure. The ssh-login 1FA is ssh pubkey (also in LDAP) and 2FA is TOTP. To achieve this we use a PAM module which does an ldapbind against the user-DN which has the userPassword schema '{TOTP1}'.
Maybe I wrong or outdated here and slapo-opt also supports TOTP-only authentication now?
Ok, makes sense. Yeah, OTP does not support that scenario at this time.
--Quanah
On 31Jan24 16:16+0000, Howard Chu wrote:
File a bug against the totp module. If it is using this attribute, it should be registering it in the schema during module initialization.
Do I understand correctly, that sbin/slapcat should also load initalize all modules from slapd config?
- Is it safe to continue as is or should we define the attribute "authTimestamp" in our schema extension as well?
It's mostly safe, unless you configured an index on authtimestamp and needed to run slapindex on it.
We have not indexed that. Thanks!
- Is the removal of attribute definitions from the schema not supported/suggested at all?
Never recommended, no. If you're retiring a definition, just add OBSOLETE to it.
Great! I'll revert the changes about that and will mark those attributes obsolete. The OBSOLETE tag is not specified closer in manual. The RFC says it is an indicator. I think, the tag is _just_ an meta data in the schema and slapd will mostly ignore it, right?
During the composition of this mail, further issues came up with slapd-totp and I would like to add some follow-up questions here. If you prefer, I'll write another mail or I could open an issue on bugzilla.
Open a separate issue in bugzilla.
Will do.
Many Thanks,
Bastian Tweddell wrote:
On 31Jan24 16:16+0000, Howard Chu wrote:
File a bug against the totp module. If it is using this attribute, it should be registering it in the schema during module initialization.
Do I understand correctly, that sbin/slapcat should also load initalize all modules from slapd config?
Yes, all the tools fully process the config.
- Is the removal of attribute definitions from the schema not supported/suggested at all?
Never recommended, no. If you're retiring a definition, just add OBSOLETE to it.
Great! I'll revert the changes about that and will mark those attributes obsolete. The OBSOLETE tag is not specified closer in manual. The RFC says it is an indicator. I think, the tag is _just_ an meta data in the schema and slapd will mostly ignore it, right?
Right.
openldap-technical@openldap.org