LDAP Authentication - Parse error for maxPwdAge attr search

[michaelprofinancial]

Hi,

I'm trying to setup GlobalProtect with Prelogon, but I'm having trouble authenticating the user at the portal.  I'm trying to test just the user authentication with the Windows Server 2016 ActiveDirectory DC at 192.168.###.9.  Using the Pan-OS 8.0.13 CLI

admin@fw-1> test authentication authentication-profile "Corp-LDAP" username "DOMAIN\username" password
Enter password :

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

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

Authentication to LDAP server at 192.168.###.9 for user "DOMAIN\username"
Egress: 192.168.###.41
Type of authentication: plaintext
Starting LDAP connection...
Succeeded to create a session with LDAP server
Parse error for maxPwdAge attr search
Authentication failed against LDAP server at 192.168.###.9:389 for user "DOMAIN\username"


Authentication failed for user "DOMAIN\username"

admin@fw-1>

I haven't had much luck searching for "Parse error for maxPwdAge attr search".

When I run this script on the domain controller, it reports 42 days, so it seems that some reasonable data exists in the LDAP database.

Potentially noteworthy, when the DOMAIN\username user was created earlier today, I checked the account option "Password never expires".  Unchecking this option for this user doesn't change the output of the 

test authentication authentication-profile "Corp-LDAP" username "DOMAIN\username" password

command.

Thanks, 

[gwesson]

From your log output, it looks like the communication is probably plaintext (port 389 is rarely used for TLS). If that's true, you could take a packet capture of the communication between the firewall and DC.

https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/monitoring/take-packet-captures/take...

Check the LDAP response for "maxPwdAge" to see what the value is. It looks like the initial LDAP bind is failing, so you should be able to catch it there.

Interestingly, Microsoft's Max-Pwd-Age site doesn't say how it should be represented on a 2016 server. I'm sure it exists, so you may want to check it out on the DC itself if the capture doesn't reveal any results.

[aleksandar.astardzhiev]

I have recently receive similar error, trying to establish LDAP connection.

Interestingly the issues had nothing to do with this attribute. I already forgot what was actually the issue - I believe it was something with wrong bindDN (or pass).

So I would definately support the previous comment and encurage you to make a packet capture with filter your AD server as source and  destination. Plaintext LDAP is straight forward - you you wiill see bindRequest from the firewall, sending the username and the password, if successfull you should see success as reply.

[michaelprofinancial]

Thanks gwesson (and Alexander),

I installed Wireshark on the domain controller (capture filter: tcp port 389, display filter: ldap), and the failure messages were much more useful, indicating that my Base DN was incorrect in the LDAP server profile (Device -> Server Profiles -> LDAP).  It now authenticates from the CLI using the 

test authentication authentication-profile "Corp-LDAP" username "DOMAIN\username" password

command. 

Let's say my domain name was internal.fabrikam.com.
(Does not authenticate) Base DN: DC=internal,DC=fabrikam,DC=com
(Authenticates) Base DN: ou=Domain Users,DC=internal,DC=fabrikam,DC=com

Now to figure out why the user still doesn't authenticate from the GlobalProtect portal despite authenticating from the CLI.  Back to wireshark

Thanks for the help!

[michaelprofinancial]

I'm not sure why, but it now authenticates from the CLI using the original Base DN value, "DC=internal,DC=fabrikam,DC=com" using the same test command:

admin@fw-bby-in2net-1> test authentication authentication-profile "Corp-LDAP" username "DOMAIN\username" password
Enter password :

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

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

Authentication to LDAP server at 192.168.XXX.9 for user "DOMAIN\username"
Egress: 192.168.XXX.41
Type of authentication: plaintext
Starting LDAP connection...
Succeeded to create a session with LDAP server
DN sent to LDAP server: CN=Bruce Wayne,OU=Domain Users,DC=internal,DC=fabrikam,DC=com
User expires in days: never

Authentication succeeded for user "DOMAIN\username"

However, I still haven't got the GlobalProtect Portal Login page to authenticate properly.  When I enter the same DOMAIN\username and password, I get "Authentication failed: Invalid username or password".

Here's the Wireshark capture on the AD domain controller when successfully attempting a login from the above test command (DOMAIN\Administrator is the Bind DN):

144	23173.464770	192.168.XXX.41	192.168.XXX.9	LDAP	118	bindRequest(1) "DOMAIN\Administrator" simple 
146	23174.367042	192.168.XXX.9	192.168.XXX.41	LDAP	88	bindResponse(1) success 
148	23174.367773	192.168.XXX.41	192.168.XXX.9	LDAP	155	searchRequest(2) "DC=internal,DC=fabrikam,DC=com" baseObject 
149	23174.367977	192.168.XXX.9	192.168.XXX.41	LDAP	190	searchResEntry(2) "DC=internal,DC=fabrikam,DC=com"  | searchResDone(2) success  [2 results]
150	23174.368603	192.168.XXX.41	192.168.XXX.9	LDAP	391	searchRequest(3) "DC=internal,DC=fabrikam,DC=com" wholeSubtree 
151	23174.410304	192.168.XXX.9	192.168.XXX.41	LDAP	651	searchResEntry(3) "CN=Bruce Wayne,OU=Domain Users,DC=internal,DC=fabrikam,DC=com"  | searchResRef(3)  | searchResRef(3)  | searchResRef(3)  | searchResDone(3) success  [2 results]
152	23174.420534	192.168.XXX.41	192.168.XXX.9	LDAP	161	bindRequest(4) "CN=Bruce Wayne,OU=Domain Users,DC=internal,DC=fabrikam,DC=com" simple 
153	23174.461876	192.168.XXX.9	192.168.XXX.41	LDAP	88	bindResponse(4) success 
154	23174.462549	192.168.XXX.41	192.168.XXX.9	LDAP	73	unbindRequest(5) 

Here's the full Wireshark capture on the AD domain controller when unsuccessfully attempting a login from the GlobalProtect Portal Login  page:

127	17631.999659	192.168.XXX.41	192.168.XXX.9	LDAP	118	bindRequest(1) "DOMAIN\Administrator" simple 
128	17632.003200	192.168.XXX.9	192.168.XXX.41	LDAP	88	bindResponse(1) success 
130	17632.004308	192.168.XXX.41	192.168.XXX.9	LDAP	155	searchRequest(2) "DC=internal,DC=fabrikam,DC=com" baseObject 
131	17632.004440	192.168.XXX.9	192.168.XXX.41	LDAP	190	searchResEntry(2) "DC=internal,DC=fabrikam,DC=com"  | searchResDone(2) success  [2 results]

Notice how there is the same bindRequest-bindResponse and the first searchRequest-searchResEntry, but subsequent messages are missing compared to the successful authentication.

Here's an excerpt from the authd.log when unsuccessfully attempting a login from GlobalProtect Portal Login:

admin@fw-1> tail mp-log authd.log
2018-11-13 22:37:50.679 -0800 debug: _process_user_info(pan_authd_shared_ldap.c:314): found LDAP attribute: maxPwdAge
2018-11-13 22:37:50.679 -0800 debug: _process_user_info(pan_authd_shared_ldap.c:358): AD : Got value maxPwdAge : 0 in 100 nanosecond intervals since January 1, 1601 (UTC)
2018-11-13 22:37:50.679 -0800 debug: pan_authd_ldap_authenticate(pan_authd_shared_ldap.c:1021): searching basedn "DC=internal,DC=fabrikam,DC=com" for filter "(sAMAccountName=DOMAIN\username)", attrs "framedIPAddress", LDAPp=0x1086d6c0
2018-11-13 22:37:50.679 -0800 Error:  _send_async_ldap_search(pan_authd_shared_ldap.c:666): Failed to search. filter (sAMAccountName=DOMAIN\username), attr[0] framedIPAddress. error code: -7, (Bad search filter)
2018-11-13 22:37:50.679 -0800 Error:  pan_authd_ldap_authenticate(pan_authd_shared_ldap.c:1027): send userdn search request
2018-11-13 22:37:50.679 -0800 Error:  _start_sync_auth(pan_auth_service_handle.c:626): sync request for user "DOMAIN\username" is failed or possibly timed out against 192.168.XXX.9:389 with 0th VOIDp=0x1086d6c0
2018-11-13 22:37:50.679 -0800 debug: pan_auth_response_process(pan_auth_state_engine.c:4270): auth status: auth state unknown
2018-11-13 22:37:50.679 -0800 debug: pan_auth_response_process(pan_auth_state_engine.c:4449): Authentication failed: <profile: "Corp-LDAP", vsys: "vsys1", username "DOMAIN\username">
2018-11-13 22:37:50.679 -0800 failed authentication for user 'DOMAIN\username'.  Reason: Invalid username/password. auth profile 'Corp-LDAP', vsys 'vsys1', server profile 'internal.fabrikam', server address '192.168.XXX.9', From: AAA.BBB.CCC.DDD.
2018-11-13 22:37:50.680 -0800 debug: _log_auth_respone(pan_auth_server.c:263): Sent PAN_AUTH_FAILURE auth response for user 'DOMAIN\username' (exp_in_days=-1 (-1 never; 0 within a day))(authd_id: 6615420242061427090)
admin@fw-1>

Thanks in advance,

[aleksandar.astardzhiev · Accepted solution]

Hi @michaelprofinancial,

You will always see the first bind request-response pair, this is requried for the firewall to bind to the AD first before sending any query.

Next step is to search the base of your AD (the baseDN, the top level from which it will start the search) for the provided username.

If you open your wireshark for the unsuccessfull GP authentication and select searchRequest packet and dig into the LDAP you should see what filter the firewall is sending for the query. By default the PAN FW is using samAccountName, so your fillter will probably look like:

I will make an assumption that in the filter you will actually see samAccountName=domain\username, which means that the firewall is not removing the "domain\" from the user input and sending the whole string. And logically the AD is sending empty search result, because you don't have such user.

If I am right (I believe so as I had similar issue 🙂 ) you should try:

- to change the user input modifier under the authentication profile.

- Or if you don't use different domains and you are authenticating users only from one domain, you don't need to put prepent the "domain\" infront of your username and just put the username.

[michaelprofinancial]

Thanks @aleksandar.astardzhiev,

With the unsuccessful GP authentication, there is:
1) the bindRequest-bindResponse pair and then
2) a searchRequest-searchResEntry with baseObject scope,

but no following searchRequest with wholeSubtree scope.  

I changed the user input modifier (as you suggested) for the Corp-LDAP authentication profile (Device->Authentication Profile) from %USERDOMAIN%\%USERINPUT% to %USERINPUT%.  After that, my GP Portal logins authenticate successfully in addition to my CLI "test authentication authentication-profile ... username..." authentications.

My final task is to enable a certificate profile in the GP Gateway that can be used for prelogon and as a second factor, basically combining the two configurations.  My initial efforts failed, but I may make a second post since this is probably independent of the LDAP authentication.

Thanks for all the help @aleksandar.astardzhiev and @gwesson.  Is there a way to accept multiple comments as a solution?