04-14-2005 10:47 AM
We recently purchased a Cisco 3005 VPN Concentrator for WebVPN access to our intranet web applications.
We are having problems with Configuration->System->Servers->Authentication to work with KERBEROS/Active Directory.
We do have it working with the NT Domain type, but that is not our desired setup.
The device can talk to the AD controller. In fact, it can find valid users and even alert me when I have a bad password (using the TEST button for that setting).
However, whenever I enter valid credentials, it always responds with "Authentication Rejected: Unspecified"
The event log on the device contains the following entries:
7736 04/14/2005 14:43:22.400 SEV=3 AUTH/5 RPT=84
Authentication rejected: Reason = Unspecified
handle = 341, server = controller.domain.com, user = username, domain = <not s
pecified>
Any idea on what the problem could be? I have tried using an IAS server but with the same results.
04-15-2005 05:52 AM
Just so you don't go crazy; I tried here with "kerberos" and for 3 months could not get it working... I think the reason was that if the AD domain controller is no a forrest root domain controller it somehow messes up the REALM for the ad forrest and can't take this kind of kerberos ticket request... Man we spent like 4 saturdays trying to get this to work... Finally went with "NT DOMAIN" which works fine, you can also disable group lookup, so your users can type the full ad login
user123@somecompany.com and use just 1 password for everything.
If anyone can solve the Kerberos enigma with 3000's please tell us !
04-20-2005 11:12 AM
CISCO support offered the following advice that worked for us:
1) Goto the user account object in Active Directory Users and Computers
2) Bring up the Properties window for that user object
3) Go to the Account tab
4) In the Account Options section, make sure "Do not require KERBEROS preauthentication" is checked
05-12-2005 12:38 PM
Thanks for this info, it helped fix my issues of some AD users not being able to log on.
Any idea what causes this, and why some users were authenticationg ok, and others were not?
Before i had users that were in identical security groups, in the same OU within AD and one would log on, and the other not. After selecting this option the user was able to log in.
Thanks.
Neal.
05-12-2005 08:49 AM
Hi,
Had this today with a VPNC3020 (vpn3000-4.7.Rel-k9) and AD.
Have you tried entering the kerberos realm in uppercase? e.g. REALM.COMPANY.COM
This worked for me today and i was gettting the same as you, it reported bad passwords or usernames, but unspecified on correct credentials.
Also check you are using port 88 (or 0 as default).
I've now got authentication to AD working, however some AD users work fine, and others fail to authenticate. No idea why?
Best regards,
Neal.
05-12-2005 11:30 AM
We have abandoned our attempt to use the VPN 3000 concentrators since our primary goal was a SSL VPN. We have since begun a pilot / proof of concept of a true SSL VPN that integrates beautifully with Active Directory and Microsoft products.
Sorry I can't help you with you problem.
06-29-2005 12:34 PM
I know this is late, but in case someone else stumbles onto this ...
Besides everything Neal said, make sure the realm is right because I saw reported bad passwords and usernames, but unspecified on correct credentials with a bad realm.
Also, double check that the time on the VPN matches the time on the AD server that you are authenticating against and that all AD servers match as well.
09-08-2005 12:15 PM
Thanks for your helpful post to make sure the REALM is correct. That was our issue and once the realm was exactly correct, then authentication works via Kerberos. Funny thing was, on the Windows Event viewer it never complained about it although on the Cisco VPN concentrator it would fail until the realm was correct.
Regards,
Tim
09-08-2005 03:22 PM
Hi, I had this too, but solved it by having the Realm in upper case.
For example:
In Configuration | User Management | Groups | Authentication Servers | Add, Select server type = Kerberos/Active directory, Authentication Server = 192.168.90.3, Realm = DC.DOMAIN.COM. Leave the other settings at default. Press Add to add the new Authentication Server
Test this out and you should find it works.
good luck,
Neal.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide