Kerberos Authentication implementation

feels a little double to auth with kerberos and then check the credentials again, but that is up to you

check this link for an explanation how you could build the auth based on Kerberos part

http://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-aaa-auth-config-11-1-0/4.html

hello, thanks for your reply. i just forget to explain that second check is on another ldap server. So, client with kerberos arrives on vs, i retrieve the username and check if on the second ldap server is present, if yes i take a code number stored and use it as credential to send to application.

i will try the example u linked.

regards

One important thing to understand here is that the (web) client won't send a Kerberos ticket unless the server asks for it. This is generally in the form of a 401 response with a "WWW-Authenticate Negotiate" header. If the server sends a 401 with this header, and the client cannot comply (not a member of a domain), then the browser may attempt to failover to an NTLM prompt. This may not be what you want, and will certainly alter the existing form-based user experience. If you have clients that won't have Kerberos tickets, it may be best to evaluate these based on some known criteria, like IP subnet (ie. internal vs. external users). That way you could present a form logon for external users and 401 for internal users. If submitting via form, the APM logon page will by default populate the session.logon.last.username variable with the submitted name. If submitting via Kerberos ticket, upon successfully authentication, the user attribute will be stored in the session.logon.last.logonname as a userPrincipalName value (ex. bob.user@domain.com).