need a way to get the DEFAULT cipher string via a yaml script

Have you tried running a tcpdump on your BIG-IP to verify if communications to your LDAP server are working?

tcpdump -nni 0.0 port 389 and host ldapserverIPaddress

ideas:

• as cory suggests, communication (are your new big-ips in a different network, do they need a management route to reach the ldap server)

   

• other version of tmos (so different config)

   

• bit obvious, but does copy pasting the password work out? perhaps try to reconfigure it via the GUI?

   

I hadn't tried that, but having done so, this is the output (I have replaced IP addresses for security):

[root@LB1:Active:Changes Pending] config  tcpdump -nni 0.0 port 389 and host 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 96 bytes
14:53:12.215807 IP .56539 > .389: S 2280840514:2280840514(0) win 14600 
14:53:12.216374 IP .389 > .56539: S 2623792533:2623792533(0) ack 2280840515 win 49248 
14:53:12.217106 IP .56539 > .389: . ack 1 win 115 
14:53:12.217297 IP .56539 > .389: P 1:70(69) ack 1 win 115 
14:53:12.217648 IP .389 > .56539: . ack 70 win 49179 
14:53:12.231806 IP .389 > .56539: P 1:15(14) ack 70 win 49248 
14:53:12.232093 IP .56539 > .389: . ack 15 win 115 
14:53:12.232477 IP .56539 > .389: P 70:135(65) ack 15 win 115 
14:53:12.232753 IP .389 > .56539: . ack 135 win 49248 
14:53:12.234563 IP .389 > .56539: P 15:500(485) ack 135 win 49248 
14:53:12.235802 IP .389 > .56539: P 500:1035(535) ack 135 win 49248 
14:53:12.235870 IP .389 > .56539: P 1035:1049(14) ack 135 win 49248 
14:53:12.236099 IP .56539 > .389: . ack 1035 win 131 
14:53:12.237373 IP .56539 > .389: P 135:204(69) ack 1049 win 131 
14:53:12.243468 IP .389 > .56539: P 1049:1063(14) ack 204 win 49248 
14:53:12.244275 IP .56539 > .389: P 204:273(69) ack 1063 win 131 
14:53:12.246356 IP .389 > .56539: P 1063:1077(14) ack 273 win 49248 
14:53:12.247753 IP .56539 > .389: P 273:389(116) ack 1077 win 131 
14:53:12.248710 IP .389 > .56539: P 1077:1091(14) ack 389 win 49248 
14:53:12.257520 IP .56539 > .389: P 389:396(7) ack 1091 win 131 
14:53:12.257595 IP .56539 > .389: F 396:396(0) ack 1091 win 131 
14:53:12.258015 IP .389 > .56539: . ack 397 win 49248 
14:53:12.258775 IP .389 > .56539: F 1091:1091(0) ack 397 win 49248 
14:53:12.259140 IP .56539 > .389: . ack 1092 win 131 

So the communications look good. As Boneyard says, can you verify the password?

Might be worth capturing this to a .pcap file and viewing in Wireshark to see if that yields more information:

tcpdump -nni 0.0 port 389 and host serverip -s 1500 -w /var/tmp/ldapauth.pcap

Also, can the LDAP server admin give you any information from the server logs?

I've had a look with the guys who look after the LDAP servers and everything looks ok from there.

The traffic is coming from the external vlan self IP. Should this be something else? Is this because of the default gateway? Does a management route need setting up for this traffic? The other F5s haven't got this multiple VLAN configuration yet.

If I may add, it looks like your getting LDAP traffic back and forth, so I doubt there's a networking issue. As Boneyard suggested, using the -Xs0 option in the tcpdump can shed some light on the LDAP itself. The very best tool though, in my opinion, is a WireShark capture. It'll break open the LDAP packets and show you exactly what each side is saying and should pinpoint exactly where the problem is.

Ok so I've run tcpdump -nni 0.0 -s0 -X port 389 and host and in the output I can see all my credentials being returned from the LDAP server.

I know you said all of the configurations were the same, but can you verify the remote role configs to ensure they match? If your BIG-IP is getting the results from the AD server as expected and still not granting access, then it is most likely a configuration issue on the BIG-IP.

Cory, I can confirm that the configs are carbon copies of each other.

I added a management-route tonight and it had no effect on anything.