08-06-2018 03:27 AM
In the middle of a domain migration and users that have been migrated are not being identified correctly. The user that is logged into the new domain gets a blocked message but on the blocked message where it displays the username it shows their old domain \ username. (username being correct and the domain being the old one).
I have the user id agent running on both domains but user id is not listing the user correctly.
The users account for the rest of the network is working correctly.
Has anyone else come across this?
08-06-2018 04:19 AM
what is the ip mapping timeout set to on the agent.
if this time has elapsed then there should be no record of this user on the old domain mapping.
if it is being renewed then perhaps something on the users device is still auth'ing to the old domain.
08-06-2018 04:23 AM - edited 08-06-2018 04:24 AM
I assume you have a two-way trust between the domains? And the computers, are these also migrated or only the useraccounts?
08-06-2018 05:17 AM
yes its a 2 way trust, only user accounts have been migrated
08-06-2018 05:21 AM
@Mick.Ball probing is set to 20 mins.
if I turn off "enable Session" from the user mapping user id agent set up tab under devive-iser identification then the user displays correctly but we now get a TLS error for all users so had to turn it back on.
08-06-2018 08:24 AM
Are all users allready migrated or are they migrated slowly over time? Do you use Microsoft Exchange and if yes, do you have these also configured as source in your User-ID Agent configuration?
08-07-2018 01:06 AM
08-07-2018 01:50 AM
would it not work if you added the migrated users (now and as you migrate them) to a user exclude list on the agent pointing to the old domain.
08-07-2018 02:02 AM
Unfortunetely in this case I cannot really help. I had the same problem. We are also in a domain migration where users get new computers which are joined to the new domain but the users were not migrated at the same time they receive the new computer. In my case we don't even have User-ID but the users show up anyway with "olddomain\user" AND "newdomain\user".
As soon as the users are migrated and so user and comouter are in the new domain, the problem was gone. Adding exchangeservers would also help in your case, but I undersand that this could be difficult with O365 (unless you have exchange on premise). Maybe @Mick.Ball has a good idea to solve this, but my recommendation is: Use as much User-ID sources as possible where you get the mapping from the new domain (Global Protect internal gateway, Captive portal with Kerberos/SAML single sign on, ...). This way the mapping from the old domain should be overriden as fast as possible (like the situation you have with server session read).
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!