Worked in the IT industry for the past 22 years with the last 11 as a consultant at CDW. Focus is on network security with a primary emphasis on Cisco ISE.
Born and raised in Wisconsin and still reside there today.

Bringing this back up again as I didn't hear any response to this original post. This doesn't seem to be isolated to 16.3.6 and I am seeing it more frequently when applying CPL template. It is hard to correlate, but it may be the backup stack master reloading. Most often it is the second switch in the stack.
Has anyone seen this in their deployments?
... View more

Has anyone else had issues with 3850s running 16.3.6 with one member of a stack reloading after you convert to new-style in preparation for applying the CPL template? There seems to be no rhyme or reason to it. I can deploy to 10 stacks and maybe on 3 of them one of the members will reload. It is always only one member in the stack.
Everything comes up fine after the reload and my templates work just fine.
Very strange one that is hard to pin point.
... View more

Yeah the user story for doing this would be highly appealing I think. In my discussions with customers, the permissions needed for WMI polling of the DCs or installing an agent on their DCs are not appealing options. Installing an agent on a member server acting as a log collector is an easy sell. Thanks for the quick response Tim. Paul Haferman Office- 920.996.3011 Cell- 920.284.9250
... View more

Tim, Question on this. I believe the format of the forwarded logs is the same as the log format on the DCs themselves. The logs reside in a Forwarded Events log vs. Security Logs in the Event Viewer. Why can't the DC Agent be coded to allow you to select the Forwarded Events log? Putting the DC agent on a pair of event collection servers looking at the Forwarded Events log vs. doing WMI calls to the DCs or installing DC agents on all the DCs seems like a much better option.
... View more

Thanks it worked perfectly: interface GigabitEthernet1/1 cts manual no propagate sgt I haven’t tested to see if that change affected my ability to do SGT based ACP rules, but I would doubt that it does. Paul Haferman Office- 920.996.3011 Cell- 920.284.9250
... View more

By default the interfaces on the FTD have the following: cts manual propagate sgt preserve-untag policy static sgt disabled trusted Is there any way to turn off the propagation of SGT tags? We are using pxGrid to provide IP to SGT tags that we can use in our ACP. We have no need to have FTD apply that tag to a packet on egress. Is it possible to turn that off?
... View more

Here is how I handle it with Full ISE which should be very similar to ISE PIC: Once I get my full deployment put together I like to make sure the internal CA is truly reflective of the deployment setup. Go to the Certificate Authority Certificates screen in ISE and delete all the certificates. Then go Certificate Signing Request screen and generate Certificate Signing Request. In the drop down for certificate use select ISE Root CA. This will recreate the entire CA/SubCA structure for the Internal ISE CA. Now if you look at each of the nodes (assuming running 2.2) you will see a cert from the internal CA installed on each node. Set that to be your pxGrid cert. Go back to the Certificate Authority Certificates and export the Root CA cert which will be on the primary admin node. Now the CA is ready to rock and you have the root CA cert you need for FMC. Now you are ready to issue certs/private keys from ISE. Skip the BS of trying to do any of this on the CLI of FMC or using OpenSSL. Go the pxGrid Services screen and generate a new cert without a CSR which will give you a cert and private key you can export and install on FMC. Also on the pxGrid section enable automatically activate/approve certificate based authenticated pxGrid clients. No need to approve these connections when you are generating all the certs from ISE in my opinion. Finally on FMC you do the ISE integration and point to your primary and secondary pxGrid servers. The root CA cert is loaded for both root CA options. Install the cert and private key you generated from ISE pxGrid services. Now you can run the connectivity test. To really ensure it is working go into a rule in FMC and go to the SGT section of the rule and verify you can see the SGT tags and profiling groups coming from ISE. FMC integration with ISE pxGrid using internal certs is very straight forward.
... View more

Tim, All member servers are allowed to automatically WMI poll DCs for security logs? Or how is the member server getting the security logs from the DCs? In other solutions even when you deploy agents on member servers they need AD credentials to make WMI calls to the DCs. I am sure I am missing something. Paul Haferman Office- 920.996.3011 Cell- 920.284.9250
... View more

All, I wanted to put some of my thoughts down in ISE Passive ID and cofirm what I am thinking as we lay this out for customers. Please let me know if I have anything incorrect or am missing something. I am listing the Passive ID options in order of how I would prefer to implement them: Option #1- Agent Installed on Each DC Advantages Only requires elevated privilege account to install the agent. i.e. no persistent service account needed. Removes polling requirements from the PSNs. No WMI modifications on the DCs. (registry settings, CIMv2 modifications, etc.) Disadvantages Requires the installation of a service on the DCs which some customers may not like the idea of. Scalability and Performance Can scale up to 100 DCs. In terms of performance, I would think this would be the middle performer of the 3. The workload is offloaded from the PSNs, but I have 1:1 feeds coming into the PSNs from the agents. Option #2- WMI Queries from the PSNs Advantages No services required on the DCs. Disadvantages Requires elevated privilege service account. Account in Domain Admins is the simplest, but that won't fly with many customers especially if you ask for a non-expiring password service account. WMI modifications on the DCs. (registry settings, CIMv2 modifications, etc.) PSNs have to perform the polling work adding load to the PSNs. Scalability and Performance Can scale up to 100 DCs. In terms of performance, I would think this would be the worst performer out of the 3 options as the PSNs have to do all the work. Option #3- Agent on Member Servers Polling up to 10 DCs Each Advantages No services required on the DCs. Aggregate information at a 10:1 ratio before feeding the data into ISE. Disadvantages Requires elevated privilege service account. Account in Domain Admins is the simplest, but that won't fly with many customers especially if you ask for a non-expiring password service account. WMI modifications on the DCs. (registry settings, CIMv2 modifications, etc.) Need member servers provisioned for this role at a 10:1 ratio. Scalability and Performance Can scale up to 100 DCs. In terms of performance, I would think this is the best performance since it is aggregating the data so the PSNs have less data sources to deal with.
... View more

Yep I understand what Umbrella sites are and my question laid out the exact issue with Umbrella’s site design. AD authentication information is local to a domain controller only, so you have to make sure your Umbrella Site includes all the domain controllers a user can authenticate against (just as the appendix says). In my scenario of large U.S. customer with 100 remote offices each with a DC and two datacenters each with 3 DCS tell me how you can break that up into more than one Umbrella site? It is a simple Venn Diagram when you look at AD authentication. Sites and Services define your DCs into logical sets. In this case I have a 100 logical sets (each remote site) with a common intersection point of the datacenters that are allowed to authenticate all users in the event the users local domain controller fails. The Umbrella site must cover the entire Venn Diagram to ensure accurate user to IP mapping retrieval. Or at least that is how I read it and the reason for my question. Thanks for the response. Paul Haferman Office- 920.996.3011 Cell- 920.284.9250
... View more

As I am deploying Umbrella into larger enterprises the one red flag I am coming across is the Windows Connector piece. I haven't found exact hard number on how many domain controllers the Windows Connector service can handle, but I have been told 25-30. The issue with that is there is no way other than Site definitions to control what Connector servers poll what domain controllers. As soon as you assign a domain controller to a Site the connector services will start polling it. I typically setup two dedicated Windows Connector servers at the customer. Breaking up a large customer into Sites in Umbrella doesn't often work since the layout of the customer's network won't allow it. Consider a large U.S customer with 100 remote sites and two datacenters. Each remote site has a local domain controller (DC) and local DNS server. They also have DCs back in the datacenters to authenticate users whose local site DC has failed or to service very small remote offices that don't have DCs. For the sake of this post lets say there are 3 DCs in each datacenter bring the total to 106 DCs. There is no way to carve this setup into more than one Umbrella Site. I am guessing the long term answer is pxGrid or something, but is there anything that can be done in the short term? The lack of multiple AD domains being supported under a single Org is also an issue, but that is for a different time. Thanks
... View more

As was previously said this is normal behaviour. In a layer 3 ACE deployment like you have: 1) Client side resources cannot ping the server side ACE interface. 2) Server side resources cannot ping the cliend side ACE interface. Think of the ACE as an ASA. If you are on the inside of an ASA firewall you cannot ping the DMZ and outside interfaces. Paul
... View more

Gary, You don't need to do anything special. It is all part of the auto-discovery process. When the middle WAE receive the SYN from the client it will already have TCP option 21 set so the WAE will know it is not the closest to the client. When the middle WAE receives the SYN ACK from the server it will already hat the TCP option 21 set so the WAE will know it is not the closest to the server. Now it know it is the middle WAE and will simply pass the traffic back to the router. Paul
... View more