Issues with AD account lockout when discovery runs against a network containing F5 devices

[Tomko]

We're having a strange issue with Discovery against networks containing F5 devices.   I am not familiar with these devices, but it appears they contain a hypervisor or some other interface that is causing ServiceNow discovery to attempt an Active Directory login.   I'm not sure on the specifics of this, but I know we don't have these devices in the group policy that allows our AD account access.   However, rather than simply failing login, somehow the AD account is getting locked.

Has anyone ever run into this and, if so, how did you resolve?

Thanks

[Dave Ainsworth]

Hi John,

Just to check with these being AD credentials, they are Windows credentials that are getting locked? I have never seen a Windows probe attempted against an F5 although I must admit, I have never been looking out for it! I have seen virtual F5s discovered (which is probably where the hypervisor comes in?) and not seen this problem either. With the F5 OS being based on Linux we do sometimes trigger SSH probes and for Service Mapping, this is one way to retrieve iRules so I have seen these many times.

Can you obtain more information such as which interface these are being triggered on (management interface?). And if these are Windows credentials, you are seeing Windows classify probes triggered? One option might be to try the IP service affinity:

IP service affinity for Discovery and Orchestration

This assumes that you are always discovering the F5s successfully using SNMP on the same IP address as the problem probe is being triggered so that once SNMP has successfully discovered, this is always tried first and might prevent the AD credentials being used.

Regards,

Dave

[Tomko]

Our AD account is someuser@somedomain.com.   We also have an LDAP Account that is UID=someuser,ou=someou, dc=somedc,dc=com.   This account is used for SSH.   The F5 is set up for SSH, but has only been set up for AD authentication.   Seeing SSH open, ServiceNow is passing the LDAP user name and password to the F5.   Because the F5 sees a username it recognizes (someuser) but a password it does not, it's causing the bad password account on the AD DC to increment.

It would be nice if the F5 knew where the account came from (someuser is not the same as someuser@somedomain.com), but this is not the case.   So, we either need to make sure the user segment of the AD account is different from that of the LDAP account, or sync the passwords between the two accounts.

We're waiting for one of those two things to happen, but based on testing we're pretty sure this is what is happening.

[SanjivMeher]

Hi John,

Did you recently upgraded to Helsinki?

We had a similar issue, where we upgraded our test environment, which was using a LDAP to authenticate user. The service account configured in LDAP starts passing the encrypted password which fails to login and ultimately locks the account.

[Tomko · Accepted solution]

Thanks, the issue was with 2 accounts with the same username; one was AD and the other LDAP.   The target we were logging into was set up for AD and we were throwing the LDAP account at it.   Since the LDAP account had a different password but the username was recognized, the login attempt got sent to the AD domain controller, and failed as bad password.