NTLMv2

[juergen]

Hi there,
we've got a win2k3 ad domain and I've noticed that ntlmv2 with connectra does not work!! FileSharing and WebApplications don't work from connectra. After several unsuccessful tries the account gets locked out. as the software comes with samba 2.2.7 is there a chance to get it work with NTLMv2. I don't want to switch back to old NT times....


thank you!

[RayPesek]

How do you have Connectra set up for authentication?

Have you looked at the release notes for Connectra NGX R61, which was put on the download site a week or two ago? They did some work on some authentication issues, but I don't recall precisely what it was.

Ray

[juergen]

Sorry I’ve forgotten to mention that we are using the newest version NGX R61. Authentication is done with certificates (PKI) or one time passwords with RADIUS. The Authentication works fine, no problem at all. However if the logged in user tries to access a file share on a win2k3 fileserver or a web resource with NTLM access fails…
In the evnetlog on the windows file server you’ll see the follwing error message:
Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 529
Date: 25.04.2006
Time: 19:28:38
User: NT AUTHORITY\SYSTEM
Computer: NAMEOFMYSERVER
Description:
Logon Failure:
Reason: Unknown user name or bad password
User Name: USERNAME---
Domain: DOMAINMAE--
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: \\IP of connectra
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: IP of connectra
Source Port: 0


For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

[RayPesek]

Are you by any chance trying to use multiple Windows domains? Here's what I had:

Windows IAS server was in domain "A"

User was in domain "B" and file share was in domain "B" with a two-way trust to "A"

For granularity, I created the user in Connectra as "B\user" with RADIUS to the IAS server.

Virtually everything worked except for file shares. It gave me an unknown user message. A packet capture showed the authentication traffic was being passed to the file share as "A\B\user"

The only fix was to leave the file share field "Windows default domain" blank AND configure the share to prompt for credentials rather than passing the portal credentials.

Check Point came up with this workaround. They said I should have set up the user as "generic*" and used RADIUS groups to handle the access rules, but they also said we lose granularity with that solution, which is why we didn't do it.

Ray