How to address intruder lockout problems after routing password changes
We performed our periodic update of user passwords. This is not cause issues last year. This year, on one of our servers, holder of the master of edirectory, we get intruder lockout warnings as follows:
1-31-2008 4:31:58 pm: DS-10553.37-268
Intruder lock-out on account .xxxxxxx.xxxxxxx.xxx [333D58C6:000000000001]
1-31-2008 4:32:02 pm: DS-10553.37-268
Intruder lock-out on account .xxxxxxx.xxxxxxx.xxx [333D58C6:000000000001]
1-31-2008 4:32:05 pm: DS-10553.37-268
Intruder lock-out on account .xxxxxx.xxxxxx.xxx [333D58C6:000000000001]
It has occurred for several different users. Some have been addressed by uninstalling Adobe Acrobat and reinstalling, which reset the automated update agent. Some were addressed by changing to our cable gateway versus our dsl gateway, which bypasses our content filtering process. We know it is related to an authentification issues, but don't know how to determine the cause of the user's issue. The user names in the log are legitimate but all reference the same [333D58C6:000000000001] item. We do not know how to determine what is causing the problem so we can correct the authentification problem.
Cliff
1-31-2008 4:31:58 pm: DS-10553.37-268
Intruder lock-out on account .xxxxxxx.xxxxxxx.xxx [333D58C6:000000000001]
1-31-2008 4:32:02 pm: DS-10553.37-268
Intruder lock-out on account .xxxxxxx.xxxxxxx.xxx [333D58C6:000000000001]
1-31-2008 4:32:05 pm: DS-10553.37-268
Intruder lock-out on account .xxxxxx.xxxxxx.xxx [333D58C6:000000000001]
It has occurred for several different users. Some have been addressed by uninstalling Adobe Acrobat and reinstalling, which reset the automated update agent. Some were addressed by changing to our cable gateway versus our dsl gateway, which bypasses our content filtering process. We know it is related to an authentification issues, but don't know how to determine the cause of the user's issue. The user names in the log are legitimate but all reference the same [333D58C6:000000000001] item. We do not know how to determine what is causing the problem so we can correct the authentification problem.
Cliff
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I checked, and the IPX address references is the Internal IPX number of the server where the intruder lockou errors are occurring.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The problem is that although it may be the iprism, the issue with adobe was resolved by uninstalling and reinstalling. However, the current user with issues does not have that software installed.
I turned off arcserve services from the workstation but it had no affect on the intruder lockout process.
We removed the proxy in IE that pointed to the iprism and had no luck with that either.
I turned off arcserve services from the workstation but it had no affect on the intruder lockout process.
We removed the proxy in IE that pointed to the iprism and had no luck with that either.
So you still have users getting locked out for no apparent reason, and they're not going through the iprism. You say "the current user with issues" - does that mean you're down to one?
Is CIFS enabled? Is it possible they're connecting with the normal client process for the most part, but using CIFS to access another service?
If you're not using NMAS authentication, and CIFS is using the simple password, they can get out of sync.
Another possibility to check - make sure the Novell client is only using TCP/IP. Strange things can happen when the client can use NCP over more than one transport.
Is CIFS enabled? Is it possible they're connecting with the normal client process for the most part, but using CIFS to access another service?
If you're not using NMAS authentication, and CIFS is using the simple password, they can get out of sync.
Another possibility to check - make sure the Novell client is only using TCP/IP. Strange things can happen when the client can use NCP over more than one transport.
ASKER
We have switched several users off that gateway and it corrected the problem for them but not for others. Again, the adobe acrobat update process is part of it. Don't know why it did not happen before.