Cisco ISE Downloadable ACLs

[ifabrizio]

Dear All,

I am configuring the AAA with ISE 3.0 Patch 5 two Nodes deployment.

I have setup the EAP-TLS authentication for wired and wireless clients, all works as expected. Now I am working to authorize the clients that belongs to a Microsoft Windows Domain, I have setup some policy roules on the ISE and the ACLs are downloaded on a WS-C4510R+E, with WS-X45-SUP8-E version 03.11.07.E.

The Authorization works and also the ACLs are dowloaded.

But I have a question about the effectiveness of ACLs, since the windows client to operate correctly must be able to use the dynamic RPC communication ports which, as you know, have a very wide range.
What's the point of using ACL , if you then need to open a huge range of ports?

[ahollifield]

Well it depends on the environment and the endpoint.  What is your use-case for restricting these domain joined windows workstations?

https://www.cisco.com/c/en/us/products/collateral/security/identity-services-engine/identity-service-engine-software-3-0.html

[ifabrizio]

Hi Ahollifield,
the scenario i'm in has a microsoft domain with PCs belonging to it, from the various departments.
The ultimate goal is to allow only necessary traffic between PC and Domain Controller, and block traffic between PCs.
This should help mitigate a possible Malaware infection like ransomware.
This for me represents the first step, then I would like to implement SGT tagging.

[ahollifield]

Yeah I mean part of deciding what should go into a dACL is a balance between security and what is actually required from a connectivity standpoint. 

[Karsten Iwen]

The moment you open the ACL you already know that it is quite trustworthy PC as it is one of your domain computers. But all other devices are still restricted and can't access your DCs. I would say this is already a huge improvement.

[ifabrizio]

Hi Iwen,
I agree with you.
Reading the ISE Admin Guide 3.0, I saw that to configure the Passive Identity several steps are recommended to be performed on the Domain Controllers, which I have already done. One of these configuration steps the number 5 is particularly interesting, from an ACL perspective:

"Make sure that you have created a firewall rule to allow traffic to dllhost.exe on Active Directory domain controllers.
You can either turn the firewall off, or allow access on a specific IP (ISE IP address) to the following ports:
• TCP 135: General RPC Port. When doing asynchronous RPC calls, the service listening on this port tells the client
which port the component servicing this request is using.
• UDP 137: Netbios Name Resolution
• UDP 138: Netbios Datagram Service
• TCP 139: Netbios Session Service
• TCP 445: SMB
Higher ports are assigned dynamically or you can configure them manually. We recommend that you add
%SystemRoot%\System32\dllhost.exe as a target. This program manages ports dynamically.
All firewall rules can be assigned to specific IP (ISE IP)."
Therefore, using the Windows firewall on the Domain Controllers, as described above, the ports to be opened on the DC side would only be the non-dynamic ones, which would instead be managed at the application level with the DLLHOST.exe.

That is about the communication between ISE and DC. Is it true also for the communication between clients and DC?

There is any use cases about it?

[Karsten Iwen]

The access-control that you just mentioned is not controlled by your ISE and with that is not a DACL. The DACL for your authenticated machines and user will likely also include similar lines like these for user-authentication and pushing of GPOs to the client.

[ifabrizio]

Yes I know that Windows firewall is managed by DC operative system.

What I mean is that if it is true that by configuring DLLHOST on the Clients Windows Firewall, the RPC ports are managed at the application level, it is no longer necessary to include them in the DACLs applied on clients. But it would suffice to specify the non-dynamic ports above.

There is any use cases about it?

[Karsten Iwen]

The DACL also need to allow this traffic (or better, all ACLS on the way end to end). But with the proper host-ACLs in place you perhaps can accept a broader open DACL on the switch-port.

[hslai]

@ifabrizio This is for ISE Passive Identity feature and, more specifically, to enable a Microsoft Active Directory domain controller as a WMI provider for ISE Passive Identity. In such case, ISE is simply getting the AD authentication records from the domain controller's security logs, but is not participating in the authentication "actively".

Since you are doing "active" auth, you do not need it.

[ifabrizio]

https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/create-inbound-rules-to-support-rpc

Following the link above seems that the RPC ports will used only when the DC server reply to the Client connetion request on port TCP 135. So the DACL is applied to inbound traffic, we can open the RPC dynamic ports only on the DACL on the Server side. On the client side we open only the port TCP 135. Is it correct?