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.
“[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 ?
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.
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.
@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.