Re: Accessing security information from an authentication provider

Chris Smith wrote:
The LSA is running as the system user on the local machine, yes. But it
has no identity in the domain. Windows domains do not assume the
physical security of all domain members, so having system access on a
workstation would not necessarily imply having any kind of privileges on
the domain.

Unfortunately I can't find the doc which states that the local system
account on domain member machines has access to all sorts of AD
information. But maybe you're right and some information is more
restricted. Too bad, I only remember having read *something*, but
not exactly in which context I read it :(

See;en-us;246261 for
information on restricting the NULL account. There is apparently a
setting for preventing it from enumerating SAM accounts and names, and
one to prevent it from having any access at all. I'm curious if changing
this on your domain controller helps at all.

Assuming you're right, shouldn't it also suffice to impersonate the
privileged domain account running the logon application? Changing
the NULL account access doesn't sound like the right thing to do...

Isn't that the task of the AP? I mean, the user has authenticated by
some other means. The AP is supposedly a trusted part of the OS. Why
should a user who authenticated against that AP *not* be able to access
network resources?

Because network resources are not part of the OS. Maybe we're
miscommunicating here, but it's obvious to me that if you want to access
a network resource, you'll need to convince *that* server, not the
workstation you are working on, that you have permission to do it. The
LSA only matters on the local system, so inherently it can do nothing to
convince some other system of your identity. Otherwise, I could write an
authentication provider for my laptop that lets me be anybody I like, and
plug it into someone else's network, and access a bunch of private files
on their Windows domain. If the LSA is going to give you access to your
network shares, it would have to do something to convince those other
servers that you've got the necessary permissions. Given that
authentication uses Kerberos in Windows domains, that would probably mean
obtaining a TGT (ticket granting ticket) that the system can use later to
obtain tickets for those other servers' resources.

I have some trouble with the concept. If I have to convince the sharing
server, I need credentials to present them to that server. If I'm not
using passwords or smart cards but some other means of authentication,
how can I convince that server that my domain user has authenticated?
For the Kerberos ticket I still need to authenticate using an
authentication mechanism Kerberos supports, and so I'm right back at
start, right? How can I ever implement my own authentication mechanism
this way, which then works transparently when, say, accessing a SMB


Corinna Vinschen
Cygwin Project Co-Leader
Red Hat