This is a two part series on integrating IA and Application Control into Active Directory AD.
Lately I’ve become an IA “expert” (insert smiley). Well I exagerate but I wanted to share some of the things I learned while App Control integrating into a large AD forest.
First step is integrating IA. IA is used for 2 things: authentication for access control by the gateways and identity translation by logging server. IA will keep track of what users are on what IP address. This is done by SmartCenter and gateways registering with AD via WMI to get notices of when people log in. NOTE: more specifically the gateways have to register with EACH domain controller at EACH site throughout the forest!!! Not just the top domain. The domain controllers keep track of logins/logouts, not the top level domain or the top global catalog.
The first thing is you need an AD expert to translate all the DC, OU, CN stuff. I am not it. What I learned is that if you have AD subdomains, your paths will be:
DC=sub,DC=domain,DC=top Example: DC=sales,DC=acme,DC=corp or sales.acme.corp
But if you have a site your path will be with an OU
OU=sub,DC=domain,DC=top Example: OU=sales,DC=acme,DC=corp
Sites are easier to manage because permissions are set all at the top and not each individual domain controller at all the sites.
Once you have this info you are ready to start. Go the the servers/OPSEC tab to create LDAP account units or the users tab to edit the units (right click).
One the first page you have to specify what domain you will be querying. NOTE if its a site you use the top level domain acme.com, if its a subdomain then enter the subdomain sales.acme.com.
I like to make the permissions read-only, no one can blame the firewall for screwing up AD.
I like to use wbemtest.exe in Win7 to verify DC credentials on a DC by DC basis.
Also add the Account Unit into the gateway’s IA configuration. See the picture below
Phase 2: Testing
So assuming you got all that working, the first test is going into the user tab and double clicking on an LDAP object to see if it retrieves AD information.
For sanity check you can tcpdump port 389 on SmartCenter to verify the query actually went out (sometimes it hangs). If this works, then theoretically you are a LDAP expert.
For extra points, remember these commands.
SmartCenter/LogServers uses LDAP to map login names to user names for the logs. The gateways use a similar command but for credentials and authentication. This is important for this next command
adlog l dc – ” l ” is for the log server and lists connectivity to the DCs for the Log Servers
adlog a dc – ” a ” is for authentication and lists connectivity to the DCs for the gateways
adlog is the process and database for the IP to User mapping. You can see traffic come from the DCs to the gateway and LogServer on port 1026, the AD port. make sure you are on the ACTIVE cluster member (or on load balanced probably the non-pivot) to get the latest results. Watch the last column for increasing event counts. These are events that DCs report back to SmartLog and gateways. This shows that the DCs are talking to the gateways and logging servers
adlog a query all
adlog l query all
will dump the adlog database of user->IP.
Make sure all have connectivity. If they don’t they you screwed up your credentials, DNs, firewalls blocking ports to the DCs. cpstop;cpstart works miracles too. Make sure your AD account is not getting locked out by looking in AD security logs.
If that works, then on the GATEWAYS you use these commands:
(WARNING: Insert grains of salt, I only get about 75% of the following. TBD work in progress)
pdp is the process that monitors user activity and keeps track of recent events coming from AD where credentials are required. File mapping is probably the most common, log in and some log outs(if someone formally logs out).
pdp monitor all
<insert picture>
Will dump all the users/machines and all the activity records associated with them. I usually pipe it through grep looking for user information ‘pdp monitor all | fgrep -i endrizzi’
pep is the process that is referenced to enforce security decisions based on user credentials. These processes can sync with each other throughout a network of firewalls that are participating in a AD Identity Awareness forest. There are optimization where firewalls share pep information and don’t have to get it from DCs and flood WAN links.
Anyways
pep show all (fix this)
<show dump>
Dumps user records showing which users are being used to enforce security decisions.
Bugs:
1) Fetch Branches will NOT verify credentials and will reset the DN string.
2) Hung LDAP queries: You can enumerate the LDAP tree, but port 389 will have NO traffic
and the query will hang. Suggest cpstop;cpstart
3) LDAP queries not all working, some DCs responding with no records: Suggest cpstop;cpstart, worked for me
4) Firewalls lose credential info – Make sure you put a username into the blocked pages in active portal. If these start coming up blank you know that firewalls are losing credential info.
5) NOTE: SmartDashboard does NOT verify LDAP account unit credentials for domain controllers!!! Make sure you get the right credentials. Check your AD security event log to make sure the LDAP account is not getting locked out. WARNING: You will get weird random rippled login failures that are a pain to track down. Sometimes it works, other times all the DCs are locked out. Has to do with the AD lockout and delay in DC replication.
Make Sure
5) Make sure you use domain\user to login
6) Make sure your LDAP account user has enterprise privs to make life easy otherwise I’m not sure what will
happen in real life
7) Make sure you enable “Assume that only one user is connected per computer” otherwise multiple users will be associated with an IP and the permissions accumulate. This is a good SK:
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk60301&js_peid=P-114a7bc3b09-10006&partition=General&product=Identity