Dave,
    To answer some of your questions... 
    We are authenticating the users on AD using AAA.
 
Our users are explicitly granted dial-in permissions on a per user basis.  Although some of the acct's that work are set to "Control Access through Remote Access Policy"  This got me looking at the Default Remote Access Policy, which might be something for me to tinker with next.
 
The successful and then failed attempts appear like this on the Concentrator:
 

693 09/03/2003 15:15:28.830 SEV=6 AUTH/4 RPT=313 Authentication successful: handle = 895, server = 10.10.10.239, user = vpntest

776 09/03/2003 15:15:54.770 SEV=3 AUTH/5 RPT=101 Authentication rejected: Reason = Invalid password handle = 896, server = 10.10.10.239, user = ciscovpn, domain = <not specified>

Again I know the password isn't bad, becasue I use the acct. to do other things.

The Pre-Authentication failed is a canned MS event entry.  From my research it seems that this is the same entry that would appear if you were to enter the wrong password when trying to authenticate onto the domain.  Although when I am using one of the bad accounts the VPN kicks me back to the logon box pretty quick.  It was so fast that I first thought that it wasn't even making an attempt, but I was able to dig up the failed attempt from my Win2k Event logs.

Some of your other questions I am unable to answer as I don't have access to config. the concentrator.
 
Thanks for your help,
 
-Tim



From: Dave Kinnamon [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 04, 2003 1:24 PM
To: [EMAIL PROTECTED]

Tim,

 

 

A few questions …

 

How are VPN users being authenticated?  Local user database on the VPN Conc. (ughhh!) or remote database?  --- likely AD Users through Cisco’s AAA product “Cisco Secure ACS.”

 

If they’re all going through ACS to AD, did you setup ACS to use the “Check User Dialin Permissions” option?

 

If yes, how do you grant dialin permissions?  GPO or explicit Allow or Deny in a users account

 

Have you observed the failed attempts in ACS?  Does the reason given make any sense or help?  i.e. Bad NAS or bad password

 

On the VPN concentrator in Configuration | User Management | Base groups or Groups options – have you checked “Allow Alphabetic – Only Passwords”?  I can envision strange problems if the “password options” on the VPN concentrator don’t agree with AD’s complexity requirements.

 

Also, the statement that “Pre-authentication failed” makes me think that maybe you aren’t even passing Phase 1 authentication.  And in that case you won’t even see a record in ACS – just in the event logs on the VPN Conc.

 

 

I hope something here helps …

 

Dave

 

 

 

 


From: Wright, T. MR [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 04, 2003 11:52 AM
To: [EMAIL PROTECTED]
Subject: [ActiveDir] Possibly OT: Cisco VPN and AD

 

We have an issue with our VPN concentrator.  It seems that it allows some AD users to authenticate, while others can not.  We can find no pattern to explain why the users that are able to authenticate are allowed to do so and why the users that can't authenticate can not.  An example is that I have two domain admin acct's, one that is a Service acct. and one that belongs to me.  I am able to authenticate using the service acct. but not my own acct.  They are in the same OU, they have permissions to the same groups etc.  The only thing I see in the event logs upon an authentication failure is a generic EventID 675 with Pre-authentication failed, with Failure Code 0x18, which translates to a bad password, but I know this is not the case since I use my admin account to logon to other resources etc.

    Our network guys have been in contact with TAC and they don't seem to have a clear answer either.  They feel it it is something in our GPO.  The thing is our GPO settings are not rocket science.  Right now we are basically just enforcing complex passwords etc. and we're not doing much outside of that.  I was hoping that someone might have had these issues before and could provide some insight.

 

Thanks,

 

-Tim

Reply via email to