Multi-domain/child domain group mappings

[JHartley49690]

We are in the process of moving two old domains into a new domain with child domains and have been having some issues with UserID and group mapping applying the wrong domain to users, which in turn makes it so the correct security policies don't apply.  The general setup is this: Old1 and Old2 are the old domains (neither has child domains); Root is the new domain which has several child domains set up as Child1.Root.com, Sub.Child1.Root.com, Child2.Root.com, and a few more.  We have full domain trust across the forest.  All new domain users (other than IT) are in the Child domains, but the URL filter groups are in the root domain.  We are still in the process of migrating users, so not everyone is on the new domain yet.

What happens is a user will connect, say Child1.Root.com\Test and will show up properly in traffic monitoring as Child1\Test and get the proper group mapping, then it will change them to Root\Test and no longer apply the correct URL filter.  I'll watch it for a while and it will bounce back and forth occasionally.

I set up a Global Catalog server profile on port 3268, as I have read is the way to map child domains, and have another profile set up with the two root domain controllers.  The user ID group mappings are pointed to the Global Catalog server profile, though I have tested one profile for a particular child domain to use the second server profile with the root domain controllers and have seen the same issue.  This is also an issue with some users on the old domains, they will show up as Root\User instead of Old2\User.

[S.Cantwell · Accepted solution]

Howdy there.

So..the FW is only gaining information that is otherwise collecting from the various security logs on the DCs in environment.

It is difficult to ask the question like this.. but WHY are the DC's sending conflicting information to the FW?

Seems like a rather unusual question to ask, but I do believe there is only a single service account (from the DC) that has been configured on the FW.

So the FW, uses this service account to collect the groups and DCs that it can communicate with (meaning, configured to talk to) and this comes from the FW admin under the UserID ==> Server Monitoring.... so the FW only collects what it receives....  Make sense?

So working backwards... I am presuming you have UserIDAgent (standalone software) on the DCs for Root and OLD (vs using the Integrated UserID on the FWs)

Either way, I think there is a need to go back and confirm the Group Mapping settings the FW, and perhaps prepend and filter out information.

What have you done (if anything) to all tab on this screen (including Server Profile, User and Group Attributes).. are you using the default (blank) or have you made changes here?

It just generally "feels" that your UserID agents, are continuing to pass conflicting info to the FWs, and the FW is merely updating its logs, based on information it is receiving. 

Based on what response we get back, we may be able to determine next steps.

Thanks.

[JHartley49690]

From what I see when looking at the user agents they are almost always grabbing the correct user IDs, but occasionally will still grab the incorrect one (Root instead of OLD or Child[X] domain).  We have 1 agent on each of the old domain controllers, and 2 agents set up on the new domain and they appear to both grab the same information from what I have seen so far.

For the group I have been doing testing with, I have added the server profile on the first tab, leaving the default in Group object class as 'group' and I have tried leaving the default in User object class as 'person' though I saw elsewhere you should change it to 'user', though that did not appear to change anything.  On the User and Group Attributes tab everything is default, and the Group Include List tab I have just added the necessary group from AD.  I should note that this is mainly being used for URL filtering so we set up a Universal group in the root domain and have linked the child domain users to that (not with nested groups, I read that the PA will not work with nested universal groups).

A question I have and have been unsuccessful in finding an answer is: I know I need to add the global catalog in the LDAP profiles with port 3268 to map the domain, then the LDAP servers on port 389 as a separate profile, but which one gets applied as the server profile in the group mapping?  In my test group I am using the LDAP profile, though I have tried the GC profile and had pretty much the same results.  The odd thing is that the two old domains are seeing the same issues (showing as Root\User instead of Old\User) and they are using LDAP ports only since neither of the old domains have child domains.

Thanks for your help, it is much appreciated!

[JHartley49690]

With you being so sure about it being an agent issue, I went and double checked all the settings on the agents and come to find out there was one setting different between them, Enable Server Session Read.  I changed the one to 'no' and everything appears to be working, though I'm going to monitor it over the next day and see how things showing up.  So far with my test account it appears to be working correctly.  Also with things (seemingly) working how they are supposed to, I discovered that I do need the Global Catalog server profile set for the group mappings otherwise it does not apply the correct security policy even though the user is showing correct.  Thanks again for your help!  I'll reply again if the issue isn't fixed, but it is looking like it might be.