Intruder lockout on admin account

[bopritchard]

I recently had to change the password on my admin account because of a personel change...problem is the account keeps getting locked out...there is no lockout address listed in nwadmin...so i'm assuming the lockout is coming from the server itself...it's something pretty persistent...i'll unlock it and it will be locked-out again in 2 minutes...

how can i track this down...i guess there is a process on the server using the old password...

 

[Jontmke]

Absolutely.
Mercury mail might be. Arcserve (backup) also. And any cron type automation too.

Jon

There is much pleasure to be gained from useless knowledge. (Bertrand Russell)

 

[bopritchard]

i don't use Mercury mail or Arcserve...and my crontab is empty

 

[Jontmke]

What email or backup do you use? Any Faxware? How about a backroom PC that does scheduled processes?

Jon

There is much pleasure to be gained from useless knowledge. (Bertrand Russell)

 

[Octavius]

When the account locks out you can check the address of the workstation which locked the account. It is listed in the 'Intruder Lockout' tab under 'Last Intruder Address'.

That should help you find the cause of your issue.

 

[bopritchard]

groupwise and veritas backupexec...think i've eliminated them though...

in regards to the intruder address...like i said in my original message...there is no address listed

 

[Octavius]

Sorry, missed that one

Glad you got it sorted though

 

[xaviero]

I'm having the same problem with groupwise 5.5 and veritas backup exec. How did you eliminate the intruder lockout?

 

[marvhuffaker]

Why not rename the admin account or create a new admin account. There is nothing that says the admin account has to be "admin".

In fact, I recommend this as a standard security precaution... Your admin account has less chance of being compromised if the name is not obvious.

As far as accounts for other functions like backups, etc, create an account for each specific function (use a non-obvious name), and limit the permissions as much as possible. If you use separate accounts, use complex passwords 12-16 characters long with a good mix of numbers and special characters. Then you can be fairly confident that it would take thousands of years or more to crack. Then you really don't need to worry about changing them like you do the regular user accounts. But the advantage of doing this, is that when you do change your 'Admin' account password, it doesn't hose up the other functions that rely on the admin user's authentication.

Marv

Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting

http://www.redjuju.com

 

[TheLad]

Marv has a good point. All of the big companies I have worked for do not have an ADMIN account, they have two (or more) accounts with [Root] supervisor access. It is always better to have at least two accounts just in case something goes wrong with one. You could always set a password on the backup account and place the password in a sealed envelope in a company safe??

-----------------------------------------------------
"It's true, its damn true!"
-----------------------------------------------------

 

[xaviero]

So should I just create a new admin account and let the intruder lockout continue???
bopritchard what did you do to eliminate your problem?

 

[davisje]

You can also go through the system directory and look at the .ncf and .cfg files. These files contain login info for other programs as well. If you are running gwia the gwia cfg file normally has the admin name and password.

Jeff

 

[Provogeek]

xaviero On GroupWise, check your GWIA and WebAccess configuration files. These two agents want to have a user + password. In poorly configured systems, people use the ADMIN user ID. If you have MTA or POA agents running on a different box than the domain or postoffice directory, then these also would want a user+password. The config files you want to look for are *.mta, *.poa, strtweb5.ncf, & gwia.cfg. All are in the SYS:SYSTEM directory.

On your backup, use the job manager and edit the password OR delete and recreate the backup job using the new password.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Certified nut case
Senior Network Engineer

http://www.kiscc.com