About ucteam

I agree with mikand on this one.. especially in large dispersed networks.. manytimes installing on DC's is the best solution.. And if its not recommended architecture then Palo Alto should officially document that .. I'm fairly sure I remember multiple refreneces in PA documentation referring to Agents been able to be installed on DC's. And the proposed reasoning behind not installing on DC's.. 1.) "Load issues on a DC"..??  have you seen how much network resources (bandwidth) a remote Agent uses vs the CPU cycles and Memory when locally installed on a DC (ie. not having to pull all the event logs across the network). Agent cpu/memory utilisation is miniscule vs it's potential for bandwidth utilisation. 2.) "The domain controller could go down"...??  well if your thinking on a small scale and you've only got "one" DC in your network and it goes down your fairly screwed anyways.. and how does having it on another server reduce your risk? it just moves the risk/dependancy to another device.. now your dependant on 2 separate devices been up and running correctly in order for your authentication to work. Dont get me wrong I understand security and administrator concerns around installing third party applications onto devices as sensitive and trusted as domain controllers.. you need to review your options with how to plug in the PA to your authentication service and the best option will vary between different businesses/ networks.. When dealing with small systems/networks architecture is less important.. you could do it anyway and your not likely to have issues.. however on larger scales the architecture/ implemtnation type become vastly more important.. and making the wrong descision can have unfortunate consequences. ... View more

A warning for all.. you cant retrieve the membership of the "domain users" group in active directory (usually peoples "primary group") from the Palo Alto firewalls direct group enumeration. In active directory the "primary group" for each user (usually the "domain users" group) is not part of the list of groups the user is a "memberof". Instead, the primary group token (just an ID) is stored in each user's record.. So stick to your own created groups.. or utilise the "any authenticated user" option.. "domain users" is a no-go group... (well at least as far as a simple query goes..) ... View more

Oh yeah I should have mentioned.. depednding on your configuration  you might have to exclude these IVPump/ SCADA devices from your captive portal policy (if you use CP for fallback authentication). This exclusion can be done based on source ip/subnets or destination ip/subnets and protocols. ... View more

Though I do believe configuration snapshot "running-config.xml"  is the equivalent of the actual running config. So I do suspect both methods would work .. but the first is the more correct method.. at least from the GUI. From the commandline loading from "running-config.xml" is the only way I know of to discard the current candidate. e.g  # configure # load config from running-config.xml ... View more

I've experienced this issue also within the GUI when connecting to large ldap directories... Workaround was to add the groups by the CLI. Making sure to use full ldap path e.g set group-mapping GROUP_MAPPER group-include-list "cn=internet power users,ou=www groups,ou=groups,dc=xyz,dc=local" ... View more

Another point .. this information is perhaps out of date  "Each UIA can connect to up to 10 Domain Controllers" The older 3.x UIA Agents by "default" would monitor only 10 domain controllers, but if you manually edited the XML config file you could get them to monitor 100  e.g <max-dc>100</max-dc> I believe the new 4.x UIA have this setting by default now. ... View more

Yes I've successfully conected 100 UserID agents. All back to a single vsys. I've also requested that PA have the 100 UserID agent limit increased and the max DC's limit... as the limits seems arbitrary and unnecessarily restricts design options for large networks. ... View more

Enviroment I've worked on: 13k+ active users (expected to double in the next couple of years) 120+ domain controllers 180+ remote sites with WAN links varying from 4Mb - 10Gb Centralised internet gateway Very dynamic network, sites been mobilised/ demobilised usually on a monthly basis My opinion its great for large centralised and static enviroments.. were all you users are in a central location... However if you have a large disparate or spread out enviroment you might hit some issues with some of the undocumented limitations of the UserID agents/ architecture. -Each firewall can only talk to a maximum 100 userID agents -Each agent can only monitor a maximum of 100 domain controllers So if you have more than 100 DCs you CANT just push an agent out to all of them so that sec logs can be locally read and user-ip maps sent to FW.. Or the other way if you wanted to use a central agent to monitor multiple DCs (which unfortunately tends to generate alot of traffic across the WAN).. then you would need to install a minimum 4 agents servers.. (ie. 2 agents cos single agent can only monitor max 100dcs.. and another 2 needed to provide redunadncy) I really hope PA will increase these seeminly arbitrary limitations in the near future.. (amazinly the older agent by "default" would only let you connect to a max of 10 domain controllers... you'd have to edit a xml config file to get them to talk to more.) -- Some recommendations As PA recommend.. whatever your primary authentication method, it's usually worthwhile setting up captive portal/ NTLM auth as fallback authentication mechanism for any web users/ clients which slip through the cracks. Just be aware when setting up for NTLM authing that some browsers (e.g firefox) require manual configuration in order to support NTLM.. and they also maintian their own separate list of trusted RootCA's i.e they dont refernce the local windows certificate store (which you might be updating via grou policy etc)... so firefox users might get cert warnings when hitting the CP/NTLM redirect. Regarding you IV Pumps/ or SCADA style equipment, if you do already have these devices in dedicated VLANs but you cant trunk them all back to central layer 3 interface to push them through a dedicated interface/ zone on the firewall natively... you can potentially virtualise your network at a layer 3 level. Utilise a combination of VRF or VRF-LIte to create a separate virtual layer3 network instance and you could use mGRE or IPSEC/VTI to tunnel this traffic across your regular network back to a central interface connect through the firewall providing complete network isolation for your sensitive devices and then... apply appropriate policies on that zone/interface. Otherwise yes as you mentioned it is possible to put a non-authenticating policy before  your standard user web browsing authetnicated policy.. and as long as you specifying the trusted destination which can be accessed without authentication this could be considerded an acceptable level of security (depedning on your risk model). Which you could also further secure by creating a custom application signature and only allow the specifically required type of traffic. I find this suitable for things like printers etc that want to phone home across the net to their vendors to order more consumables or notify of problems etc. e.g Permit ***FROM*** src = 10.0.0.0/8  (be specific if you can.. but dont have to) user = any (ie. dont require authentication) ***TO*** dst = 1.1.1.1/32  ( be specific) port = TCP 577  App = IVPUMP  (create custom app signature) I believe Cisco's got big whitepaper on TrustSec/ NAC 2.0 style stuff spefically focussed on medical enviroments which may be of interest to you http://www.cisco.com/en/US/docs/solutions/Verticals/Healthcare/bnac_adg_2.0.html As already mentioned if you do implement a NAC solution these devices will be authenticated automatically by the NAC system (by profiling, eap or MAC address etc), you can then plug into these systems using syslog and the extensibile UserID api to get that auth information to the firewall. Enterasys has whitepapers out on doing this with Palo Alto currently, but should work for most any standard system. ... View more

I've also noted this issue in 4.1.4. when trying to change the default page and also when trying to modify an existing custom block page. I dont believe its a browser upload issue as I've verified the new custom block pages were included in the device config.. (they are stored in base64 encoded format directly in the config.) Rebooting the device (or possibly just restarting software services) will get a newly uploaded respone page to actually display properly but thats hardly a great solution for most businesses. ... View more

Page 164 from "PA-4.1_Administrators_Guide" FQDN: To specify an address using the FQDN, select FQDN and enter the domain name. The FQDN initially resolves at commit time. Entries are subsequently refreshed when the DNS time-to-live expires (or is close to expiring). The FQDN is resolved by the system DNS server or a DNS proxy object, if a proxy is configured. For information about DNS proxy, refer to “DNS Proxy” on page 125. I agree there is definitely still some mystery around how the DNS to IP mapping is dynamically reprogrammed into the FPG's for the security rulebase to be able to process at high speed.. I'm guessing something similar to an automatic partial/selective commit. ... View more

I believe the IP address is determined at commit time.. and then again periodically according to the TTL of the DNS record. I wouldnt expect much of a performance hit.. though cant say I've tested with more then a handful of FQDN objects.. I would really hope the Palo Alto wouldnt be stupid enough to accept a 0.0.0.0 address for a FQDN object .. or infact anything other than a single host /32. (but that would definitely be worth checking) Though I do acknowledge the general risk associated with relying on DNS for defining your access rules. Also on a similar subject ..  I think the last time that I tested I'm pretty sure if there are multiple "A" records defined for a domain name the palo alto only uses the first one it gets.. which might throw a spanner in the works if there's any DNS based round robin/ loadbalancing going on. Yet again functionality worth verifying yourself with your current operating version of PAN OS .. as usual the documentation from PA on many things is lacking.. ... View more

Any fundamental differences between the 2 deployments? ie. the one that is working and the one that isnt? ... View more

And yes.. correct.. the reason for deploying many UserID agents (i.e locally installed at each remote site with domain controller) is to reduce the network/ bandwidth utilisation. Whilst in theory the concept of having 2 central agents monitoring 100 domain controllers seems like a good solution.. unfortunately it doesnt account for common windows applications / active directory issues whereby sometimes users or computer accounts will begin authenticating 1000s of times (seemingly unnescarily) in the matter of a few seconds due to either poorly written applications or general issues with the windows operating system itself..  These excessive amount of successful authentication events which then have to be dragged across the network by the centrally located UserID agent can have a negative impact on the network if there is limited avaialble bandwidth on the WAN links. Also PaloAltos UserID agent limitation that it can only monitor a maximum of 100 domain controllers each is a bit of a pain..  Given that we have over 130 domain controllers it would require a minimum of 4 UserID agents centrally installed to monitor all domain controllers (with redundancy). So either dedicating 4 new servers to this purpose or deploying to 4 existing random servers seems messy when compared to been able to package up and just push out the agent to all existing domain controllers with a identical config file for each. ... View more

Jseals how large is your AD structure?  Im suspecting its relatively small? correct? I've been troubleshooting an issue with support regarding 4.1.3-4 direct group enumeration.. whereby the Palo Alto is only able to retrieve a small portion of our AD structure/ objects. Having similar experiences where from the Palo Alto am not able to browse the full structure and group enumeration for example shows only 26 users in "domain users" group when there is in fact over 27,000 .. When I change back to using LDAP proxy and a 3.1x userID agent the group enumeration works correctly. At first I suspected an issue with LDAP paging.. but packet captures indicated paging is working .. but seem to point towards some strange delays/timeouts towards the end of the session.. May be related to this discussion.. difficult to tell at this time. For the user having problems..  If everything looks to be configured correctly and your domain structure/ permissions are good.. then try doing some packet captures from the Palo Alto monitoring tab.. filtering on LDAP communications with domain controller. Would recommend temporarily changing to unencrypted TCP 389 for the LDAP bind so you can view the full LDAP protocol interactions. ... View more

I've heard the following may be documented on the Palo Alto internal KB: Platform Capacity Maximum number of pan-agents per vsys: 100 Maximum number of pan-agents per platform: 100 BUT I also revieved a reply to direct email recently stating that: Thats it's 255 for user agent. Terminal server agents are 255 except in the 5000 series where they can go up to 1000 ... View more