Highlighted
New Member.
1406 views

Connector Appliance - Account Lockout

Greetings,

I am experiencing a problem with a domain account being locked out by a connector on a connector appliance.  Reviewing the domain controller logs I can identify the source of the lockout as "JCIFS#_#_A#" where #_#_A# appears to be an alphanumeric identifier (e.g. JCIFS0_1_C1).  I believe this is probably a mount point created by the WUC on the connector appliance.

The problem is that I have WUCs running on about 10 different appliances and this had made it difficult to identify what single connector appliance is causing the lockout.  I've already created a new domain account and applied this to the WUCs on all appliances, however, the problem continues to occur.

Does anyone have any suggestion for matching this JCIFS mount up with a specific connector and system on an appliance?  Thanks in advance for your help!

Jeremy

Labels (2)
0 Likes
Reply
15 Replies
Highlighted
Absent Member.
Absent Member.

Re: Connector Appliance - Account Lockout

Have you tried checking Windows logs for failed authentication attempts for that account?

0 Likes
Reply
Highlighted
Absent Member.
Absent Member.

Re: Connector Appliance - Account Lockout

This has been a major problem for me also. My solution was to use a different usernames for each connector.

0 Likes
Reply
Highlighted
New Member.

Re: Connector Appliance - Account Lockout

Thanks for the suggestions!

I've been monitoring the Windows event logs for failures for several days.  I'm using the Windows account lockout status tool to identify the domain controller where the failures are occurring and then viewing the events on that server.  The problem I'm having is that the source of the failures is identified as JCIFS0_1_B2 or something similar.

I believe these sources are CIFS mounts created by the WUC.  Everytime the connector is started/restarted, a new mount point like this is created.  I'd like an easier way to identify the connector that is doing the creating.  There are mutiple connectors that are creating these mounts, even on a single appliance, so it can be difficult to determine the connector with the problem.

Using connector status events, I've been able to match these references to "JCIFS" to an appliance, but thats about as far as I can go.  I've reentered the domain, user and password many times over on multiple appliances and connectors, but the lockouts persist.

Also, I like the idea of using separate accounts for each appliance, however, we are trying to limit the number of admin accounts on our domain.

0 Likes
Reply
Highlighted
New Member.

Re: Connector Appliance - Account Lockout

Update:

Accounts continue to lock out, regardless of whether I use a different account or not.  I've re-entered the domain, username and password several times for several hundred hosts.  If I delete a connector the lockout source moves to a different connector that was working previously.  The only surefire way to stop the lockouts is to remove the account from all connectors.

When monitoring the DC logs I no longer see any failed authentication events, just successes and then an account lockout event.  To me this means that the source of the lockouts is not a system that I'm logging events from.  I suspected it could be caused by mismatching kerberos timestamps, but the domain admin assured me that is not occurring.

As other accounts in the domain have begun to lock out sporadically, I think the source of the problem is with our DC configuration.

0 Likes
Reply
Highlighted
Absent Member.
Absent Member.

Re: Connector Appliance - Account Lockout

Jeremy,

Did you ever find root cause and, more importantly, a root fix to this issue? As I'm seeing similar behaviour 😞

Thanks, jhs

0 Likes
Reply
Highlighted
New Member.

Re: Connector Appliance - Account Lockout

There were a number of problems that were causing this, but I was able to fix the issue eventually.  We were in the middle of a migration from a  2003 to a 2008 domain and this initially caused some problems.  I'll see if I can dig up the exact reason from the support tickets I created.  Some security controls had been tightened as well.  Here are a few that I can remember off the top of my head:

1) Try using the pre-2000 account name if your service account name is long (max of 20 characters)

2) Set your LAN manager authentication level on the system(s) you are connecting to "Send NTLMv2 response only\refuse LM".  I know the security risks involved with NTLM, however, the logon information always appeared to be truncated on the Windows system if I refused both LM & NTLM.  Kerberos is not supported as far as I know.

3) Check your account and password expiration policies

4) Use a different account for the CIFS mounts you create (LAN manager authentication level comes into play here as well)

5) Confirm that any domain accounts are replicating properly (I used the MS lockout utility to monitor for the DC where the lockout was occurring and checked the logs on that DC)

Edit:  I believe the problem with the DC migration was that Kerberos client certificates and/or the KDC certificate were becoming corrupted (http://technet.microsoft.com/en-us/library/dd348640%28WS.10%29.aspx).  This was not so much a problem with the appliance but the clients that the appliance was authenticating to.  Paired with the account truncation issues, it was quite a headache.

0 Likes
Reply
Highlighted
Absent Member.
Absent Member.

Re: Connector Appliance - Account Lockout

Thanks Jeremy! It seems this was a very specific cause then.

Despite the fact that I was told that the account(s) were unlocked. They were not, it took several hours after to have them unlocked.

I'm not quite sure as to why the account got locked out, but I suspect a PEBKAC on my behalf when editing the table on the connapp.

cheers, jhs

0 Likes
Reply
Highlighted
Outstanding Contributor.
Outstanding Contributor.

Re: Connector Appliance - Account Lockout

Did you try setting windowsfg.jcifs.netbios.hostname=abcd in agent.properties?

This will force a NETBIOS connection on port 139 as well as the standard 445.

I have found this at least helps me find which ConApp is hosting the connector.  I am also finding that the connector doesnt seem to listen to what I specify at abcd, and instead just uses the hostname of the ConApp.... Well, at least thats better than JCIFS_blah....

HTH,

Ian.

0 Likes
Reply
Highlighted
Absent Member.
Absent Member.

Re: Connector Appliance - Account Lockout

I am having this issue also where I have a lockout problem but can't figure out what is causing it. I have double checked and triple checked the user name and password but still the lockouts continue. Like the original poster in this thread all the logs show for the source is that generic JCIFS name which I can't match up to any specific connector. If someone has a method for matching up that generic JCIFS name to an actual connector I would love to hear it because this is driving me insane!

Also if someone knows a way I can change that name to something more meaningful or where that name comes from I would love to hear that too! I checked the agent.properties file and don’t see the windowsfg.jcifs.netbios.hostname parameter that Ian mentioned or anything that even remotely resembles it.

0 Likes
Reply
Highlighted
New Member.

Re: Connector Appliance - Account Lockout

The windowsfg.jcifs.netbios.hostname parameter isn't in agent.properties by default. Simply add the line to the end and assign it a value. Also, i found that on my c5100/5200's w/ more than one container, it helped to add cX to the end of the hostname, where X is the container number.

0 Likes
Reply
Highlighted
Absent Member.
Absent Member.

Re: Connector Appliance - Account Lockout

Is the JCIFS mount name actually logged somewhere by Arcsight?  If so where?

0 Likes
Reply
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.