I am seeing a good deal of these warning messages in my server logs. I have noticed that it is always the same exact OU’s in each message, different CN’s though. As though Ignition doesnt like something about that branch in the OU tree.
Thoughts?
“[profileName=ActiveDirectory] Unable to read group attribute “cn” from group “CN=some-group-name,OU=some-ou,OU=another-ou,DC=domain,DC=net”, using distinguished name instead.”
i think i need more info to be able to answer anything…
Can you screenshot your AD User Source config (anonymized).
you have what type of domain ? tried other Domain Controllers ?
Where is this OU in relation to any source filters or LDAP filterts you may have setup ?
Does this OU have any odd attributes or difference with any other OUs in your domain ?
what IS the group name exactly in question ?
also what is in the Role Search Filter ?
I for example have this :
(&(objectClass=group)(|(CN=IGN_ADMIN_GROUP)(CN=*TEST*)))
This returns me the IGN_ADMIN_GROUP and any other group in the Search Base that has TEST in the name.
I found this page very helpful for getting my head around LDAP filtering syntax : How to write LDAP search filters | Atlassian Support | Atlassian Documentation
Hi,
Did you solve the problem with the warning messages about group attribute “cn”?
No, never solved the log issue, unfortunately.
I've been having these log messages for quite some time as many of you likely are too. It's been difficult to track down, but I think I know partially what is causing it, but I'm not sure how to resolve it. Maybe someone from IA can chime in here.
These warning messages aren't coming from any of the user or role search base or filters, as many have alluded to. Those are used to add groups and members to the Authentication profile used by Ignition in various forms (i.e. security on graphics and tags, Call Rosters, etc..) Instead, these are coming from the actual query of the user records when authenticating. When the authentication occurs with AD, we are running an LDAP query, looking up specific information on the user, one of those being the roles the members a part of. The default is memberOf, which queries for AD groups the user object is a member of, which gives us the Ignition Roles we manage all the other things on. What I have found is that some users have AD groups in memberOf that no longer exist, and seems to throw this error. My best guess is Ignition is attempting to grab information on the AD group, perhaps even a recursive lookup (for nested AD Groups), and because the object isn't found, AD is returning an error. The warning message, however, is misleading, as it says its using the distinguished name instead, but I'm guessing that is just some sort of internal logic that this gets default to.
What I'm attempting to experiment with now is if turning off the Cache Validation Timeout will eliminate this, as the issue is limited to a very small subset of users that are in my user filter. This isn't ideal, as the caching helps speed up processing time significantly for typical authentications, so I want to leave this on preferably. The other option I've explored is setting the logging level on UserSource.ActiveDirectory to ERROR, as this will eliminate the warnings, but still show error messages, but if anyone ever uses the "Reset Defaults" button on the config page, it wipes this out. Not a good long term solution. The only other way that I know to clean this up is to fix the users that have AD groups associated to them that no longer exist, but that is likely not going to happen easily in my situation (very large and complex organization). Not sure where to go from here.
Anyone else have any thoughts?
its been a while since i looked at this, but i seem to recall tracing down all the roles hitting that error coming from a particular AD OU that we didnt have permissions on. I dont know if that was the cause of those AD groups appearing in this manner, but after that I kinda gave up.
This all makes sense to me, I don't have a solution but I definitely have a few large client projects that are plagued by this pretty consistently.
Our solution has been to change the default logging level for AD problems to Error in the logback.xml file and essentially ignore the problem. We have created a few support tickets before, and never had it resolved.
yep, i essentially did the same. just not as elegant...i updated the filter settings each time i needed them out of the way lol. I toyed with all the search and user filters for a long time, but it was how those AD groups were coming in and I couldnt find a filter that would catch it.
One way to validate if the group exists or not is just to run a lookup to see if you can find it. For the example above, you could, on Windows using the Command Prompt enter the following command:
net group /domain some-group-name
If you get a list of users, it exists and isn't your likely cause, but if you have another group nested or you get a The group name could not be found message, you might have to try the other group name or it just plain doesn't exist.
The trick is finding the users that have this stranded groups. In my case, these seem to stem from Email Distribution Lists (which I am able to search on), and trace it back on that some.
Where do I find this? I've never heard of this before. I might need to check this out.
If you look in your install directories data folder, you will find a file called logbook.xml
That file determines the built-in logging done with logback in java.
If you add an xml key in it with the following:
<logger name="UserSource.ActiveDirectory" level="ERROR"/>
It will limit whatever logger you set to have a default level of whatever you provide it.
Note: I believe this only goes into affect when the gateway starts, if someone hits "Reset logging levels" in the gateway webpage, it will go back whatever its programmed to be by default.
Logback can also be used to enhance the native logging and push logs straight into a db, a different file, etc.
@Herbie I was finally able to resolve this issue with the help or our IT department. Essentially we have two domains and started to run into the issue of LDAP referrals sending queries across the country and timing out logins. When we set the LDAP referral to ignore we got the thousands of errors of could not resolve group CN=.
To address our IT had us repoint the Domain Controller ports from 389 to 3268 to allow the ldap queries to run against the Global Config of all domains instead of just the single domain controller.