• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1793
  • Last Modified:

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
0
cwsoft05
Asked:
cwsoft05
  • 3
  • 3
3 Solutions
 
ShineOnCommented:
It sounds like something is sending multiple login attempts on a particular server interface.  I'll bet 333D58C6 is one of your NetWare server's server ID's (formerly known as internal IPX number) - possibly even the one on which the lockout messages appear, or perhaps the "content filtering process?"

You say it started "after routing password changes" - can you explain that?  I understand "after password changes" but what's the word "routing" in reference to?  Network devices or processes that route traffic, or passing change info around manually or via email, or something else?

Does the content filtering process use something that leverages eDirectory?  Does that server log in to eDirectory to check a user's group membership, or use secure LDAP lookup or something?  Is it possible that either the content filtering process has an expired password that needs changing, or that the certificates need refreshing or something along those lines?
0
 
cwsoft05Author Commented:
Routing is a misspelling.  Routing should be Routine.  The content filtering is Isprism.  It only affects some users and it comes/goes.  I will have to check into the process, but it needs access to the edirectory to lookup the group membership for determination of internet classes, which defines where they can go on the internet.

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.
0
 
cwsoft05Author Commented:
I checked, and the IPX address references is the Internal IPX number of the server where the intruder lockou errors are occurring.
0
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
PsiCopCommented:
Sounds like there's an automated process running on the server (good candidates including backup software, tools like RSync, and anything else that needs to authenticate to eDirectory in order to function) that's using old credentials.
0
 
ShineOnCommented:
I think you should concentrate on the Isprism process, personally.  It's either got a service ID password problem or something related to the user ID lookup.

The reason I suspect that is because the acrobat update process appears to be triggering an authentication, and it's failing, sufficient times in a row to trigger the lockout.
0
 
cwsoft05Author Commented:
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.
0
 
ShineOnCommented:
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.
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now