Windows Auto-auth

[Ben Creech]

A while ago, I posted a question on Microsoft's platformsdk.security
MSDN newsgroup asking what Windows does with that memory, but the
question went unanswered.  If I had gotten an authoritative response
that said "the memory is treated as sensitive", then I probably would
have gone that route.

It would be really cool if someone were to write a fully-featured
alternate ticket cache as an LSA custom authentication package.  I think
that would be Better in many ways than the current krbcc memcache. 
However, custom ap's seem to be overcomplex and underdocumented, which
is probably why no one has bothered.



On Fri, 2003-01-17 at 00:01, Marc Reyhner wrote:
> The Stanford Kerberos client currently does the approach of using a
> network provider dll and then creating a script to run on session
> startup containing the username/password of the user in the command line
> arguments.  It's a horrible idea from a security perspective (don't
> blame me it wasn't my idea :-) ) since getting command line arguments is
> trivial if you are an admin.  Windows doesn't think the scripts contain
> sensitive information so I don't think it does anything really to
> protect the scripts and wipe memory.  The only redeeming point of this
> approach is I don't think you can get the password without being an
> admin.  The way you are working on sounds like a lot better approach
> since you can protect the password better.  Ideally I'd like to see a
> system service like the LSA which would centrally manage the tickets so
> impersonation worked correctly and system services could read/write the
> ticket cache.
> 
> Marc
> 
> -----Original Message-----
> From: Ben Creech [mailto:bpcreech at eos.ncsu.edu] 
> Sent: Wednesday, January 15, 2003 8:35 PM
> To: krbdev at mit.edu
> Subject: Windows Auto-auth
> 
> Has anyone worked on auto-auth on Windows recently?  I'm just wondering
> what experiences other people have had with this.  Specifically, the
> kind of auto-auth to which I'm referring grabs the Windows login
> password and uses it to grab a Kerberos tgt and various sgt's (most
> importantly for AFS).  This way users have the access they need as soon
> as the machine finishes logging in, providing a sort of "single
> sign-on".
> 
> Currently I'm working on a project that uses a network provider dll and
> a Windows service to hold tickets until the user has a desktop in which
> for krbcc32s.exe to reside.  
> 
> Formerly, NCSU had a custom gina, but it was a pain to support, partly 
> because it had to also implement the functionality of the NetWare gina, 
> partly because it was written in NT4 days when (from what I understand)
> Microsoft was changing the gina specs frequently, and partly because
> things can go horribly wrong when the gina screws up.
> 
> Again, I'm just wondering if anyone else is working on or has
> implemented some manner of Windows auto-auth (preferably one that
> doesn't get the tickets from an AD server and ms2mit them).
> 
>