So it turns out that our NetBackup 7.1 master server, running on Linux, is generating account lockouts for a personal user account multiple times a day.
This started after the password expired, and was changed, on that account.
Clearly we've at some point provided the username, password and domain info for this account to Netbackup - but I cannot for the life of me figure out where this might be.
We do not use access control, but bpnbat -ShowBrokerCerts returns a certificate for our Opscenter server, which is a member of the same windows domain as the locked account.
Anyway I am completely stumped as to which part of NetBackup is trying to log in a user with an old password.. Any ideas?
I'm with revaroo ...
"So it turns out that our NetBackup 7.1 master server, running on Linux, is generating account lockouts for a personal user account multiple times a day."
OK, what makes you say this ....
How quickly, after you unlock the account does is lock again ?
Because the account lockout message in the event log of our domain controllers show that the originating host for the incorrect password is the netbackup master servers FQDN. It has no other roles than being a NetBackup master server nor have we messed with samba or similar products.
As replied to the previous poster, we know that these account lockouts are originating from the master server based on the event log entries.
The lockout happens about once every 20 minutes, and the automatic unlock is set to 15 minutes so something is really trying very hard to get a valid connection to the domain. The most likely candidate would have been the access control, which can be AD integrated, but as I mentioned it is not turned on for this installation.
Stil; it has to be something and most likely related to authentication. So which bits of Netbackup, when running on Linux, are able to talk to a windows domain, and how do I figure out which bit is caching this information?
Can you breifly stop NBU and see if the account still locks ?
I can't think nbac possibly, I can't think of anywhere NBU would do this.
I think it is sensible to prove for 100% certain, that NBU is doing this, else we are looking for something that does not exist.
can you try wireshark for that... explore more granular connection in between NBU host and nearest Domain Controller and GC. You can also seek assitance of Symantec Critical System protection which logs every usual and unusual activity happens... This would surely helps you getting RCA and culprit which plays