When configuring a Global Protect portal to authenticate users against an LDAP server (in my case, Windows Server 2012 R2), I had to remember the following few details.

Firstly, when you edit the LDAP profile Web GUI→Device Tab→Server Profiles→LDAP, in the Domain text box, ensure that you have put the NetBIOS name not the full domain (e.g. set domain and not domain.com. You may also have to set this under Group Mapping→Server Profile→User Domain. When I was mapping to more than one domain. I found the second domain wouldn't work with group mapping until I added the netbios name to Group Mapping→Server Profile→User Domain. Unfortunatly, I also run debug user-id reset group-mapping NameOfGroupMapping before commiting and testing so I don't know which fixed it.

Make sure allow list in the LDAP profile is set with full path. E.G.

cn=palo_admins,cn=service_accounts,dc=domain,dc=local

You may also have to ensure that the LDAP server profile itself has Bind DN set to

cn=palo_ldap,cn=service_accounts,dc=domain,dc=local

and not

palo_ldap@domain.local

Secondly, when you edit the authentication profile (Web GUI→Device Tab→Authentication Profile), ensure that the Login Attribute is set to sAMAccountName. You probably also want to ensure that the Allow list only contains the domain group whose members are permitted to use VPN.

In addition, when you create an Authentication Profile, fill in the Login Attribute field with sAMAccountName when Authentication Type is set to LDAP.

If you set an “Allow List” you must ensure you enter this in *lower case* (that included the CN, OU, etc)

Thirdly, ensure that the groups you want to use for group filtering are CN objects and not OU objects.

I found that the 'test' command for authentication profiles is dodgy. Although you can log in using palotestusername (without appending DOMAIN\), I found that the test command would not work unless you append the domain like the following

test authentication authentication-profile AUTH_P_LDAP_Admins username domain\palotestuser password

If you try to authenticate and see an error about not parsing maxPwdAge, check the Base DN you are using. I once left it as DC=domain.local,DC=local rather than DC=domain,DC=local. Also check you are using sAMAccountName. It could also be that the password is missing.

When creating an LDAP authetication profile to allow members of an LDAP group access to GlobalProtect, you will need to set your Authenticaiton Profile up with the following values.

• Type: LDAP
• Server Profile: Name of profile
• Login Attribute: sAMAccountName
• Password Expiry Warning: 7
• User Domain: Short domain name (e.g. acme rather than acme.local
• Username Modifier: %USERINPUT%

Then, in Advanced tab, set the group like so

cn=allowed_vpn_users,ou=ad_groups,ou=global,dc=example,dc=com

In the group mapping configuration, set as follows

• User Domain: Short domain name (e.g.

  acme

  rather than

  acme.local

• Search Filter: <blank>
• Object Class: group
• Group Name: name
• Group Member: member
• Search Filter: <blank>
• Object Class: person
• User Name: sAMAccountName
• Mail Attributes: mail
• Domain List: <blank>

If you want to use certificate validation for LDAP connections, you can get the certificate by logging onto the domain controller and running the following. In my lab, the domain was setup with a certificate authority infrastructure.

certutil -viewstore -enterprise ntauth

Two other commands

certutil -adca

certutil -catemplates

Another export method is

1. Go to the Certificate Authority server (Windows Server)
2. Click 'Start' > 'Control Panel' > 'Administrative Tools' > 'Certificate Authority' to open the CA Microsoft Management Console (MMC) GUI.
3. Highlight the CA computer, and right-click to select 'CA Properties'.
4. From 'General' menu, click 'View Certificat'e.
5. Select the 'Details' view, and click 'Copy to File' on the lower-right corner of the window.
6. Use the Certificate Export wizard to save the CA certificate in a file.

To check if accounts are locked out, run the following on PowerShell on the domain controller

Search-ADAccount -Locked | Select Name, LockedOut, LastLogonDate

It is possible to lock out some accounts when using authentication sequences. Let's say you have an authentication sequence with LDAP profile at the top and Local User DB at the bottom. Let's also say that the same user name john has password 1234 in LDAP but password abcd on the local user database. If you log in with john and abcd enough times, it is possible to lock out the LDAP account because that is being tested with the password each time you try to login.