• Ticket is still avilalble despite the fact that the account is locked down

Ticket is still avilalble despite the fact that the account is locked down

  • 240 Views
  • Last Post 01 February 2017
boaz20 posted this 31 January 2017

Dear experts,

 

When implementing my application that is based on Weblogic – (with LDAP connection for Active directory for SSO capabilities against active directory 2008) – I notice during testing that when the end-user account get locked down… the user can still login to the app because the Kerberos ticket (klist) is still available.  Is there way to shorten the ticket expiration date OR is there configuration/setting in active directory to expire all tickets for account that has been locked down?

active-directory exchange group-policy
Order By: Standard | Newest | Votes
jeremyts posted this 01 February 2017

Very true.

 

From what I’ve seen and projects I’ve been part of, Weblogic uses Kerberos via keytab and krb5 config for SSO and LDAP for validation of the user.

 

Now that I understand what is meant by “locked down”, maybe here the trick is to change the ldap query from Weblogic to check the lockoutTime attribute? It

sounds like they are already checking for disabled and expired accounts.

 

Boaz, typically an apps team will be the owner of the Weblogic service, or you may have it outsourced. Either way, if you can find out what the LDAP query it’s

using is, we can help make suggestions on how this can be tweaked. You can test this using Joe’s AdFind utility.

 

Cheers,

Jeremy

 

show

barkills posted this 01 February 2017

Well, when whoever suggested that weblogic is using LDAP, I’m not sure that’s the whole story. I’m not closely familiar with weblogic, but with a quick minute

of browsing, I see it has web-based components. In which case, you’ve got another potential layer (or a different layer) in the story. When I said the authentication method used by LDAP depends, there are a lot of complex details behind that or I would have

spoken more specifically. At the simplest level, the LDAP client sends a username and password. At the more complex end, it might be Kerberos via SPNEGO. But with weblogic, it may be that the LDAP client is wrapped by a web server (or there is no LDAP involved

and it is basic or integrated windows auth), in other words, the web server proxies the LDAP connection for the client. In which case, there may be a token/cookie that persists past the LDAP connection and even the web session. With web services that use simple

authN, the web server retrieves a logon token on behalf of the client. Depending on the design, that logon token might persist beyond the session and the web service might use cookies that allow re-use of the token.

 

Lots of complexity, but it all goes down to understanding how something is designed, which so few vendors document.

 

Brian

 

show

gazzadownunder posted this 01 February 2017

The AD LDAP bind process will honour account state, i.e disabled or locked and will not authenticate the request for the provided credential, so its likely this is a behaviour of the weblogic app.
To help explain why you have different results between the two scenarios is probably related to ldap bind implementation in weblogic. To complete a simple bind requires the users DN/CN as the username. Normal the ldap implementation will use a master service account to search the directory for the user's CN based on the username provided by the user or sso. Its most likely that the weblogic app is also checking if the account is disabled as part of this search and doesn't perform the subsequent bind to validate the credentials of the account is disabled. This check probably doesn't look at the account's lock out state and then uses a previously cache set of rights.
Gary.
On Feb 2, 2017 04:16, Boaz Galil <boaz20@xxxxxxxxxxxxxxxx> wrote:
Brian and Michael - thank you very much for the information. How do you explain the fact that I see different result between the following scenarios - just wondering if you have any theories about it? and is it related to the ticket life-time?
Scenario A - 1.user logins to his computer... then logins to the app based on weblogic...2.User logoff from the weblogic app  - in the background the user is disabled in active directory - user try to access the weblogic app (SSO/LDAP) and the login is failing (make sense).
Scenario B -1.user logins to his computer... then logins to the app based on weblogic...2.User logoff from the weblogic app  - in the background the user is getting his account locked out (by entering wrong password) - user try to access the weblogic app (SSO/LDAP) and login successful (despite the fact that the user is locked out in active directory).

show

a-ko posted this 01 February 2017

Session cookies?

 

show

boaz20 posted this 01 February 2017

Brian and Michael - thank you very much for the information. How do you explain the fact that I see different result between the following scenarios - just wondering if you have any theories about it? and is it related to the ticket life-time?
Scenario A - 1.user logins to his computer... then logins to the app based on weblogic...2.User logoff from the weblogic app  - in the background the user is disabled in active directory - user try to access the weblogic app (SSO/LDAP) and the login is failing (make sense).
Scenario B -1.user logins to his computer... then logins to the app based on weblogic...2.User logoff from the weblogic app  - in the background the user is getting his account locked out (by entering wrong password) - user try to access the weblogic app (SSO/LDAP) and login successful (despite the fact that the user is locked out in active directory).


show

barkills posted this 01 February 2017

To explain a bit more, LDAP authentication is very different than Kerberos.



 

With LDAP authentication, you make a connection (hopefully with an encrypted session), then you perform a bind operation. What authentication mechanism is used

depends, but after you’ve completed the bind operation, the resulting session needs no further bind/authentication. As long as that session does not hit a time out or is closed, it is good to go to perform any other LDAP operation allowed by the security context.

 

show

a-ko posted this 01 February 2017

Exchange has RPC connections to AD and does not use a simple LDAP Connector and filters.

 

show

boaz20 posted this 01 February 2017

Hi Michael,
Thank you for your respond.  do you have any theory - for the scenario I have described in my previous message?  User get locked down (because he entered wrong password few times) - immediately, outlook disconnect from exchange but the user is still able to access application that is based on weblogic (SSO, connected with LDAP adapter to the Active directory) -  regardless of the ticket lifetime, how did outlook/exchange detect that the user is locked immediately? What is the mechanism behind it? basically I am trying to have the same mechanism with the weblogic (I guess its not related to the ticket lifetime? because outlook got disconnected seconds after the user got locked).


show

a-ko posted this 01 February 2017

In short, there is no way to nuke Kerberos ticket lifetimes. They will still be valid for the duration of the ticket.

 

I would have thought that AD sets the lifetime only and does not allow a system to request a shorter duration. Though I’ve never actually tested that behavior.

So maybe the AD settings is just a “maximum”?

 

The problem with changing Kerberos ticket lifetimes is that users will have to re-authenticate when that lifetime expires. So if you set it to something

like 1 hour, then your users will have to re-authenticate every hour.

 

show

boaz20 posted this 01 February 2017

Hi Jeremy,
So when we disable the account through AD - the user is unable to browse to the app... but when we lock down the account (user enter the wrong password few time) - despite the fact that the user cannot enter to different applications like outlook/etc - he can login to the app (based on weblogic).


show

jeremyts posted this 31 January 2017

Hi Boaz,

 

I’ve never tried it myself. But as these are supported parameters in the

krb5 config file, the request via Weblogic may honour them.

 

When you say “locked down” do you mean disabled or expired?

 

Cheers,

Jeremy

 

show

boaz20 posted this 31 January 2017

Hi Jeremy,
I thought that the ticket life time is something that the AD responsible and not the webserver/weblogic - I guess I am wrong?


show

jeremyts posted this 31 January 2017

You can probably do this from the Weblogic server itself within the krb5 config.

 

Cheers,

Jeremy

 

show

Dima Razbornov posted this 31 January 2017

Yep. But only for these resources, which Kerberos ticket he has got for the ticket lifetime. He can't ask the new one or renew the old one after you unlock his account.

Cheers, Dima.

boaz20 posted this 31 January 2017

Hi Ken,
So the overall behavior make sense? user that are locked down can still access resource for 10 hours or am I missing something?


show

kbatlive posted this 31 January 2017

You can shorten the lifetime (default is 10 hours – but goes down to 4 hours I think in win/2016?). 



 

I’m not aware of any way, using Kerberos of killing a issued Kerberos ticket at the DC after it has been issued and it is still valid.  Using

claims it should be possible (but I’m not a claims expert…yet! J

)

 

Here is an article that describes changing the time – and some other items that can be changed from in Kerberos policy area via GPO:

https://technet.microsoft.com/en-us/library/jj852258(v=ws.11).aspx

 

Good luck!

 

 

show

Categories
Search
Popular Tags
Hot Topics
Close