Windows Server 2019 issues

Copper Contributor

We are using a palo alto 3050 firewall with the integrated user identification feature. It probes our DC's and client workstations to map usernames to IP addresses to appropriately assign security policies on the firewall.

 

Previously, I was running server 2012 with no issues on the user to ip mapping. I am now running server 2019 version 1809 on all DC's and I am running into some issues. Any time a new user signs into the network, they are mapped to the computer they signed in on, and they are also mapped to the domain controllers IP.

 

The users are only mapped to DC's that are Read Only dc's. I know the firewall probes the DC's and client workstation using WMI to extract event logging information. Did something change from 2012 to 2019 on how events are logged for login? I am completely stumped and palo alto support has done more than enough digging on their end. It is receiving that information from my DC, so the issue has to be there. The strange thing that I also found is when the user is mapped to the DC, it is almost always DNS traffic being sent out first. Sometimes they stay mapped long enough to be able to use the policy for other traffic, but like I said, when a new user on the network logs in, the new user is then mapped to the IP of my rodc. It is occuring on 3 seperate RODC's. 

 

Any ideas? If I left out important information, excuse me as I am rushing to try to get this sorted out.

1 Reply

@Jrogers08 

 

Do you by chance have the user agent configured to look at the read only DC? Is it deployed on every DC in your environment? Is the sites and services subnets configured for the users to go towards the read only DCs (RODC)? How did you do your upgrade? Did anything change infrastructure wise during the upgrade, like new IP ranges?

 

On the Palo side did they validate everything on this page to insure you are in alignment for supported config? Also do you use the credential service functionality? If yes, it looks like that is only supported on 2012/2012R2 RODC. Maybe if it's deployed on RODC's not for credential service maybe remove the agent from the RODC and see if behavior changes? 

 

In my environment I have it with server 2016 with no RODC in my environment and everything works great.