User-ID: Require some guidance on best architecture for UserID deployment

[jezkerwin]

Hi everyone.

We currently have a small rollout of UserID across 2 of our firewalls across 2 sites. I think there are some gaps in performance and redundancy and I'd like people's opinions about the best way to deploy UserID.

Bit of background about our environment. 

We have approx 40 domain controllers spread across 2 domains over 10-15 sites

User accounts exist in both domain domains

Computer accounts exist in 1 domain.

Each site has a PA Firewall with multiple vsys, zones, vlans etc.

Right now we have 1 UserID agent installed on a server that queries all the domain controllers of the computer account domain in the HQ site, the FW at that site queries that user-id agent.

At the next biggest site, the userid agent is only query the DCs for that site and the FW at that site queries the local userID agent with a backup at the HQ site.

I'm sure this isn't the best way to do it, so I welcome any suggestions on how to improve.

Thanks.

[OtakarKlier]

Hello,

I would say have each PAN connect to both user-id agents. Also if you are using Exchange, I have seen great results in using the agents to query the exchange systems fro user-id lookup due to the frequency of Outlook to Exchange connections.

Regards,

[Remo]

Hi @jezkerwin

Do you need User-ID data on all firewalls and on all VSYS of theses firewalls or only on specific ones? Do you use panorama for firewallmanagement? Is there a domaintrust between these 2 domains? 

As mentionned by @OtakarKlier querying the exchange servers is a very good solution but not always if you need the mappings as soon as possible after a user logs in to his computer. This changes a little if you use skyper4business as this software is in most cases the first software that starts (if autostart is enabled), and as skype4business relies on exchange for a lot of features the alternative with the exchange servers becomes pretty good also in this case.

But to complete the whole story I would recommend both and depending on your answers to my questions we could recommend a good solution (even if you are already pretty close to a good solution except for the redundandency).

Regards,

Remo

[jezkerwin]

Thanks for your reply.

At the moment, we don't have a need to use UserID across firewalls and VSYS, however I do see a need in the future so I would the answer to that question is yes. We use Panorama and all the firewalls are configured to talk to it. we use it for firmware updates but due to the nature of our enviornment, we're not using it for rule managmenet. The domains do exist within the same environment so there is a trust between them. 

I didn't know we could use Exchange. In some cases a user would be using a workstation that doesn' have Outlook. The exchange environment sits in a resource type forest, there is a forest trust between those domains. We use OCS that for most people starts automatically.

I think the questions are still open for me are, do I continue to use direct polling to the domain controllers or implement something with event forwarding, the location of the userID agent on the network for best performance and the firewall configuration to query them and how to implement redundancy incase one of the userID agents fails.

Thanks again for your help.

[Remo]

Hi @jezkerwin

Allright I still see multiple ways about how to do it right in your environment. Let's start with the way I personally prefer: Direct polling. For the redundandency part you simply install a second User-ID agent server. Both servers poll ALL the domain controllers. Because of the domain trust it should also be possible to poll the domain controllers from the second domain with one single service account and you could there also configure the exchange servers to query these sources also for even more acurate data. On all your firewalls (and on all vsys) you then configure these two user ID agents and you will have consistent and acurate User-ID mappings everywhere in your firewall infrastructure. Simple and easy to achieve 😉 This solution requires reliable connections from your HQ (where you install the agents) to all the sites and if you are really, really concerned about the bandwidth to your sites you could use the same agents servers and configure event log forwarding from all domain controllers to these two user ID agents. Only if every bit/s of bandwidth matters I would use the event log forwarding method.

If the connection between the sites and the HQ is not that important and might fail without big restrictions (for examlle if all the firewalls in the sites have local internet connections and also if you have the important ressources distributed to all sites), the first proposed solution might not be the best one. In this case I would recommend using agentless User-ID agent on all the site firewalls to poll all the coresponding domain controllers at the sites. This way the site firewalls will continue to have user-id mappings also in case of the connection to the HQ fails. If you go this way you could theoretically dispense with the user-ID agent servers but then you need to configure user-ID redistribution between all and every firewall to have consistent data in every case on every firewall. So also in this case I would still use the user-ID agent servers.

Another possibility would be to use panorama for the redistribution of all user-id mappings, but this obviously requires a HA panorama because without that you are again at the non-redundant point as you are now.

Regards,

Remo

[jezkerwin]

Thanks for your reply @Remo, 

Aren't there some features that Agentless UserID doesn't haved compared to the Agent?

The problem I had when the remote firewalls were talking to the Core UserID agent was the time it took for the database to update with the IP address, so some users were waiting a long time for the rules to reconigse they had logged onto the network.

I suspect I have some configuration settings in terms of time to retrieve logs, etc, aren't configured correctly (I've just used the defaults of the agent install).

While our network links don't go offline that often, I wouldn't describe them as reliable which is why I went down the path of local UserID agents at the main datacentre sites other than HQ.

Perhaps I could look at the panorama to distribute the database.

The other option I was thinking is this.

We have 2 sites that are the biggest. each site has 2 x userID agents installed and configured. The F/Ws at those sites are configured for the local UserID agents. then those local F/Ws are configured to distribute their databases to all the other F/Ws in the environment.

[Remo]

The differences are:

• Agentless UID Agent does not support Nebios probing
• Agentless UID Agent requires less bandwidth for reading DC logs as only the required event IDs are transfered compared to the UID agent which reads the whole security log
• Agentless UID Agent has a max. of supported DCs for querying per HW platform and you need to keep in mind that too many DCs could have an impact on other functions like dynamic routing, logging and other processes that run on the management plane

When you had these user-ip-mapping-update problem, it could have been related to the configured log reading frequency. I always configure this value to 1 second, because we also rely on fast updates in order to make some access possible. If you configure this value also to 1 second you should have the data pretty fast, as the agent sends updates to connected firewalls - the firewall does not have to poll the agent to receive the updates.

In your highly distributed AD design you need do make sure that you connect to all DCs to always have the latest mappings and even more important to get the mapping as soon as possible after a user logs in. 

Because of that I would still try it with 2 agents that query all the DCs. This configuration should work and you have low-complexity-straight-forward config of the agents which you can distribute to all firewalls with a template and you do not need to configure various UID redistributions back and forth between your firewalls. As you don't absolutely trust the connections to the sites you could configure the site DCs on every branch firewall to continue to have updated ip-user mappings even when thw WAN connection goes down, but this one you probably don't need to redistribute to all other firewalls as it isn't that important to have this mapping when the connection is down anyway. Simply configure a timout of the mappings of about 4 or even more hours and it should be good (as long as the users are mostly static on one computer / IP).

As I already wrote, panorama is an alternative, pretty good one actually in your case. You could use the agentless way and keep all firewalls in sync with the redistribution. Here I only assume that this way also works with pushed updates and nit polling, but I never tested it by myself. And if you require the redundandency as you mentionned, you also would need a HA panorama. If you already have that - go for it 😉

[Sec101]

This is good info