Waffle authentication after domain user change

[Evgeny]

I use Waffle to authenticate domain users on Tomcat and then forward some info to WebSphere that works under Java 1.4.

So WebSphere users have single sign-on option.

Recently our admin changed name of a domain user.

After that the user can't automatically login through Waffle-Tomcat-WebSphere.

I read Waffle log files and found out that the workstation of the user still send tokens with old user name.

Waffle (Tomcat) authenticates the user and forward special info to WebSphere.

WebSphere says in its log that can't find user by such id - this is ok because such old user is removed from the domain.

So, what is the best practice for this case.

Where and what actions should I do to instruct the workstation to renew user's token.

I asked the admin to change also the computer name but it made no sense.

[Daniel Doubrovkine]

I would imagine that if the user were to logout on the workstation and log back in with the new username, he'd get a brand new context with all the information updated. It's weird though, the username shouldn't be relevant in SSO - what's the protocol chosen for the negotiation (NTLM or Kerberos?).

--

dB. | Moscow - Geneva - Seattle - New York
dblock.org - @dblockdotorg

[Evgeny]

Unfortunately, I can't check negotiation settings right now because I'm already at home.

But I've recalled that I use some caching in Tomcat.

Tomcat has not been restarted for months, so it might cache quite old information.

Other evidence is that the user correctly authenticates on the test environment with the same topology where the user has not ever logged in.

I'll verify that and write back on monday.

Have a nice weekend.

пятница, 21 сентября 2012 г., 17:33:58 UTC+4 пользователь Daniel Doubrovkine написал:

[Evgeny]

Caching makes no problem.
Now I think that the problem may rise from long living Tomcat sessions.
When the user visits a page Tomcat picks up his old session and returns his old name as the principal name.

So, what is a way Tomcat decide whether to start new session or keep the previous one?

[Daniel Doubrovkine]

This is more of a Tomcat question, but you can configure expiration like this:

1.<session-config>

2.<session-timeout>30</session-timeout>

3.</session-config>

Google has a ton of results on session expiration, persistence, etc.

[Evgeny]

Of course, I know this is not a Tomcat forum. ;)

Actually I meant a mechanism that provides user identity for Tomcat.

If Tomcat sees the same user it picks up his old session and further checks session expiration by timeout and other custom conditions.

It's probably waffle.apache.NegotiateAuthenticator provides the user identity.

I've decoded NTLM tokens from the log file and found out that token does contain correct new user name, but NegotiateAuthenticator after all negotiations reports old user name.

Please find below log file extraction.

All messages are prepended by the same header so I moved it to the top.

I also group messages into 3 groups for 3 negotiation rounds.

I've found out also that new user name has the same object sid (admin confirmed that).

So, is it possible that NTLM implementation (in Waffle? in Windows?) takes new user name, then identifies it in domain, then gets object sid and then gets old user name from some local cache by this object sid?

==log file extraction==

<DATE> <TIME> waffle.apache.NegotiateAuthenticator authenticate

FINE: GET /sso/, contentlength: -1

FINE: authorization: <none>, ntlm post: false

FINE: authorization required

FINE: GET /sso/, contentlength: -1

FINE: authorization: Negotiate <a-short-token>, ntlm post: false

FINE: security package: Negotiate, connection id: 192.168.6.108:56581

FINE: token buffer: 40 byte(s)

FINE: continue required: true

FINE: continue token: <outgoing-long-token>

FINE: GET /sso/, contentlength: -1

FINE: authorization: Negotiate <incoming-long-token-with-NEWNAME>, ntlm post: false

FINE: security package: Negotiate, connection id: 192.168.6.108:56581

FINE: token buffer: 454 byte(s)

FINE: continue required: false

FINE: logged in user: DOMAIN\OLDNAME (<OBJECT-SID>)

FINE: roles: <some AD groups>

FINE: session id:6B2BF83C4241F62A3742E28CDB308A21

INFO: successfully logged in user: DOMAIN\OLDNAME

 

[Daniel Doubrovkine]

Once you had authenticated with Waffle, ie. the server sent a 401, the client did the whole negotiate dance and back and forth, the sever establishes a session and uses that for subsequent authentication. The principal will be stored in the session and reused.

You can see this in https://github.com/dblock/waffle/blob/master/Source/JNAWindowsAuthProvider/src/waffle/servlet/NegotiateSecurityFilter.java

if (doFilterPrincipal(request, response, chain)) {
			// previously authenticated user
			return;
		}

That's why I thought session expiration would clear this, the server would return another 401 and we restart the auth.

So I think your root problem is that you should never rely on the username, it's just FYI information from the domain controller. The SID is the only permanent identity in all of this, so your Websphere app needs to be using that and not the friendly name. There's nothing wrong with this entire security context to be persisting forever. Next time a user logs on some PC he get a new security context and then presents that to whatever server(s).

[Evgeny]

I have googled a bit and found MS Kbase article that explains it at all.

The short story is that the server attached to a windows domain maintains a local cache of SID-to-username mappings.

All cache entries have time out but when a user contacts the server day by day they usually don't expire.

The cache can be disabled (temporarily) through the windows registry.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa 

add DWORD LsaLookupCacheMaxSize=0

When the user is authenticated on the server and the Waffle reports new user name we can roll back registry changes.

I tried LsaLookupCacheMaxSize=0 and the user was authenticated right away with the correct new name - without server restart.

Long story - http://support.microsoft.com/kb/946358

Thanks for your help, Daniel.

[Daniel Doubrovkine]

Can I please ask you to contribute an entry to the FAQ?

Fork  https://github.com/dblock/waffle/, contribute it to the 1.5 branch. 

You can add an entry to https://github.com/dblock/waffle/blob/1.5/Docs/FAQ.md, with a page under Docs/faq and a link to this thread.

Thx,

dB. 

[Evgeny]

Of course, but

How can I register for this site?

I have no user account and I don't see a registration link.

среда, 26 сентября 2012 г., 16:06:25 UTC+4 пользователь Daniel Doubrovkine написал:

[Daniel Doubrovkine]

You mean for Github?  :)

https://github.com/signup/free

[Evgeny]

That's all.

Please check my entry on the mentioned page.

среда, 26 сентября 2012 г., 17:21:41 UTC+4 пользователь Daniel Doubrovkine написал: