topic Re: LDAP authentication does not work for Global Protect Clients in General Topics

LDAP authentication does not work for Global Protect Clients

Farzana — Mon, 20 Nov 2017 06:04:50 GMT

Hello,

We have got a working LDAP server profile. We have made sure user 'test' is listed on the group mapping.

Steps:

a) Setup group-mapping under Device->User Identification->Group Mapping Settings. Under 'Group Include List' pick a specific cn.

b) Device->Authentication Profile. Add a new profile and add the same cn under allowed list.

Error: LDAP Authentication Profile test

=========================

Test with TEST-ldap-all which allows all domain users.test@TEST-PA> test authentication authentication-profile TEST-ldap-all username test passwordEnter password :Target vsys is not specified,
user "test" is assumed to be configured with a shared auth profile. Do allow list check before sending out authentication request...name "test" is in group "all"Authentication to LDAP server at 10.1.1.3 for
user "test"Egress: 10.2.6.4 Type of authentication: plaintext Starting LDAP connection...Succeeded to create a session with LDAP serverDN sent to LDAP server:
CN=Company,OU=ITDept,OU=User,OU=Ann,DC=test,DC=netUser expires in days: neverAuthentication succeeded for user "test"2.
Test with ldap profile which points to a domain global security group.test@TEST-PA> test authentication authentication-profile test-ldap-globalprotect username test passwordEnter password :
Allow list check error:Target vsys is not specified, user "test" is assumed to be configured with a shared auth profile.
Do allow list check before sending out authentication request...User test is not allowed with authentication profile test-ldap-globalprotect

Any thought on this?

Thanks in advance.

Re: LDAP authentication does not work for Global Protect Clients

mgarg — Mon, 20 Nov 2017 12:51:40 GMT

I see an authentication success message in the logs 'Authentication succeeded for user "test"2.'

Can you try connecting from Global protect client with the same user and share the output from the authd.log.

You can run a "tail follow yes mp-log authd.log" in the command line when attempting to connect from client.

Re: LDAP authentication does not work for Global Protect Clients

Farzana — Tue, 21 Nov 2017 05:04:52 GMT

@mgarg

Thanks for that. Below is the authd.log for user 'angusg'.

2017-11-10 21:30:29.084 +1000 debug: _get_profile_domain(pan_auth_sysd.c:890): auth prof "test-ldap-globalprotect" on vsys "vsys1" does NOT have domain
2017-11-10 21:30:29.084 +1000 Error: authd_sysd_profile_domain_callback(pan_auth_sysd.c:936): find domain for auth profile: test-ldap-globalprotect; vsys vsys1
2017-11-10 21:30:29.086 +1000 debug: pan_auth_request_process(pan_auth_state_engine.c:3306): Receive request: msg type PAN_AUTH_REQ_REMOTE_INIT_AUTH, conv id 24, body length 2128
2017-11-10 21:30:29.087 +1000 debug: _authenticate_initial(pan_auth_state_engine.c:2362): Trying to authenticate (init auth): <profile: "test-ldap-globalprotect", vsys: "vsys1", policy: "", username "angusg"> ; timeout setting: 25 secs
; authd id: 6486741776332750875
2017-11-10 21:30:29.087 +1000 debug: _get_auth_prof_detail(pan_auth_util.c:1057): non-admin user thru Global Protect "angusg" ; auth profile "test-ldap-globalprotect" ; vsys "vsys1"
2017-11-10 21:30:29.087 +1000 debug: _get_authseq_profile(pan_auth_util.c:856): Auth profile/vsys (test-ldap-globalprotect/vsys1) is NOT auth sequence
2017-11-10 21:30:29.087 +1000 debug: _retrieve_svr_ids(pan_auth_service.c:645): could not find auth server id vector for test-ldap-globalprotect-vsys1-mfa
2017-11-10 21:30:29.087 +1000 debug: add_info_from_auth_profile_to_request(pan_auth_util.c:1020): MFA is not configured for the auth profile. No mfa server ids for the user "" (prof/vsys: test-ldap-globalprotect/vsys1)
2017-11-10 21:30:29.087 +1000 debug: pan_auth_cache_user_is_allowed(pan_auth_cache_allowlist_n_grp.c:185): This is a single vsys platform, group check for allow list is performed on "vsys1"
2017-11-10 21:30:29.087 +1000 debug: pan_auth_cache_user_is_allowed(pan_auth_cache_allowlist_n_grp.c:310): user "angusg" is NOT in allow list of auth prof/vsys "test-ldap-globalprotect/vsys1" (vsys in request "vsys1")
2017-11-10 21:30:29.087 +1000 failed authentication for user 'angusg'. Reason: User is not in allowlist. auth profile 'test-ldap-globalprotect', vsys 'vsys1', From: 122.104.158.11.
2017-11-10 21:30:29.087 +1000 debug: _log_auth_respone(pan_auth_server.c:263): Sent PAN_AUTH_FAILURE auth response for user 'angusg' (exp_in_days=-1 (-1 never; 0 within a day))(authd_id: 6486741776332750875)
2017-11-10 21:30:34.963 +1000 debug: pan_auth_cache_get_authprof_info(pan_auth_cache_authprof_n_authseqprof.c:176): prof "test-ldap-globalprotect", vsys "vsys1" (method: LDAP (active directory)) has sso hash table id: 0 (0 means no or i
nvalid keytab)
2017-11-10 21:30:35.004 +1000 debug: authd_sysd_profile_domain_callback(pan_auth_sysd.c:911): profiledomain triggered via sysd
2017-11-10 21:30:35.004 +1000 debug: authd_sysd_profile_domain_callback(pan_auth_sysd.c:931): get domain for vsys1/test-ldap-globalprotect
2017-11-10 21:30:35.004 +1000 debug: pan_auth_cache_get_authprof_info(pan_auth_cache_authprof_n_authseqprof.c:176): prof "test-ldap-globalprotect", vsys "vsys1" (method: LDAP (active directory)) has sso hash table id: 0 (0 means no or i
nvalid keytab)
2017-11-10 21:30:35.004 +1000 debug: _get_profile_domain(pan_auth_sysd.c:890): auth prof "test-ldap-globalprotect" on vsys "vsys1" does NOT have domain
2017-11-10 21:30:35.004 +1000 Error: authd_sysd_profile_domain_callback(pan_auth_sysd.c:936): find domain for auth profile: test-ldap-globalprotect; vsys vsys1
2017-11-10 21:30:35.006 +1000 debug: pan_auth_request_process(pan_auth_state_engine.c:3306): Receive request: msg type PAN_AUTH_REQ_REMOTE_INIT_AUTH, conv id 27, body length 2128
2017-11-10 21:30:35.006 +1000 debug: _authenticate_initial(pan_auth_state_engine.c:2362): Trying to authenticate (init auth): <profile: "test-ldap-globalprotect", vsys: "vsys1", policy: "", username "angusg"> ; timeout setting: 25 secs
; authd id: 6486741776332750878

Re: LDAP authentication does not work for Global Protect Clients

Mick_Ball — Wed, 22 Nov 2017 12:07:51 GMT

when you add the username to the auth profile, does the user auto populate for you to select ?

Re: LDAP authentication does not work for Global Protect Clients

Farzana — Thu, 23 Nov 2017 02:59:19 GMT

@Mick_Ball

Thanks. Your hint helped to figure out that I need to replace allow-list from “cn=test global protect users,ou=security groups,ou=user1,DC=test,DC=net” to individual users like test\user1.

I then added all the users in this list.

But this does not seem to be scalable. I even tried using the short name test\ test global protect users, which did not work.

Is there a better scalable solution?

Re: LDAP authentication does not work for Global Protect Clients

mgarg — Thu, 23 Nov 2017 17:07:44 GMT

In the logs i see this error "failed authentication for user 'angusg'. Reason: User is not in allowlist"

In your authentication profile change the user domain to none ( you will have to type it) and keep the user name modifier as

%USERINPUT%

Re: LDAP authentication does not work for Global Protect Clients

Mick_Ball — Thu, 23 Nov 2017 17:48:52 GMT

@Farzana

Just start typing test global, this should also auto populate a matching group.

it works for me....

Re: LDAP authentication does not work for Global Protect Clients

AMCNLA — Thu, 17 Sep 2020 18:11:07 GMT

I know this was from long ago, but I had a similar issue. It turns out that group mappings dont work well with security groups that have a - (dash) in the name. Took me a couple days to realize this.

Re: LDAP authentication does not work for Global Protect Clients

echahine — Mon, 26 Jul 2021 14:51:52 GMT

Hey. I know this is an old forum, but I was wondering if anyone found a more scalable way to solve this issue? As it still persists to this day (PAN-OS 9.1.10)

Re: LDAP authentication does not work for Global Protect Clients

BPry — Mon, 26 Jul 2021 19:24:06 GMT

@echahine,

What exactly is the issue that you are running into getting this to scale? Generally speaking I've found that the vast majority of people simply setup dynamic AD groups to manage this side of things and it works pretty well.