[foaf-protocols] microsoft kerberos in www-auth, over FOAF+SSL- help wanted

[Bruno Harbulot]

Hi Peter,

I haven't had time to look at your latest messages in details. I haven't 
used SPNEGO/Kerberos for some time, but if I remember well, here are a 
few things to set up (not sure if this can help here):

- There's something about mapping the user:
    ksetup /mapuser * *
or ksetup /mapuser user at REALM localuser

- Could this have to do with the allowtgtsessionkey registry entry in 
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters?
   http://support.microsoft.com/kb/308339
   http://support.microsoft.com/kb/837361

I'll try to look into it next week.

Best wishes,

Bruno.


Peter Williams wrote:
> To save me some time, perhaps someone already knows the answer to 
> Kerberos over TLS, and showcasing delegation.
> 
>  
> 
> Having done my digest auth experiment for indirect reliance 
> investigation, I’ve now added support to my foaf+ssl responder so it can 
> ask the browser to “negotiate” www-auth headers. If the (IE) browser 
> determines it can indeed supply Kerberos tickets in the www-auth HTTP 
> headers (over the FOAF+SSL channel) it will do so. Assuming it can, one 
> type of kerberos ticket allows for “constrained-delegation” (vs spegno 
> style delegation), allowing the server to consume further services using 
> the authority of the user. Unlike unconstrained delegation (shib-style 
> spegno), constrained-delegation applies several advanced features of 
> Kerberos (and token translation services) to limit a server’s potential 
> to abuse a user trust. Trust is “constrained”, if you will.
> 
>  
> 
> Today, my use of negotiate is inducing the browser to send NTLM 
> credentials vs Kerberos credentials (and NTLM doesn’t have the 
> constrained-delegation feature). Turning on Kerberos requires X.
> 
>  
> 
> Anyone tell what X is?
> 
>  
> 
> Here are my guesses (from what I remember from my MCITP certification 
> course on windows):-
> 
>  
> 
> 1.      FOAF+SSL Certs on client must have UPN field in SAN
> 
> 2.      Cert on SSL server must have SPN field in SAN
> 
> 3.      The windows identity under which the Server operates must have 
> an SPN and have registered it specially (there was some tool to do this)
> 
> 4.      One sets  flags (somehow) that control how service tickets are 
> minted and thereby control such as “constrained-delegation” options.
> 
>  
> 
> So, in a FOAF+SSL context (where FOAF+SSL is controlling and governing 
> the channel and its uses), anyone give me advice on whether the above is 
> correct, sufficient, and how to do it?
> 
>  
> 
> One we have something practical working, we will have something 
> mainstream (and working) - to compare against our own delegation 
> concepts that leverage linked data ways of thinking.
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols