Win2000 PAC-Credentials Implementation
Luke Howard
lukeh at PADL.COM
Tue Sep 9 11:28:33 EDT 2003
Greg,
>At this point in time I get to plead my utter ignorance with respect
>to most things in the area of Windows architecture. I've never owned
>a computer which boots the operating system so my analysis needs to be
>taken with a grain of salt. There have been a couple of other notes
>recently on this issue so I will offer the following comments to at
>least provide background (from my perspective) on the issue.
I suggest you read:
http://www.usenix.org/publications/login/1998-5/brundrett.html
Peter's article covers the issues more succintly than most.
>The important issue to clarify is what it exactly means to 'logon' to
>a Windows machine or network. If 'logon' means to authenticate
>someone who is sitting at the keyboard of a Windows client so they can
>use the machine locally the PGINA project provides tools that would
>enable Hurderos to manage 'logins'.
These replacement GINA modules typically create a local SAM account
for the user logging in. While this is fine for local access, they
fall down badly when a user needs to access network resources that
respect the NT impersonation model; each user will have a different
identity (SID) on each machine, presuming they have even logged on
interactively.
Finally, none of this addresses things like assigning ACLs to files,
which outside the scope of the LSA authentication provider interface,
and yet are important parts of the user experience as far as Windows
security is concerned.
>The security context created by the LSA contains a TGT which has been
>extended to carry PAC's in the optional payload section of the ticket.
To be pedantic, it is the authorization data in the service ticket
for the local machine that is used to authorize interactive logon.
Authorization data in the TGT is an optimization.
>Going beyond that means that an LSA DLL is needed to create a security
>context around an identity based on the Hurderos identity and
>authorization model. Perhaps even more formidable is making or
>mapping that context into something relevant to a proprietary
>operating system and applications. I'm doing a lot of thinking about
>that right now.... :-)
I note that client-side modifications, such as replacement DLLs, often
meet deployment resistance.
-- Luke
More information about the Kerberos
mailing list