GlobalProtect remote access - some pointers

[Steve-Phillips]

Dear All,

I'm relatively new to Palo Alto firewalls and I am attempting to implement GlobalProtect to provide remote users with access to our internal network through the Palo Alto firewall and I am striggling to get even the most basic system working, so I wonder whether I could ask for some pointers for anyone who has got a working GlobalProtect remote access environment.

The problem I currently have is attempting to establish which authentication method should work successfully.

I have been attempting to get RADIUS working, but this appears not to work with our Active Directory, the authentication fails for both CHAP and PAP and looking on the AD security log, I see an error that states "The user attempted to use an authentication method that is not enabled on the matching network policy." As I have spent over a week on this trying various combinations of setup, I have decided this is not the way forward.

I just tried LDAP, but broke the firewall outbound Internet access, as I also use LDAP for user to group mappings in security policies, and creating a second LDAP server profile and authentication profile caused that mechanism to fail and block Internet access for all users for some reason I do not yet understand, so that feels a risky way to proceed.

I am now trying Kerberos, but it is not clear to me whether this is a viable authentication method for authentication to the GlobalProtect portal / gateway for a laptop out on the Internet.

Can anyone please provide some pointers as to which authentication method is likely to work in this scenario?

We have an internal Certificate Authority on our domain, and I have configured the root CA information into Palo Alto, so Ideally, what I want is to use a pre-athentication connection for a remote laptop so that it can connect to the portal / gateway using an internal Certificate Authority certificate in the certificate store of the laptop which allows an initial IPSec VPN connection.

Once that pre-auth connection is made, what I would then like is for when a user logs into Windows using their domain credentials, these credentials are passed through "single sign-on" (via the pre-auth VPN tunnel) and the user and laptop are granted full access to the internal network via the VPN.

The documentation states this should be feasible but I cannot fathom out the authentication methods to implement to facilitate this.

Any pointers to a real-world implementation of what I am trying to achieve would be greatly appreciated.

Many thanks in advance.

Regards,

Steve

[BPry]

@Steve-Phillips,

That's a big wall of text 😉 

Joking aside I would really recommend that you contact your SE or support and have them walk through the setup with you since you're really just at the beginning of even getting any of this configured. They can talk you through everything and answer any questions as they come up and will get you configured correctly, you'll just have to dedicate some time to working with them. Working through all of this through Live would be a little complex. 

[Steve-Phillips]

BPry, many thanks for the reply.

Indeed, that is rather a lot of questions, I realise that after I posted and read it all back.

All I was really after was a pointer to which stone I should step on first (the most appropriate authentication method) and work my way forward from there.

As you suggest, I'll approach support and see what I can learn from there.

Many thanks,

Steve

[Mick_Ball]

Steve, Hi.

LDAP works fine for me, although we only use it for IPads, or win7/10 are cert based authentication. (we do not use pre-logon).

I am surprised that after creating a second LDAP profile it caused issues to your user group policies.

did you apply that new (2nd) server profile to the group mapping or did it have the original server profile.

what you are trying to set up here seems perfectly acceptable but I would get LDAP working first prior to pre-logon. (or kerberos). I found LDAP very easy to setup and support. hence we stuck with it...

for me.. i would create a new LDAP profile and not link it to any service, then test it via cli "test authentication". perhaps you just did this already and crashed your policies.

laters...

[Steve-Phillips]

Mick,

Many thanks for your reply. I have been working on this problem for a month now, and I am still no further forward.  I have our Palo Alto reseller support team working on this, but so far thay have not been able to work out what is  going wrong, so I thought I would continue with this post.

I have settled on LDAP and I can successfully get a user authenticated when using the command line test, as long as the Authentication Profile Allow List is set to "All" (why this is the case is a mystery):

admin@PaloAlto> test authentication authentication-profile "Remote Access Users - LDAP" username zzztest password
Enter password :

Target vsys is not specified, user "zzztest4" is assumed to be configured with a shared auth profile.

Do allow list check before sending out authentication request...
name "zzztest4" is in group "all"

Authentication to LDAP server at 10.10.10.10 for user "zzztest"
Egress: 10.10.10.110
Type of authentication: plaintext
Starting LDAP connection...
Succeeded to create a session with LDAP server
DN sent to LDAP server: CN=zzzTest,OU=Test,OU=Users,DC=domain,DC=co,DC=uk
User expires in days: never

Authentication succeeded for user "zzztest"

admin@PaloAlto>

However, if I then attempt to log in to the GlobalProtect portal using the same user, I receive an "Authentication failure: Invalid username or password".

When this occurs, if I use the "tail follow yes mp-log authd.log" command to examine the authentication logs, I see the following:

2018-07-12 15:23:58.420 +0100 Error:  _get_auth_prof_detail(pan_auth_util.c:1060): non-admin user thru Global Protect "zzztest" does NOT have auth profile
2018-07-12 15:23:58.420 +0100 Error:  pan_get_authprofile_n_setting(pan_auth_util.c:1123): Failed to get authentication profile for non-admin user thru Global Protect "zzztest"
2018-07-12 15:23:58.420 +0100 failed authentication for user 'zzztest'.  Reason: Authentication profile not found for the user. From: <external IP>.
2018-07-12 15:23:58.421 +0100 Error:  _authenticate_initial(pan_auth_state_engine.c:2518): Failed to get authentication profile
2018-07-12 15:23:58.421 +0100 Error:  pan_auth_request_process(pan_auth_state_engine.c:3324): _authenticate_initial()
2018-07-12 15:23:58.421 +0100 Error:  _taskq_worker(pan_taskq.c:622): Error executing tasks process fn

I do have an Authentication Profile named "Remote Access Users - LDAP" with the following settings:

Type: LDAP

Login Attribute: sAMAccountName

User Domain: <blank>

Username Modifier: %USERINPUT%@%USERDOMAIN%

Allow List: All

This Authentication Profile is then referenced in both the GlobalProtect > Gateway authentication settings and in the GlobalProtect > Portal authentication settings. 

Also, as the Allow List is set to "All", surely this means that any user would match this Authentication Profile?

Any advice on this is much appreciated!

Thanks,

Steve

[Mick_Ball]

If your auth profile domain is blank, why are you using it in the modifier, just try “%USERINPUT%”.

[Mick_Ball]

Also.... why not use packet capture in monitor tab, set interface to default service route for ldap and set 2 filters, destination 10.10.10.10 from any and source 10.10.101.10 to any, you will need to disable secure ldap to see packets in wireshark. This will show you the exact user id and password the palo is sending.

[Steve-Phillips]

Very good point, I have changed this to %USERINPUT%. I have been experimenting with many combinations, that just happened to be the one it was left on, which was not the best choice.

Thanks,

Steve

[Steve-Phillips]

Using the packet capture is a VERY good idea, many thanks for that.  I shall investigate and report back in due course.

Thanks again.

Regards,

Steve

[Mick_Ball]

Also-2, you may need to add your domain in the auth profile as the all option may apply to a domain group “all” and not just mean “everyone”

or, add domain\all to the allow list.

i hope that make sense...

laters...