01-31-2021 05:34 AM
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
Solved! Go to Solution.
02-01-2021 03:02 PM
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
02-01-2021 03:02 PM
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