Authentication failed from AD

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Authentication failed from AD

L4 Transporter

Hello,

I have integrated the AD with Paloalto , it is working fine and i can see the IP user mapping is correct, once i tested authentication profile

I got the below error:-

 

Jafar_Hussain_0-1596457062859.png

Once i tested the authentication by local profile it is working fine.

 

Jafar_Hussain_1-1596457142802.png

 

Can anyone help me on this to reolve this issue.

 

4 REPLIES 4

L2 Linker

IP to UserMapping is separate than LDAP. 

 

Based off your error message in the first screenshot, 'Failed to create a session with LDAP server', I would point towards a network level issue from the firewall MGMT IP (assuming no custom service routing) and the LDAP controller.  Could also be permissions on the service account used, but I would bet dollars to donuts it's network level. Also - TLS/389?  I know it's possible, but...might need to swap to port 636

 

Local auth used in second is just authenticating against the local user database on the FW, no LDAP connection needed

Cyber Elite
Cyber Elite

@Jafar_Hussain  

 

Is this new setup?

Please check below document it has step bu step info on troubleshooting

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClpoCAC

 

Also try below commands to do the TCPdump on the management port

 

Command to capture LDAP traffic if using management port

> tcpdump filter "port 389"

 

Command to view the pcap taken off the management port

> view-pcap mgmt-pcap mgmt.pcap

 

Regards

 

 

 

MP

Help the community: Like helpful comments and mark solutions.

@Chris_Johnston @MP18 

 

Yes this is a new setup. i have gone through the documents and changed the service account with ssl/tls 636 port.

 

My LDAP, UID, DNS service route changed via data plane interface  I have tried everything but still, the issue is the same.

 

 

Will need to check your authd.log if you've checked everything from above.  I would also double check your firewall policy to ensure that dataplane source interface/zone is allowed to the other zone that 10.10.10.100 exists in.

 

I've also noticed theres more helpful information in group mapping failures versus auth attempts (lists bad password/fail to connect/etc).  Do you have group mapping configured for the associated ldap profile?  If you show the group mapping state, what is the output?

CLI

show user group-mapping state <name of group mapping profile referencing the LDAP Profile>

 

Future troubleshooting for auth specific, if group mapping is successful.

SSH to firewall, issue the following command

tail follow yes mp-log authd.log

 

while that is running, test authentication via another SSH window and paste results (sans business specific information that may be present)

 

 

  • 4685 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!