cancel
Showing results for 
Search instead for 
Did you mean: 

WiNG 7.5.1 LDAP cannot join to Windows Active Directory Domain 2016.

WiNG 7.5.1 LDAP cannot join to Windows Active Directory Domain 2016.

NoufalQA
New Contributor


WiNG 7.5.1 LDAP can not join to Windwdows Active Directory 2016. The configuration is below. Can Anybody help?


radius-server-policy default
 authentication data-source ldap 
 authentication eap-auth-type peap-mschapv2
 ldap-server primary host 172.16.4.140 port 389 login "(sAMAccountName=%{Stripped-User-Name:-%{User-Name}})" bind-dn "CN=administrator,CN=Users,DC=shareweb,DC=net,DC=pa" base-dn "DC=shareweb,DC=net,DC=pa" passwd 0 hidden passwd-attr UserPassword group-attr cn group-filter "(|(&(objectClass=group)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-userDn})))" group-membership radiusGroupName net-timeout 10
 ldap-agent primary domain-name shareweb domain-admin-user Administrator domain-admin-password 0 hidden
 no ldap-group-verification

profile ap410 default-ap410
 ip name-server 172.16.4.140
 ip name-server 172.16.4.141
 ip domain-name shareweb.net.pa


1-ap410-FF2A10#ping shareweb.net.pa
PING shareweb.net.pa (172.16.4.140) 100(128) bytes of data.
108 bytes from dc1.shareweb.net.pa (172.16.4.140): icmp_seq=1 ttl=128 time=0.342 ms
108 bytes from dc1.shareweb.net.pa (172.16.4.140): icmp_seq=2 ttl=128 time=0.286 ms
108 bytes from dc1.shareweb.net.pa (172.16.4.140): icmp_seq=3 ttl=128 time=0.317 ms
108 bytes from dc1.shareweb.net.pa (172.16.4.140): icmp_seq=4 ttl=128 time=0.325 ms
108 bytes from dc1.shareweb.net.pa (172.16.4.140): icmp_seq=5 ttl=128 time=0.322 ms


1-ap410-FF2A10#show ldap-agent join-status 
Primary LDAP Server's agent join-status : Unable to find a suitable server for domain shareweb.net.pa
Unable to find a suitable server for domain shareweb.net.pa
Secondary LDAP Server's agent join-status : Not Configured or Unused

1 ACCEPTED SOLUTION

Ovais_Qayyum
Extreme Employee

Hi Noufal,

Since you have posted limited details on your AD domain structure, I am responding with few assumptions. There could be multiple reasons for it to fail, two of the most common ones are the Bind DN configuration and insufficient permissions on the Bind User.

The Bind DN configuration will vary depending on where the Bind User account is created in the Active Directory tree. For smaller environments, the Bind DN will typically be located in the default Users container such as cn=username,cn=Users,dc=example,dc=com where the Users container is designated as a Common Name (CN).
However, in larger Active Directory environments the Bind User account will typically be located in an Organization Unit (OU). One common configuration error is to designate the OU as a CN. For example, one may incorrectly enter cn=username,cn=US,dc=example,dc=com where the correct Bind DN would be cn=username,ou=US,dc=example,dc=com.
When entering the Bind DN is very important to know exactly where in the Active Directory tree and what type of container (i.e. CN or OU) the Bind User account is located.

You can run a packet capture on interface ge1 and filter with ldap port 389.

VX9000-Primary~#service pktcap on int ge 1 filter port 389

Open the capture in Wireshark, if there is an issue with the Bind user permissions you will see an “incorrect credentials” error message.  

 

Regards,

Ovais

View solution in original post

1 REPLY 1

Ovais_Qayyum
Extreme Employee

Hi Noufal,

Since you have posted limited details on your AD domain structure, I am responding with few assumptions. There could be multiple reasons for it to fail, two of the most common ones are the Bind DN configuration and insufficient permissions on the Bind User.

The Bind DN configuration will vary depending on where the Bind User account is created in the Active Directory tree. For smaller environments, the Bind DN will typically be located in the default Users container such as cn=username,cn=Users,dc=example,dc=com where the Users container is designated as a Common Name (CN).
However, in larger Active Directory environments the Bind User account will typically be located in an Organization Unit (OU). One common configuration error is to designate the OU as a CN. For example, one may incorrectly enter cn=username,cn=US,dc=example,dc=com where the correct Bind DN would be cn=username,ou=US,dc=example,dc=com.
When entering the Bind DN is very important to know exactly where in the Active Directory tree and what type of container (i.e. CN or OU) the Bind User account is located.

You can run a packet capture on interface ge1 and filter with ldap port 389.

VX9000-Primary~#service pktcap on int ge 1 filter port 389

Open the capture in Wireshark, if there is an issue with the Bind user permissions you will see an “incorrect credentials” error message.  

 

Regards,

Ovais

GTM-P2G8KFN