Showing posts with label Windows Security. Show all posts

Thursday, February 26, 2015

LDAP Troubleshoting

Using LDAP with Active Directory

Administrators may decide to use Active Directory via LDAP. This may be done by connecting to Active Directory via an anonymous bind or by using a privileged user. The following topic explains how to set up an anonymous connection or a privileged connection, and some accompanying security risks.

Connecting via an Anonymous Bind

Active Directory does not allow anonymous access by default, but Administrators may enable anonymous searches if they choose.

Note: There are security risks with allowing anonymous LDAP binds with Active Directory; in this case, any users who have network access to the Active Directory server can search Active Directory.

How to Enable Anonymous Searches on the Active Directory Server

On the Windows 2000 Active Directory server, run the Active Directory Users and Groups administration tool.
Select the top level of the directory from the tree view in the left hand panel, and right click. Select the first item on the menu, which begins with Delegate Control. Click Next.
In the next window, titled Users or Groups, click Add.
On the next list, select ANONYMOUS LOGON and click Add. Administrators may also need to select Everyone and the Guests group, depending on how Active Directory is configured. Click OK when this is done. Click Next.
Select Create a custom task to delegate and click Next.
In the next list, select Read. Read All Properties will be selected at the same time. Click Next.
Click Finish.

Connecting via a Privileged Bind

By default, Active Directory can only be searched via LDAP if a privileged user is used to connect to the LDAP server. A privileged bind requires the distinguished name (DN) and password for the user. There are two options for connecting via a privileged bind:

Create a new Windows user within Active Directory. Assign this user only the right to read access to the directory. Use this user as the privileged user.
Use an existing Windows user as the privileged user.

Note: There are security risks with connecting via a privileged bind to Active Directory. Any user who can navigate to the file system and locate the authentication.properties file may find the user ID and password of the privileged user.

Troubleshooting LDAP with Active Directory

For Administrators using a Windows workstation, the LDP executable may be used to troubleshoot LDAP authentication properties. The LDP executable, found on the Windows 2003 Server CD in the \SUPPORT\TOOLSfolder, allows LDAP operations to be performed against Active Directory and includes a graphical user interface. To learn more, see Troubleshooting LDAP.

The only change for this procedure is in Steps 2, 10 and 12. Follow the steps below when using the LDP executable against Active Directory:

Login as the Windows user (username, password, domain) whose username and password are being used for the privileged bind.
Add sAMAccountName to the Attributes field and click OK.
Enter (sAMAccountName=WindowsUserName) in the Filter field, where WindowsUserName is the Windows username that will be used as the privileged user for binding to LDAP.

For Administrators using a UNIX workstation, the LDAP Browser may be used to troubleshoot LDAP authentication properties. To learn more, see Troubleshooting LDAP.

Original:

Troubleshooting LDAP Connections to Active Directory Using Apache Directory Studio

Symptoms

You cannot successfully integrate with an Active Directory (AD) server using the LDAP Server Connection Assistant in the JSS.

Resolution

Apache Directory Studio is useful for troubleshooting an LDAP connection to AD. It is available for free at:

http://directory.apache.org/studio/

To use Apache Directory Studio to troubleshoot an LDAP connection to AD:

Open Apache Directory Studio.
Add a new LDAP connection.
Enter a connection name.
Enter the host name of the AD server.
If you have a custom environment, modify the port and encryption method as needed.
Note: Using an encryption method allows the JSS to perform authentication with AD using LDAP over SSL (LDAPS). For more information, see "Configuring the JSS to Use LDAP Over SSL When Authenticating with Active Directory".
Click Check Network Parameter and verify that the host name resolves correctly.
If the connection fails, see the "Additional Information" section.
Once the connection is established successfully, click OK, and then click Next.
Choose an authentication method.
Note: The JSS supports CRAM-MD5 and DIGEST-MD5 authentication types only.
Enter credentials for a bind user in AD (an AD user with permissions to browse LDAP).
There are three formats you can use for the bind DN or username:
- Distinguished name (DN)
  The full path to the common name of the object. For example, "(CN=Administrator,OU=Users,DC=ad,DC=jamfsw,DC=corp)".
- Domain and sAMAccountName
  For example, "AD\administrator".
- userPrincipalName
  For example, "administrator@ad.jamfsw.corp".
For more information on how to find the DN or username for the bind user, see the "Additional Information" section.
Click Check Authentication to verify the credentials.
If the authentication fails, see the "Additional Information" section.
Once the correct credentials are entered and verified, click OK, and then click Finish.
Log in to the JSS with a web browser.
Click the Settings tab.
Click the LDAP Server Connections link.
Click Add LDAP Server Connection.
Select Active Directory and click Continue.
In the JSS, enter the hostname and domain of the AD server, and then click Continue.
The domain is the value for the "dc" attribute in Apache Directory Studio.
In the JSS, enter credentials for a bind user in AD (an AD user with permissions to browse LDAP). The username must be value for the sAMAccountName attribute in Apache Directory Studio.
After you enter the username, the JSS automatically adds "ad\" to the beginning so that it is in the "domain\username" format.
Enter two users to verify attribute mappings for, and then click Continue. The usernames must be the values for the sAMAccountName attributes in Apache Directory Studio.
The JSS will use these usernames to determine the search base for the LDAP server connection. You will be able to use the LDAP server connection to search for users that share the lowest common denominator of these two usernames. For example, if you want to be able to search for users in two different organizational units (OUs), you must enter a username from each OU.
Verify the attribute mappings for the users and click Continue.
These mappings are based on settings in ADUC. If you want to use custom mappings, you can enter them here or wait until later. Click the ellipsis (...) button to edit mappings.
Enter two groups to verify group membership mappings for, and then click Continue. The groups must be the values for the sAMAccountName attributes in Apache Directory Studio.
You should choose two groups that the users from step 20 are members of.
Verify the group membership mappings and click Continue.
Click Save.

After you finish creating the LDAP server connection, you should view the mappings and verify that the search bases are correct. If the users search base is OU=Test,OU=JAMFSW,DC=ad,DC=jamfsw,DC=corp, you can only search users in the “Test” folder.

You can modify the search base to include a wider search range. For example, if you change the search base to DC=ad,DC=jamfsw,DC=corp, you can search all computers in the domain.

Additional Information

This section explains how to:

Troubleshoot a failed connection to the AD server
Find the DN or username for the bind user in Active Directory Users and Computers (ADUC)
Troubleshoot failed authentication with the bind DN or username

Troubleshooting a Failed Connection

The connection to the AD server may fail if:

Apache Directory Studio cannot reach the AD server
The port entered in Apache Directory Studio is incorrect
The encryption method in Apache Directory Studio does not match the encryption method of the AD server

To ensure that you can reach the server, execute the following command and verify that you receive a response:
ping ad.jamfsw.corp
To verify that the server uses the port that you entered in Apache Directory Studio, execute a command similar to the following and verify that you receive a connected status:
telnet ad.jamfsw.corp 389
To verify the encryption method of the AD server, contact your AD administrator.

Finding the DN or Username for the Bind User

You can find the DN or username for the bind user by opening ADUC, right-clicking a user, and choosing Properties.

To find the distinguished name, click the Attribute Editor tab.

To find the domain and sAMAccountName or the userPrincipalName, click the Account tab. The domain and sAMAccountName is in the User logon name (pre-Windows 2000) fields. The userPrincipalName is in the User logon name field.

Troubleshooting Failed Authentication with the Bind DN or Username

Authentication with the bind DN or username may fail if:

The bind user entered does not exist in AD
The bind user entered does not have permission to browse LDAP
The DN or username is not formatted properly

Contact your AD administrator.

Original:https://jamfnation.jamfsoftware.com/article.html?id=224

How can I troubleshoot LDAP connections for my LISTSERV installation?

Q: How can I troubleshoot LDAP connections for my LISTSERV installation?

Answer by Liam Kelly
Senior Consulting Analyst, L-Soft

In the past, we've covered the integration of LISTSERV with LDAP data sources like OpenLDAP and Active Directory. While assisting customers with technical support for LISTSERV's LDAP configuration, we've found that most problems arise from customers either not knowing what settings are required to connect to their LDAP server or not knowing how to translate those settings to LISTSERV site configuration settings. In this tech tip, we'll look at how to test your LDAP connection using standard Windows and Unix LDAP tools, and how to apply those settings to LISTSERV once you've made a successful connection.

LDP.EXE On Windows

Regardless of whether your LDAP server is Active Directory on Windows or OpenLDAP on Unix, if your LISTSERV installation is on Windows, you can use the standard Windows LDP.EXE tool to debug connections to your LDAP server. The screen captures below are of LDP.EXE on Windows Server 2008, but the tool works the same way on other Windows versions. To install LDP.EXE on Windows Server 2008, open the Server Manager, and under Roles, install Active Directory Lightweight Directory Services. This will include, among other tools, LDP.EXE:

For other Windows versions, the installation of LDP.EXE may be different, but the tool is available on all Windows platforms. Check the Microsoft TechNet for details for your Windows version.

You can launch LDP.EXE either from the Server Manager or from the Windows command line. From LDP.EXE, you'll first want to connect to the LDAP server. From the Connection menu, select Connect. The connection screen will prompt for the LDAP server hostname and port number:

The Server can be a fully qualified domain name (LDAP.EXAMPLE.ORG), a short hostname (LDAP), or an IP address (192.168.0.123). The default LDAP port is 389. The default port for LDAP over SSL is 636. If you have an Active Directory server and want to search the Global Catalog, you can use port 3268. Click OK, and verify that the connection succeeds. If it fails, check the hostname, port number, SSL certificate chain, etc., until the connection succeeds. Once you can successfully connect, you can input the hostname and port number into the LDAP_SERVER setting in LISTSERV (for example, LDAP.EXAMPLE.ORG:636).

The next step is to test authentication. From the Connection menu, select Bind:

For the Bind type, select Simple bind. This is the only Bind type that LISTSERV supports. Supply the user name and password for an account authorized to search the LDAP directory. For Active Directory, the user name may be in the form of a Windows domain login (DOMAIN\user). For other LDAP servers, it may expect the user name to be a Distinguished Name/DN (for example,CN=Foobar,CN=Users,DC=EXAMPLE,DC=EDU). Provide the password, and click OK. You should see a message like "Authenticated as: 'DOMAIN\user'". If not, then troubleshoot the user name and the password until you can authenticate successfully. Enter the username and password in LISTSERV'sLDAP_UID and LDAP_AUTH settings respectively.

Once connected and authenticated, we should be able to search the directory. From the Browse menu, select Search:

This is where we'll supply a search base and filter. LISTSERV always does a Subtree search, so under Scope, select Subtree. For the Base DN, supply the search base. This will typically be something likeCN=Users,DC=DOMAIN,DC=EXAMPLE,DC=EDU. The actual search base depends on your LDAP directory configuration – check with your directory administrator if you're not sure. For the Filter, you'll enter your search filter criteria. If you're configuring LISTSERV for LDAP authentication, the search Filter should be some variation on the email address – either the directory attribute containing the full email address, or the attribute containing the user name portion of the email address. For example, we might enter (mailNickName=user) to search the mailNickName field of the directory for 'user', or (mail=user@example.edu) to search the mail field of the directory for user@example.edu. In theAttributes box, enter the name of the directory attribute that contains the email address. For Active Directory, this is usually just 'mail'.

If you're configuring LISTSERV for LDAP authentication, the search Filter should return one (and only one) user record. Click Run, and make sure that the result is a single user:

If the search fails or returns multiple user records, modify the Base DN and/or the Filter until the result is a single user record with email address.

Once the search succeeds, if you want to configure LISTSERV for LDAP authentication, you can enter theBase DN in LISTSERV's LDAP_PW_BASE setting, and the Filter in LISTSERV's LDAP_PW_FILTER setting. InLDAP_PW_FILTER, you'll enter a placeholder that LISTSERV will populate when it runs the query to authenticate the user. Use %s for the user's full email address, %u for the user name portion of the email address, and/or %h for the hostname portion of the email address. So our sample filter becomes (mailNickName=%u), such that if the user logs in to LISTSERV as user@example.edu, the filter will search the mailNickName field of the directory for 'user'. It is not typically necessary to set LDAP_PW_BIND – the default setting is %n, which binds with the user's full DN, and works with most LDAP directory servers, including Active Directory.

If the tests above fail, alter your Base DN and/or Filter until you get the expected results. At that point, you're ready to enter settings into LISTSERV's site configuration.

If you're configuring LISTSERV for LDAP-based Dynamic Query Lists (DQL), you should use LDP.EXE to test using a Filter like (Department=Sales) to return a set of users that will correspond to your list membership. You'll also need to know which directory attribute contains the email address (and optionally full name) for the users. In our example above, our email attribute is called 'mail', and our full name attribute is called 'displayName'. Make sure that the result set from the query matches the list of recipients to which you expect to deliver mail. Then in your LISTSERV configuration, you could create a Dynamic Query something like:

DYN_QUERY_SAMPLE= BASE=CN=Users,DC=EXAMPLE,DC=EDU FILTER= '(Department=Sales)' EMAIL=mail NAME=displayName

Ldapsearch on Unix

If you're running LISTSERV on Unix and have OpenLDAP installed, the best tool for testing LDAP connectivity is the ldapsearch command. A sample ldapsearch command (as of OpenLDAP 2.3) might look as follows; other OpenLDAP versions may require different syntax:

ldapsearch -x -H ldaps://ldap.example.edu -D 'cn=admin,cn=Users,dc=domain,dc=example,dc=edu' -w 'password' -b dc=domain,dc=example,dc=edu -s sub 'mailnickname=user'

In the sample above, -H is the URI of the LDAP server. It may begin with ldap:// or ldaps:// and may optionally have a port number appended to it. The URI will go into LISTSERV's LDAP_SERVER setting.

The –D flag is the DN of the account with which we're authenticating ('cn=admin,cn=Users,dc=domain,dc=example,dc=edu'). Note that if the DN contains spaces, you may need to pass escape characters to your shell for the command to succeed. This will become the LDAP_UIDsetting in LISTSERV.

The –w flag is the password (which also may need escape characters if it contains spaces or characters that are otherwise interpreted by your shell). This will become the LDAP_AUTH setting in LISTSERV.

The –b flag is the Base to use for the search (dc=domain,dc=example,dc=edu). If you're configuring LISTSERV for authentication, this will become the LDAP_PW_BASE setting. If you're configuring LISTSERV for dynamic queries, it will be used as the BASE in the dynamic query.

The –s flag should always be 'sub' for a subtree search. This is the only type of search used by LISTSERV.

The final argument is the search filter ('mailnickname=user'). To search for a single account for authentication purposes, the filter should return a single user record. This will become theLDAP_PW_FILTER setting in LISTSERV.

For testing dynamic query lists (DQL), the filter should return all of those email addresses that should be list recipients. It will become the FILTER part of the dynamic query:

DYN_QUERY_SAMPLE= BASE=CN=Users,DC=EXAMPLE,DC=EDU FILTER= '(Department=Sales)' EMAIL=mail NAME=displayName

If the ldapsearch command fails, pay attention to the output and modify the LDAP search parameters as needed. Once the ldapsearch command works, only then should you apply the settings to LISTSERV.

LDAP debugging in LISTSERV

If you were able to successfully test LDAP authentication and/or dynamic queries with LDP.EXE orldapsearch but the LDAP functions still aren't working in LISTSERV, you can enable LDAP debugging in your LISTSERV log file. Send the following command to LISTSERV (either via email or the web interface) to enable tracing of LDAP calls:

DEBUG FLAGS +TRACE_LDAP_CALLS

The response should look something like this:

Debug flags for this session: 00000080

00000001 TRACE_DIST       [Trace DISTRIBUTE processing - OFF]
00000002 TRACE_MIME       [Trace MIME parser - OFF]
00000004 TRACE_LISTS      [Trace (a few) list-related functions - OFF]
00000008 TRACE_SPAM       [Trace spam filter calls - OFF]
00000010 TRACE_EMM        [Trace Embedded Mail-Merge processor - OFF]
00000020 TRACE_DEV        [Temporary ad hoc tracing for development use - OFF]
00000040 TRACE_FSAV       [Trace FSAV calls - OFF]
00000080 TRACE_LDAP_CALLS  Trace LDAP library calls
00000100 TRACE_LDAP_DATA  [Trace data obtained from LDAP - OFF]
08000000 HOLD_DISTBG      [Do not process background DISTRIBUTE jobs - OFF]
10000000 HOLD_XB64        [Hold X-B64 jobs instead of processing them - OFF]
20000000 KEEP_JOBFILES    [Keep successfully processed job files - OFF]
40000000 TRACE_TCPGUI     [Additional TCPGUI tracing - OFF]

This will enable debugging of LDAP calls in the LISTSERV log. The debug log might look like this:

13 May 2014 12:32:38 From [ANONYMOUS]: X-LOGIN user@example.edu fe80:0:0:0:2c58:48f0:2a73:1d52%11 PW=[redacted] LDAP> ldap_init("ldap.example.edu", 389) -> SUCCESS LDAP> ldap_set_option(ld, 17, =3) -> SUCCESS LDAP> ldap_bind_s(ld, "cn=admin,cn=Users,dc=domain,dc=example,dc=edu", "XXXXXXXX", 128) -> SUCCESS LDAP> ldap_search_s(ld, "dc=domain,dc=example,dc=edu", 2, "mailNickName=user", attrs, 0, &result) -> SUCCESS LDAP> + attrs[0] = "1.1" LDAP> ldap_first_entry(ld, 0x8BA918) -> SUCCESS LDAP> ldap_get_dn(ld, 0x10CE6B0) -> SUCCESS LDAP> : DN="CN=Sample User,CN=Users,DC=EXAMPLE,DC=EDU" LDAP> ldap_next_entry(ld, 0x8BA928) -> EOF LDAP> ldap_unbind(ld) -> SUCCESS LDAP> ldap_init("ldap.example.edu", 389) -> SUCCESS LDAP> ldap_set_option(ld, 17, =3) -> SUCCESS LDAP> ldap_bind_s(ld, "CN=Sample User,CN=Users,DC=EXAMPLE,DC=EDU", "XXXXXXXX", 128) -> status=49 LDAP> ldap_unbind(ld) -> SUCCESS 13 May 2014 12:32:38 To [ANONYMOUS]: ***BADPW***

In the debug output above, we see user@example.edu try to log in to LISTSERV. LISTSERV successfully connects to LDAP.EXAMPLE.EDU and binds with the "cn=admin,cn=Users,dc=domain,dc=example,dc=edu" account. It runs the search with theLDAP_PW_BASE of dc=domain,dc=example,dc=edu and the filter mailNickName=user. The directory returns the user's DN (CN=Sample User,CN=Users,DC=EXAMPLE,DC=EDU). LISTSERV then connects toLDAP.EXAMPLE.EDU a second time and tries to bind with the user's DN and the password the user provided. In this case the authentication fails: (status=49), so LISTSERV rejects the login with a***BADPW*** error, meaning that the user was found in the directory but the password didn't match.

If you are testing using LISTSERV for dynamic queries, it is also possible to enable debugging to log the user records returned by the LDAP server. Send the following command to LISTSERV (either via email or the web interface) to enable tracing of LDAP data:

DEBUG FLAGS +TRACE_LDAP_DATA

The additional debug lines in the LISTSERV log file will show all of the user records returned by any LDAP dynamic queries run by LISTSERV.

References

Original:

Troubleshooting Active Directory authentication with Sign-on Splash page

Sign-on Splash page with Active Directory authentication uses LDAP/TLS to securely bind to a Global Catalog for authentication. Specifically, the AP performs a secure LDAP bind to the Domain controller on Global Catalog TCP port 3268 using the admin credentials specified in Dashboard and searches the directory for the user with the credentials entered into the splash page. When errors occur the Sign-on Splash page will show "Access denied" for wireless clients attempting to authenticate, and Dashboard will also show error messages as shown below.

Authentication failures with Sign-on Splash page fall into two categories.

1. Failure to connect to the Active Directory server

When a connection failure occurs, the test widget on Configure > Access control provides a link to the APs that "failed to connect."

The root causes of connection failures are:

a) APs in Dashboard are configured to use an Active Directory server that is unreachable over TCP port 3268 or is not a Global Catalog.

b) The Active Directory server does not have a digital certificate installed for LDAP using TLS.

2. Failure to authenticate

When an authentication failure occurs, the test widget on Configure > Access control reports "bad admin password"

or "bad user password."

In addition, an "authorization" failure will appear in Dashboard on the Login attempts page.

The root causes of authentication failures are:

a) Invalid Active Directory admin username, password or both.

b) Invalid Login username, password or both.

c) The Active Directory Admin does not have read access to the OU containing the user object.

Troubleshooting Method

The flow chart below outlines the recommended method for troubleshooting Active Directory Sign-on issues given the above information. The remaining portion of this article describes the steps necessary to follow this procedure.

Troubleshooting a connection failure

When the Sign-on Splash page returns Access denied, run the test widget on Configure > Access control with the same user credentials. If the widget reports a connection failure, begin troubleshooting connectivity between the reported APs and the AD server.

1. Check IP connectivity between the reported APs and the configured AD server. Ping the AD server from the AP in question using Live Toolsthen try pinging the AP from the AD server. Successful ping tests verify IP connectivity between endpoints.

2. Run the test widget while taking simultaneous packet captures from the AD server using Wireshark and the wired interface of the AP using Dashboard. These captures are analyzed in Wireshark and can be used to verify if the AD server is receiving TCP packets from the the AP on TCP port 3268 and whether or not the server is responding appropriately.

3. Analyze the capture taken on the AD server using the following Wireshark filter tcp.port==3268 and ip.addr==X.X.X.X, where X.X.X.X is the IP address of the AP. If the AD server replies to TCP SYN packet on port 3268 with a TCP RST, it is likely the AD server is not a Global Catalog. In this instance enable the Global Catalog role on the AD server.

Figure 1: AD server 10.0.0.116 replies to the AP 10.0.0.117 with a TCP RST because it is not listening on TCP port 3268

4. If the packet capture shows the AD server sending an "Error initializing SSL/TLS" in response to the APs StartTLS packet, then the AD server does not have a valid digital certificate installed. In this case you will need to install a valid digital certificate on the AD server.

Figure 2: AP 10.0.0.2 sends a StartTLS packet, but the AD server 10.0.0.117 sends a LDAPError: Error Initializing SSL/TLS.

5. Firewalls can also cause connection failures. If the server is a Global Catalog but an TCP RST or ICMP "Destination Unreachable Communication administratively prohibited" is returned by the AD server, make sure TCP port 3268 is opened inbound on the local firewall. If either of these messages shows up on a capture taken from the AP but not on the AD server, there could be an intermediate firewall blocking access to the AD server. If there are no packets from the AP when analyzing the packet capture taken from the AD server, check the packet capture taken from the AP. If you see packets being sent from the AP to the AD server on TCP 3268 but no response, then there may be an intermediate firewall silently blocking communication.

Troubleshooting authentication failures

Examining LDAP interface events in the Windows Directory Service Event log can help determine if a bad password or bad username is the cause of the authentication failure. To enable LDAP debugging logs on the Domain Controller, s et the LDAP Interface Events to verbose using DWORD value 5 in the Windows registry. Once LDAP events have been enabled, open the Windows Event Viewer and navigate to Applications and Services Logs > Directory Service.

Before running the widget test or trying to authenticate via the splash page to generate some logs, clear the older logs or filter the current logs over the last hour. This will make it easier to locate the newer events. Right click the Directory Service log and choose Clear log. Then perform authentication attempts.

After LDAP Events have been generated they can be pieced together to isolate the cause of the authentication failure as described below.

Bad passwords (Admin or User)

When all users are unable to authenticate to the splash page, it is most likely a bad admin credentials. If some users are able to authenticate then it is probably bad user credentials. Either way the test widget can be used to determine if the admin or the user password is invalid. In the Windows Event log, the SID of the account using the bad password will be shown in a event 1174. If the Active Directory admin password or the user account password is incorrect you will see Events in the following order.

1. Events 1138 and 1139 always appear when a LDAP search occurs, as shown below.

2. When a bad password is entered, an Event 1174 will immediately follow, showing the SID of the account that attempted to use a bad password.

You can use the SID specified in the 1174 Event and match it to the user object (Admin or user) properties in Active Directory Users and Computers.

3. Event 1535 will appear after the 1174 and tell you an LDAP error occurred.

4. Event 1215 shows the LDAP client closed the connection.

Whichever account SID was specified in the 1174 event is the one that had a bad password. Make sure to use the correct password and try again.

Active Directory Admin account name is invalid

If the Active Directory admin name is invalid or does not exist in the directory all users will fail to authenticate through the splash page and the test widget will report "bad admin password" (previously shown). A 1174 event will not appear because the initial bind request failed. You will see Events 1138 then1139 immediately followed by a 1535 LDAP error event (previously shown). Finally the LDAP client will close the connection resulting in a 1215 event. In this case, verify the account exists in Active Directory. Try using the UPN i.e. administrator@mydomain.local or just the sAMAccountName i.e. administrator without a prefix or suffix.

Login username is invalid

If the user account logging into the splash page does not exist in the directory, the username is being entered incorrectly, or the Admin account does not have access to OU containing the user, an LDAP search will complete successfully with no error based Events. Events 1138 and 1139 will be logged when a successful LDAP search has occurred, however a "bad user password" (previously shown) will appear in the test widget and the Sign-on Splash page will alert Access

How to Troubleshoot LDAP Authentication

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.

Windows System Admin Blog..Welcome to Microsoft World..!!!