Version 15
Symptom
LDAP authentication is configured for device administration, captive portal or GlobalProtect. However, the authentication requests always fail.
Overview
This guideline describes how to troubleshoot this kind of LDAP authentication issue.
Preliminary assumptions:
- The LDAP server is a Microsoft Active Directory server.
- Allow List is not used in the authentication profile. (Allow List usage can lead to other kind of issues, which are outside the scope of this document)
Steps
The authentication process is handled in the Management Plane by the authd process. All debugs logs will be located in mp-log authd.log
1. Check your LDAP server profile:
# show shared server-profile ldap
ldap {
ad2008 {
server {
myadserver {
port 389;
address 10.0.0.10;
}
}
ldap-type active-directory;
base DC=panw,DC=dom;
bind-dn admin@panw.dom;
timelimit 30;
bind-timelimit 30;
bind-password -AQ==LEkLjmi5LnnONEwl89h/wpfRI0Y=AgBprzhy+CcbuOsMVp+mJg==;
ssl no;
}
}
1.1 TCP port 389 is used for regular LDAP. When using port 389, be sure to have disabled SSL (ssl no;).
If SSL is enabled, make sure the LDAP server supports LDAPS and check to ensure that TCP is configured to port 636 in your server profile (LDAPS default port).
# show shared server-profile ldap
ldap {
ad2008 {
server {
myadserver {
port 636;
address 10.0.0.10;
}
}
ldap-type active-directory;
base DC=panw,DC=dom;
bind-dn admin@panw.dom;
timelimit 30;
bind-timelimit 30;
bind-password -AQ==LEkLjmi5LnnONEwl89h/wpfRI0Y=AgBprzhy+CcbuOsMVp+mJg==;
ssl yes;
}
}
1.2 The Base DN should be acquired automatically from the Palo Alto Networks device when the Base dropdown list is selected in the LDAP Server Profile (Device > LDAP > LDAP Server Profile). It is highly recommend to use this value for the LDAP server Base.
1.3 In the LDAP Server Profile, the Domain name can be configured manually. Leaving this field blank is recommend, as the PAN-OS will determine the Domain automatically. This option is used in very specific situations when several AD domains need to be unified to a single one.
1.4 A good way to check the LDAP connection is by using the LDAP tree browser when configuring Group-Mapping (choose the appropriate LDAP server in the Server Profile).
If you are able to browse your ldap, then your ldap server profile is correctly configured.
2. Check authd.log
When following authd.log with # tail follow yes mp-log authd.log, the following entries will typically appear
Authentication Succeeded
Jan 08 14:00:46 pan_authd_service_req(pan_authd.c:2604): Authd:Trying to remote authenticate user: user1
Jan 08 14:00:46 pan_authd_service_auth_req(pan_authd.c:1115): AUTH Request <'vsys1','adauth','user1'>
Jan 08 14:00:46 pan_authd_handle_nonadmin_auths(pan_authd.c:2245): vsys, authprof <vsys1,adauth> doesnot exist in db, trying 'shared' vsys
Jan 08 14:00:46 pan_authd_common_authenticate(pan_authd.c:1511): Authenticating user using service /etc/pam.d/pan_ldap_shared_adauth_0,username user1
Jan 08 14:00:46 pan_authd_authenticate_service(pan_authd.c:663): authentication succeeded (0)
Authentication Failed
Jan 09 23:21:15 pan_authd_service_req(pan_authd.c:2604): Authd:Trying to remote authenticate user: user1
Jan 09 23:21:15 pan_authd_service_auth_req(pan_authd.c:1115): AUTH Request <'vsys1','adauth','user1'>
Jan 09 23:21:15 pan_authd_handle_nonadmin_auths(pan_authd.c:2245): vsys, authprof <vsys1,adauth> doesnot exist in db, trying 'shared' vsys
Jan 09 23:21:15 pan_authd_common_authenticate(pan_authd.c:1511): Authenticating user using service /etc/pam.d/pan_ldap_shared_adauth_0,username user1
Jan 09 23:21:21 pan_authd_authenticate_service(pan_authd.c:663): authentication failed (6)
Jan 09 23:21:21 pan_authd_common_authenticate(pan_authd.c:1531): Authenticating user using service /etc/pam.d/pan_ldap_shared_adauth_0,usename user1 failed - trying other hosts
Jan 09 23:21:21 pan_authd_common_authenticate(pan_authd.c:1506): Skipping LDAP server due to missing Auth-Profile: pan_ldap_shared_adauth_1
Jan 09 23:21:21 pan_authd_common_authenticate(pan_authd.c:1506): Skipping LDAP server due to missing Auth-Profile: pan_ldap_shared_adauth_2
Jan 09 23:21:21 pan_authd_common_authenticate(pan_authd.c:1506): Skipping LDAP server due to missing Auth-Profile: pan_ldap_shared_adauth_3
Jan 09 23:21:21 authentication failed for user <shared,adauth,user1>
Jan 09 23:21:21 pan_authd_process_authresult(pan_authd.c:1258): pan_authd_process_authresult: user1 authresult not auth'ed
Jan 09 23:21:21 pan_authd_process_authresult(pan_authd.c:1282): Alarm generation set to: False.
Jan 09 23:21:21 User 'user1' failed authentication. Reason: Invalid username/password From: 192.168.0.17
These logs for failed attempts are very generic and can be confusing.
The same logs can be seen for various causes:
- Your LDAP server is not reachable (check your service routes)
- User does not exist in LDAP server
- Username and/or Password is wrong
- Bind DN format in your server profile and/or Password is wrong
3. Check your Service Routes
If a service route has been configured for UID agent service, Group Mapping test will work while LDAP authentication may fail because the Palo Alto Networks device is still using the management interface as the source for LDAP authentication requests.
Indeed, group-mapping is managed by the useridd process and will use its dedicated service route (UID agent).
As mentioned before, authentication service is achieved by authd process and it is not possible to configure a dedicated route for this service.
If the mgmt interface is not used for LDAP authentication requests, an individual service route with the LDAP server IP address in destination must be configured.
No comments:
Post a Comment