Forum Discussion
AndOs
Cirrostratus
Apr 16, 2013Can't change AD password through APM
Hi!
I'm having some problems with password change for expired AD passwords through APM.
Running on APM+LTM 11.2.1 build 797.
Using "AD Auth" in the access policies to authenticate users.
The session log shows
AD module: Can't contact KDC 127.7.0.3 for domain xxxxxx.xx
AD module: (null) '' failed: (1331653729)
AD module: (): (1331653729)
AD module: LEAVE Function chgUserPassword
AD agent: Auth (logon attempt:1): failed to change password for 'xxxxxxxxx'
I found this old post describing a similiar issue, but it didn't help much in this case, so I'm making a new post, hoping that perhaps someone else has run into this issue.
The errors says that KDC can't be contacted, but running a packet capture for the DC shows that APM can communicate with them.
The bad thing I've noticed is that after a user has tried to change password and gotten this error, AD auth seems to fail completly for all users and all access policies for about 10 to 15 minutes.
I've verified this by keeping tcpdump running against the DCs. After the issue has occurred, 0 packets are captured for the DCs when users try to authenticate.
The only way I've been able to force it to work again is to recreate the AAA server and reapply all access policies.
I have a test environment running the same TMOS version and basically the same access policies with the same DCs, same AAA server config etc. In that env, password change works.
The only difference I've so far been able to see is that the test environment communicates over UDP to the DCs while the production env (where passwd change doesn't work) _only_ communicate over TCP.
To troubleshoot this further, is there any way to switch APM to use UDP instead of TCP for active directory?
Or perhaps vice versa, to force it to use TCP, so I can switch the test env to TCP and see if the problem occurs there as well?
Thanks.
/Andreas
13 Replies
could you explain the part of the exhausted better Kevin. do you mean that once there have been aprox 65k session on one AD it moves to a second server in the pool? and how can that cause a problem on the AD?
- Kevin_Stewart
Employee
I don't know the complete details, as it's just observation. What I've also observed is that the domain controller will fail long before port exhaustion and the AAA will mark it down for up to 10 minutes.
- Julien_Guirling
Nimbostratus
The Kerberos use a special port for password change : udp/464 or tcp/464 Check if there is no firewall blocking this connection
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects