Details
-
Improvement
-
Status: Resolved
-
Minor
-
Resolution: Implemented
-
None
-
None
Description
I will briefly try to summarize my motivation on this, since guacamole got migrated to Apache Directory API ( GUACAMOLE-234 ) I began to see several messages like this on my logs.
- Approximately 8 times per-login (I have approx 80 user-logins per day, so logs get quite big because of this).
- This certainly has to do with my infrastructure (the attributed that is duplicated and the amount of logs), so pattern might vary and mostly being noticed on Active-Directory environments. Others already mentioned this and it`s shown in issue mentioned above. Other examples from a quick-search: example1 example2
- Logs are like these:
19:28:51.564 [NioProcessor-7] WARN o.a.d.a.l.m.entry.DefaultAttribute - ERR_13207_VALUE_ALREADY_EXISTS The value 'CN=DC1,OU=Friday,OU=Domain Controllers,DC=super,DC=awesome,DC=domain,DC=com' already exists in the attribute (msDS-RevealedDSAs) 19:28:51.564 [NioProcessor-7] WARN o.a.d.a.l.m.entry.DefaultAttribute - ERR_13207_VALUE_ALREADY_EXISTS The value 'CN=DC1,OU=Friday,OU=Domain Controllers,DC=super,DC=awesome,DC=domain,DC=com' already exists in the attribute (msDS-RevealedDSAs) 19:28:51.564 [NioProcessor-7] WARN o.a.d.a.l.m.entry.DefaultAttribute - ERR_13207_VALUE_ALREADY_EXISTS The value 'CN=DC1,OU=Friday,OU=Domain Controllers,DC=super,DC=awesome,DC=domain,DC=com' already exists in the attribute (msDS-RevealedDSAs) 19:28:51.564 [NioProcessor-7] WARN o.a.d.a.l.m.entry.DefaultAttribute - ERR_13207_VALUE_ALREADY_EXISTS The value 'CN=DC1,OU=Friday,OU=Domain Controllers,DC=super,DC=awesome,DC=domain,DC=com' already exists in the attribute (msDS-RevealedDSAs)
The key for me was, why was guacamole considering in any way attributes that are completely irrelevant like msDS-RevealedDSAs?
I made a few tweaks in the code to filter returned data from ldap using SearchRequest addAttribute and taking advantage of already "knowing" which attributes are really relevant (and looking forward to retrieve). In this way for example:
Instead of (wasting memory?) retrieving all the attributes an object might hold we tell SearchRequest to, in case of a group, get the attribute defined in configuration that hold group name (ldap-group-name-attribute) and the attribute defined in configuration that tells which attributes hold group members(ldap-member-attribute-type). The same applies for user objects.
In case of LDAP being used for connection storage (guac* attributes) the original "way" should be in place for retrieving anything as I can not replicate such scenario. Perhaps I am wrong, but I really need someone to help me out in this matter.
As for "normal" LDAP use, the pull request that will be submitted was tested, also ldap-user-attributes is being used so it's working OK (e.g. not being filtered out).