|
|
|
date: 08 Jul 2008 15:46:44 GMT,
group: microsoft.public.platformsdk.security
back
Re: Accessing security information from an authentication provider
Ok, well I hope that helps. Maybe you guys can help each other now. :)
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"ferrix" wrote in message
news:5685019C-8B47-4530-9E51-488D586021F7@microsoft.com...
> That looks promising. My problem was that the "Security Functions" page
> has
> two sections for auth packages,
> "Functions Implemented by Authentication Packages", which is what I was
> looking at, and gives no hint how the AP might do these things, and
> "Functions Implemented by SSP/APs " with its sub-section "The following
> functions are available to SSP/APs."
>
> My main ignorance was I didn't realize I had to build an "SSP/AP", just
> thought an AP was it. But without the SSP, there's no way to get a handle
> to
> all those juicy SAM functions.
>
> "Joe Kaplan" wrote:
>
>> I just took a quick look and it appears to me that you are supposed to do
>> something like a chain of OpenSamUser -> GetUserAuthData ->
>> ConvertAuthDataToToken. I could be wrong though as I haven't done this
>> myself. It just looked logical to me based on the API docs.
>>
>> Do you have enough info on the user to call OpenSamUser?
>>
>> Joe K.
>> --
>> Joe Kaplan-MS MVP Directory Services Programming
>> Co-author of "The .NET Developer's Guide to Directory Services
>> Programming"
>> http://www.directoryprogramming.net
>> --
>> "Chris Smith" wrote in message
>> news:03b57c04$0$3203$c3e8da3@news.astraweb.com...
>> > No answer? Is it not possible to implement a new authentication
>> > provider
>> > without reimplementing the database that holds a user's groups,
>> > privileges, etc.?
>> >
>> > --
>> > Chris Smith
>>
>>
>>
date: Wed, 9 Jul 2008 14:54:31 -0500
author: Joe Kaplan
Re: Accessing security information from an authentication provider
Hi,
ferrix wrote:
> That looks promising. My problem was that the "Security Functions"
> page has two sections for auth packages, "Functions Implemented by
> Authentication Packages", which is what I was looking at, and gives no
> hint how the AP might do these things, and "Functions Implemented by
> SSP/APs " with its sub-section "The following functions are available
> to SSP/APs."
>
> My main ignorance was I didn't realize I had to build an "SSP/AP",
> just thought an AP was it. But without the SSP, there's no way to get
> a handle to all those juicy SAM functions.
An AP has this information available. The pointer to the function table
you get in the call to LsaApInitializePackage is actually a pointer to
the full LSA_SECPKG_FUNCTION_TABLE, not just a pointer to the
LSA_DISPATCH_TABLE as MSDN suggests. If you have a closer look, you'll
see that the DISPATCH table is just the first snippet from the
SECPKG_FUNCTION table. In my AP I'm using for instance the
GetClientInfo function to make sure the calling process has the TCB
privilege.
But, here's the problem I have with ConvertAuthDataToToken. It sounds a
nice idea to call it, and when it returns, you have a token. But...
what next?
The call to LsaApLogonUser has no way to return the token to the
caller. Instead, there's the TokenInformation pointer which has to
be filled with a LSA_TOKEN_INFORMATION_V2 structure which in turn
is used to create a token by MSV1_0. And *that* token is returned
to the calling logon process. What's suppsoed to happen with the token
returned by ConvertAuthDataToToken?
Still puzzled(*),
Corinna
(*) and disappointed by the incomplete documentation.
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
date: Thu, 10 Jul 2008 08:49:59 +0000 (UTC)
author: Corinna Vinschen am
Re: Accessing security information from an authentication provider
On Jul 10, 12:26 am, Yannick wrote:
> Does this mean that the only difference between AP and SSP/AP is the
> access to those "juicy" functions?
>
> I'm still not sure what to choose to be honest.
>
>
>
> ferrix wrote:
> > That looks promising. My problem was that the "Security Functions" page has
> > two sections for auth packages,
> > "Functions Implemented by Authentication Packages", which is what I was
> > looking at, and gives no hint how the AP might do these things, and
> > "Functions Implemented by SSP/APs " with its sub-section "The following
> > functions are available to SSP/APs."
>
> > My main ignorance was I didn't realize I had to build an "SSP/AP", just
> > thought an AP was it. But without the SSP, there's no way to get a handle to
> > all those juicy SAM functions.
>
> > "Joe Kaplan" wrote:
>
> >> I just took a quick look and it appears to me that you are supposed to do
> >> something like a chain of OpenSamUser -> GetUserAuthData ->
> >> ConvertAuthDataToToken. I could be wrong though as I haven't done this
> >> myself. It just looked logical to me based on the API docs.
>
> >> Do you have enough info on the user to call OpenSamUser?
>
> >> Joe K.
> >> --
> >> Joe Kaplan-MS MVP Directory Services Programming
> >> Co-author of "The .NET Developer's Guide to Directory Services Programming"
> >>http://www.directoryprogramming.net
> >> --
> >> "Chris Smith" wrote in message
> >>news:03b57c04$0$3203$c3e8da3@news.astraweb.com...
> >>> No answer? Is it not possible to implement a new authentication provider
> >>> without reimplementing the database that holds a user's groups,
> >>> privileges, etc.?
>
> >>> --
> >>> Chris Smith- Hide quoted text -
>
> - Show quoted text -
The choice between whether to implement an AP or an SSP is purely
based on which functions/functionality you want to offer up to the
*caller* of the package.
All of the Windows packages, for example, are both APs and SSPs
because they offer both sets of APIs, the AP functions like
CallAuthenticationPackage and LsaLogonUser as well as the SSPI (GSS)
functions such as InitializeSecurityContext/EncryptMessage.
As Corinna points out, the helper functions offered by the LSA should
be available to either an AP or an SSP.
The MSDN folks just love to reorganize the API help docs for no
apparent reason (and never for the good!) and I agree that it's
totally unclear at this point what a developer is supposed to do if
they want to implement a particular kind of package. Only a sample
really helps to show how something this complicated is organized and
they have pulled most of the interesting samples off of the Platform
SDK. Bummer.
Dave
date: Thu, 10 Jul 2008 06:44:13 -0700 (PDT)
author: DaveMo
Re: Accessing security information from an authentication provider
Hi Dave,
DaveMo wrote:
> On Jul 9, 8:03?am, Chris Smith wrote:
>> No answer? ?Is it not possible to implement a new authentication provider
>> without reimplementing the database that holds a user's groups,
>> privileges, etc.?
>>
>> --
>> Chris Smith
>
> Hi Chris,
>
> Most likely the best way to do implement this part of your AP is to
> invoke Kerberos S4U once you have authenticated the user. From the
> token returned by S4U you can copy all the information about the
> authenticated user and generate a matching token. This will have many
> benefits over rolling your own set of AuthZ data because similiarity
> in what is returned by auth packages is a very good thing.
I don't think that's an option. I played with the KERB_S4U_LOGON stuff
just a couple of days ago, and it turns out that KERB_S4U:
- Is only implemented on server machines (2003, 2008) as the name suggests,
so there's no hope to use a logon process based on using S4U on XP or
Vista or even Windows 2000.
- The token returned by S4U is also missing the credentials necessary to
make the network calls. For instance, using this token does not allow
to access network drives w/o having to provide a password. Neither
work AD LDAP requests to fetch username <-> SID mappings w/o providing
an additional username/password authentication.
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
date: Thu, 10 Jul 2008 14:51:02 +0000 (UTC)
author: Corinna Vinschen am
Re: Accessing security information from an authentication provider
Corinna Vinschen wrote:
> But, here's the problem I have with ConvertAuthDataToToken. It sounds a
> nice idea to call it, and when it returns, you have a token. But...
> what next?
>
> The call to LsaApLogonUser has no way to return the token to the
> caller. Instead, there's the TokenInformation pointer which has to
> be filled with a LSA_TOKEN_INFORMATION_V2 structure which in turn
> is used to create a token by MSV1_0. And *that* token is returned
> to the calling logon process. What's suppsoed to happen with the token
> returned by ConvertAuthDataToToken?
In the meantime it occured to me how to transmit the token to the
calling logon process and I hacked happily away. Alas, the result is
just disappointing.
For some reason GetAuthDataForUser() only works for local machine
accounts. I have to give the plain username to the function. If I try
to get the auth data for a domain account by using the domain\username
syntax and SecNameSamCompatible as type, or using the
username@domain.tld syntax and SecNameFlat as type, I'm invariably
getting a return code of STATUS_NO_SUCH_USER from GetAuthDataForUser().
Even when running on a DC, it only works half. The token returned by
ConvertAuthDataToToken() does not contain the groups not defined in the
local SAM, and the credentials required to access network resources are
*still* missing.
If you only need a machine local account and no network credentials,
it's an easy solution, provided you have a way to transmit the results
to the calling logon application. Personally I called DuplicateHandle()
on the token and transmitted the new handle value in the profile buffer.
If you need to authenticate against AD or if you need network
credentials, you're still stuck like me.
Hello? Microsoft? Help? Please?
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
date: Thu, 10 Jul 2008 17:34:44 +0000 (UTC)
author: Corinna Vinschen am
Re: Accessing security information from an authentication provider
On Jul 10, 10:34 am, Corinna Vinschen <cori...@community.nospam>
wrote:
> Corinna Vinschen wrote:
> > But, here's the problem I have with ConvertAuthDataToToken. It sounds a
> > nice idea to call it, and when it returns, you have a token. But...
> > what next?
>
> > The call to LsaApLogonUser has no way to return the token to the
> > caller. Instead, there's the TokenInformation pointer which has to
> > be filled with a LSA_TOKEN_INFORMATION_V2 structure which in turn
> > is used to create a token by MSV1_0. And *that* token is returned
> > to the calling logon process. What's suppsoed to happen with the token
> > returned by ConvertAuthDataToToken?
>
> In the meantime it occured to me how to transmit the token to the
> calling logon process and I hacked happily away. Alas, the result is
> just disappointing.
>
> For some reason GetAuthDataForUser() only works for local machine
> accounts. I have to give the plain username to the function. If I try
> to get the auth data for a domain account by using the domain\username
> syntax and SecNameSamCompatible as type, or using the
> usern...@domain.tld syntax and SecNameFlat as type, I'm invariably
> getting a return code of STATUS_NO_SUCH_USER from GetAuthDataForUser().
>
> Even when running on a DC, it only works half. The token returned by
> ConvertAuthDataToToken() does not contain the groups not defined in the
> local SAM, and the credentials required to access network resources are
> *still* missing.
>
> If you only need a machine local account and no network credentials,
> it's an easy solution, provided you have a way to transmit the results
> to the calling logon application. Personally I called DuplicateHandle(> on the token and transmitted the new handle value in the profile buffer.
>
> If you need to authenticate against AD or if you need network
> credentials, you're still stuck like me.
>
> Hello? Microsoft? Help? Please?
>
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Project Co-Leader
> Red Hat
There are a couple of points to cover both here and in the other post.
First you talk about credentials. There is an assumption that
credentials are being provided by the caller of the authentication
package. Furthermore it is assumed that either the credentials are the
user's AD username/pwd or that they are credentials which the package
is going to validate and then go get a valid copy of the username/pwd
from some other store.
The first case would be the scenario where you are developing an
authentication package that would implement some kind of password-
based authentication protocol different from NTLM, Kerberos or Digest
(since these are already implemented).
The second scenario is a bit more iffy, since most who are going down
this route don't bother to write an AP. For instance the OTP vendors
usually validate the OTP credential in their GINA and then go out of
band to get username/pwd and then simply feed that back into the
existing packages using LsaLogonUser.
The only real reason to write an AP or an SSP is to provide a level of
extensibility such that normal system processes that call APIs like
LsaLogonUser InitializeSecurityContext would use *your* authentication
protocol seemlessly. In reality, though, it isn't that easy and SSPI
isn't as protocol agnostic as we might like it to be. There is a
reason why negotiate still only supports Kerberos and NTLM on Windows.
When I mentioned S4U, I'm really talking about what you would do if
you were implementing your own AP and maybe you only had to worry
about creating tokens that were good locally. There are valid cases
for that scenario. Instead of having to figure out how to create the
token SIDs, S4U would be a good option. You could copy the SIDs from
the S4U token and be done with it. Yes, there are no valid network
credentials that come with S4U logons as that would be a pretty
dangerous thing.
If you can describe your scenario and requirements in more detail we
might be able to figure out a better approach.
Dave
date: Thu, 10 Jul 2008 13:58:19 -0700 (PDT)
author: DaveMo
Re: Accessing security information from an authentication provider
DaveMo wrote:
> For instance the OTP vendors
> usually validate the OTP credential in their GINA and then go out of
> band to get username/pwd and then simply feed that back into the
> existing packages using LsaLogonUser.
How can they "get" the password if the user only enters the otp value
and maybe a pin? There's no password to feed into kerberos or NTLM.. Or
are you saying they *store* the AD passwords somewhere out of band and
then feed them in? That seems fraught with insecurity..
Further, there'd be no way to continue using username/password logins on
other systems since the pass is known (and I assume controlled) by the
OTP scheme.
> If you can describe your scenario and requirements in more detail we
> might be able to figure out a better approach.
Well *my* scenario is similar to an OTP case.. I want to do my own
authentication check and at the end of the day somehow end up with a
real, fully useable logon session with an AD kerberos TGT in the cache
and everything.
I am thinking a clever way to do it could be:
* Issue and store my user certificates and priv keys somewhere safe; one
cert mapped to each AD user that will use my auth scheme.
* When my AP decides a login is good, it can pull the certificate up and
do a KERB_CERTIFICATE_LOGON with it.
* Obviously there's a security hole vis-a-vis stealing that
non-smart-carded private key and using it out-of-band with my auth
process. I'm not concerned about this, I already know how to address
it. So ppl can skip any type of "Your idea would not be secure, ergo
you should not care about whether it is possible" replies :)
I'm not sure whether it's even possible to do KERB_CERTIFICATE_LOGON
using a bare certificate/key pair, or if the kerberos provider will
always try to call into the "Smart Card Module Functions"
http://msdn.microsoft.com/en-us/library/aa380252(VS.85).aspx#smart_card_module_functions
even if I pass in the basic Microsoft CSP (that's used for SChannel
etc.) I don't want to have to build a fake smart card CSP if I can help
it... Anyone know if cert login without a smart card infrastructure is
possible even nominally? Does the kerberos AP just call crypto API
functions or does it burrow into the smart card stuff directly?
So to summarize in different terms, my goal is to "add" a way for AD's
kerberos to give me a logon session and TGT, and leave other forms of
auth alone (passwords, smart cards). This problem reduces to "how do I
get kerberos to work without a smart card or password" (but possibly
with a certificate)
I see *lots* of people here and on the web at large with equivalent
problems. I think Corinna's use case calls for something similar. She
needs a way to get a fully working logon session pushed to the
workstation without the user ever entering the password during the
authentication. (Note that in her scenario, the normal password-based
logon must continue to be supported too).
DaveMo et al, your insights are much appreciated!
date: Thu, 10 Jul 2008 17:54:14 -0500
author: ferrix
Re: Accessing security information from an authentication provider
On Jul 10, 3:54 pm, ferrix wrote:
> DaveMo wrote:
> > For instance the OTP vendors
> > usually validate the OTP credential in their GINA and then go out of
> > band to get username/pwd and then simply feed that back into the
> > existing packages using LsaLogonUser.
>
> How can they "get" the password if the user only enters the otp value
> and maybe a pin? There's no password to feed into kerberos or NTLM.. Or
> are you saying they *store* the AD passwords somewhere out of band and
> then feed them in? That seems fraught with insecurity..
>
> Further, there'd be no way to continue using username/password logins on
> other systems since the pass is known (and I assume controlled) by the
> OTP scheme.
>
> > If you can describe your scenario and requirements in more detail we
> > might be able to figure out a better approach.
>
> Well *my* scenario is similar to an OTP case.. I want to do my own
> authentication check and at the end of the day somehow end up with a
> real, fully useable logon session with an AD kerberos TGT in the cache
> and everything.
>
> I am thinking a clever way to do it could be:
> * Issue and store my user certificates and priv keys somewhere safe; one
> cert mapped to each AD user that will use my auth scheme.
> * When my AP decides a login is good, it can pull the certificate up and
> do a KERB_CERTIFICATE_LOGON with it.
> * Obviously there's a security hole vis-a-vis stealing that
> non-smart-carded private key and using it out-of-band with my auth
> process. I'm not concerned about this, I already know how to address
> it. So ppl can skip any type of "Your idea would not be secure, ergo
> you should not care about whether it is possible" replies :)
>
> I'm not sure whether it's even possible to do KERB_CERTIFICATE_LOGON
> using a bare certificate/key pair, or if the kerberos provider will
> always try to call into the "Smart Card Module Functions"http://msdn.microsoft.com/en-us/library/aa380252(VS.85).aspx#smart_ca...
> even if I pass in the basic Microsoft CSP (that's used for SChannel
> etc.) I don't want to have to build a fake smart card CSP if I can help
> it... Anyone know if cert login without a smart card infrastructure is
> possible even nominally? Does the kerberos AP just call crypto API
> functions or does it burrow into the smart card stuff directly?
>
> So to summarize in different terms, my goal is to "add" a way for AD's
> kerberos to give me a logon session and TGT, and leave other forms of
> auth alone (passwords, smart cards). This problem reduces to "how do I
> get kerberos to work without a smart card or password" (but possibly
> with a certificate)
>
> I see *lots* of people here and on the web at large with equivalent
> problems. I think Corinna's use case calls for something similar. She
> needs a way to get a fully working logon session pushed to the
> workstation without the user ever entering the password during the
> authentication. (Note that in her scenario, the normal password-based
> logon must continue to be supported too).
>
> DaveMo et al, your insights are much appreciated!
I'm not sure that it would be worth trying to figure out the smartcard
approach although it has it's own coolness factor to it. I do know
that of all the authN mechanisms in Windows, SC auth has been the most
difficult to deal with and there are lots of odd things about the
whole mechanism. If you are an ISV, you might want to think about
what's going to happen if your product tries to deploy into an
existing environment where SC authentication is already used and where
they might have tweaked the default settings or even the client
footprint.
Yes, you are right in your understanding that others who have done
this store and retrieve the AD password out of band and retrieve it
through their own (hopefully secure!) mechanism. It's fairly easy to
get cleartext AD passwords by installing a password filter on the DC.
Also, we should note that there is a S4U type that allows a service to
get an S4U ticket which can be delegated. But of course this wouldn't
be available on client so it probably doesn't help everyone that's
trying to do something on client.
To my mind, the real fix here is if we could have a more flexible
Kerberos where we could define and plug-in different keying
mechanisms. Kerberos can handle almost an infinite variety of keying
mechanisms and if there was pluggability on the client and KDC to
validate different key sets everyone would probably have a pretty good
solution. If you ever get the chance to express your opinion to a
Microsoftie from the core security team try to give them this
message :)
date: Thu, 10 Jul 2008 16:58:52 -0700 (PDT)
author: DaveMo
Re: Accessing security information from an authentication provider
I just want to say thanks SO much for everyone's help on this. I have
been away and haven't been able to answer as reliably as I'd like.
It looks like the combination of OpenSamUser, GetAuthDataForUser, and
ConvertAuthDataToToken is exactly what I was looking for, at least for
the first bits here. I'm somewhat concerned by Corinna's comment that it
doesn't seem to work for domain accounts, though. The documentation of
these functions seems to suggest that it should. Is this perhaps due to
someone disabling or restricting the null account, as is sometimes
suggested in various tutorials on how to secure Windows domains? Any
other resolution on this?
I am NOT concerned that ConvertAuthDataToToken doesn't set up network
credentials immediately. In fact, it's clear to me that it can't.
Nothing I can do on a client machine should be able to give me access to
network shares and such without somehow authenticating to a domain
controller. I realize that.
But what I'm hoping to do here, eventually (meaning in the next two weeks
or so, by our current project schedule), is to replace the Kerberos AS
piece of the authentication process. I plan to actually write my own AS,
which will need to share a secret key with the existing Kerberos
components that act as the TGS and such. So I'll need to generate a TGT
using this shared secret key, and then get Windows to use that for access
to other network resources via the existing TGS. I hope that's
possible? Perhaps I can get back this TGT, and use AddCredential to add
it so that the user can access their network resources?
Storing passwords out of band is NOT an option for my application. We'd
rather just give up on the project than do that. We don't want passwords
at all (except for the pass-phrases built into our biometric tokens, but
we handle those in our own code). So I hope doing this right remains
possible.
--
Chris Smith
date: 13 Jul 2008 16:32:51 GMT
author: Chris Smith
Re: Accessing security information from an authentication provider
Chris Smith wrote:
> I just want to say thanks SO much for everyone's help on this. I have
> been away and haven't been able to answer as reliably as I'd like.
>
> It looks like the combination of OpenSamUser, GetAuthDataForUser, and
> ConvertAuthDataToToken is exactly what I was looking for, at least for
> the first bits here. I'm somewhat concerned by Corinna's comment that it
> doesn't seem to work for domain accounts, though. The documentation of
> these functions seems to suggest that it should. Is this perhaps due to
> someone disabling or restricting the null account, as is sometimes
> suggested in various tutorials on how to secure Windows domains?
What null account? The LSA itself is running in SYSTEM context, AFAIK,
and the logon application is running under a privileged domain account.
Nevertheless, the GetAuthDataForUser only works for machine local
accounts and never asks AD, apparently.
> I am NOT concerned that ConvertAuthDataToToken doesn't set up network
> credentials immediately. In fact, it's clear to me that it can't.
> Nothing I can do on a client machine should be able to give me access to
> network shares and such without somehow authenticating to a domain
> controller. I realize that.
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?
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
date: Mon, 14 Jul 2008 12:03:31 +0000 (UTC)
author: Corinna Vinschen am
Re: Accessing security information from an authentication provider
Corinna Vinschen wrote:
> What null account? The LSA itself is running in SYSTEM context, AFAIK,
> and the logon application is running under a privileged domain account.
> Nevertheless, the GetAuthDataForUser only works for machine local
> accounts and never asks AD, apparently.
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.
See http://support.microsoft.com/default.aspx?scid=kb;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.
>> I am NOT concerned that ConvertAuthDataToToken doesn't set up network
>> credentials immediately. In fact, it's clear to me that it can't.
>> Nothing I can do on a client machine should be able to give me access
>> to network shares and such without somehow authenticating to a domain
>> controller. I realize that.
>
> 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.
That's my understanding of the situation, but don't take it as gospel by
any means. I'm pretty new to this.
--
Chris Smith
date: 14 Jul 2008 13:18:54 GMT
author: Chris Smith
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 http://support.microsoft.com/default.aspx?scid=kb;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
share?
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
date: Mon, 14 Jul 2008 15:46:49 +0000 (UTC)
author: Corinna Vinschen am
Re: Accessing security information from an authentication provider
I hope someone who knows better will speak up. Again, don't trust what I
say, as I'm just trying to figure this out now, too.
But, with that disclaimer, comments below...
Corinna Vinschen wrote:
> 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.
Does the local system account for the workstation actually exist in
Active Directory server at all? I was under the impression that it does
not, and that the communication with ADS always happens anonymously.
>> See http://support.microsoft.com/default.aspx?scid=kb;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...
Yes, you're right that setting this to something less secure is not the
ideal solution. If that's the case, then one would need to obtain (or
have) some authentication information for a more privileged account, and
use that to look up the user in ADS. But if changing that registry value
makes your tests work, that would tell us something interesting, at
least. I don't have ADS set up yet, as I'm still working on biometric
matching for the local case at the moment. If you do happen to give it a
try, I'd love to hear your results.
> 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?
So that's the fundamental question, I suppose. In principle (but I'm
unsure whether there are documented Windows API calls to do this), anyone
who knows the shared secret key of the TGS (ticket granting server)
should be able to generate a TGT (ticket granting ticket), and then
Windows should be able to present that to the TGS later to gain access to
other servers (network shares, etc.)
So to make this work, you need the shared secret key for the TGS. That
should certainly NOT be stored on any system that isn't physically
secured. But if all your workstations are physically secured, then you
could in theory generate this ticket on the workstation. If you can't do
it on the workstation, then you'd need a server that IS physically secure
that could generate these tickets for you. In either case, maintaining
the appropriate mapping between user principals (that is, SIDs) and (in
your case) public keys is the crucial matter as far as security.
The sort of pie-in-the-sky idea that you can make this work on an
untrusted (i.e., not physically secure) workstation and automatically
access network shares without arranging something in a more secured place
will be impossible. That's a good thing; if I compromise a workstation
(not hard, if it's not physically secure), then I could change the LSA to
always succeed without any authentication data at all! You wouldn't want
me to be able to access network services for whatever user account I
choose to pretend to be.
--
Chris Smith
date: 14 Jul 2008 17:58:08 GMT
author: Chris Smith
Re: Accessing security information from an authentication provider
Chris Smith wrote:
> I hope someone who knows better will speak up. Again, don't trust what I
> say, as I'm just trying to figure this out now, too.
>
> But, with that disclaimer, comments below...
>
> Corinna Vinschen wrote:
>> 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.
>
> Does the local system account for the workstation actually exist in
> Active Directory server at all? I was under the impression that it does
> not, and that the communication with ADS always happens anonymously.
The system account is not listed in the AD account database. As far as
I understood this (which isn't much, probably), the fact that the
machine is a domain member machine makes it sort of trustable. Or
something.
>> 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...
>
> Yes, you're right that setting this to something less secure is not the
> ideal solution. If that's the case, then one would need to obtain (or
> have) some authentication information for a more privileged account, and
> use that to look up the user in ADS. But if changing that registry value
> makes your tests work, that would tell us something interesting, at
> least.
I tried with impersonating the user and it didn't help. The error I get
from GetAuthDataForUser is still STATUS_NO_SUCH_USER. If it would be a
permission problem, wouldn't that rather be STATUS_ACCESS_DENIED?
>> 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?
>
> So that's the fundamental question, I suppose. In principle (but I'm
> unsure whether there are documented Windows API calls to do this), anyone
> who knows the shared secret key of the TGS (ticket granting server)
> should be able to generate a TGT (ticket granting ticket), and then
> Windows should be able to present that to the TGS later to gain access to
> other servers (network shares, etc.)
> [...]
I'm trying to find a generic solution for a simple AP. I don't have
access to the servers, nor is this supposed to work only in AD
environments. Oh well.
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
date: Tue, 15 Jul 2008 11:08:15 +0000 (UTC)
author: Corinna Vinschen am
Re: Accessing security information from an authentication provider
Hi,
I'm also trying to implement my own authentication package and I'd like
to authenticate users without using their passwords. The only thing that
matters for me is to be able to open a graphical sessions with this
token. I don't need network access.
Considering this, I've got the following questions regarding the
previous messages:
- Is it possible to open a graphical sessions with the token you get
from Kerberos S4U?
- Has anybody considered the code from the CVSNT project
(http://www.cvsnt.org/wiki/Download)? They also implement their own
authentication package and as far as I understand the code, they get
some informations (groups right ect...) from the AD. I think the only
thing you need for this code to run is the SeTcbPrivilege. Is it
possible to run the code of an Authentication Package with the
privilege? I'm not sure how to give it.
Any help or comments would be much appreciated.
Cheers,
Yannick
Corinna Vinschen wrote:
> Hi Dave,
>
> DaveMo wrote:
>> On Jul 9, 8:03?am, Chris Smith wrote:
>>> No answer? ?Is it not possible to implement a new authentication provider
>>> without reimplementing the database that holds a user's groups,
>>> privileges, etc.?
>>>
>>> --
>>> Chris Smith
>> Hi Chris,
>>
>> Most likely the best way to do implement this part of your AP is to
>> invoke Kerberos S4U once you have authenticated the user. From the
>> token returned by S4U you can copy all the information about the
>> authenticated user and generate a matching token. This will have many
>> benefits over rolling your own set of AuthZ data because similiarity
>> in what is returned by auth packages is a very good thing.
>
> I don't think that's an option. I played with the KERB_S4U_LOGON stuff
> just a couple of days ago, and it turns out that KERB_S4U:
>
> - Is only implemented on server machines (2003, 2008) as the name suggests,
> so there's no hope to use a logon process based on using S4U on XP or
> Vista or even Windows 2000.
>
> - The token returned by S4U is also missing the credentials necessary to
> make the network calls. For instance, using this token does not allow
> to access network drives w/o having to provide a password. Neither
> work AD LDAP requests to fetch username <-> SID mappings w/o providing
> an additional username/password authentication.
>
>
> Corinna
>
date: Sun, 20 Jul 2008 23:57:39 +0100
author: Yannick
Re: Accessing security information from an authentication provider
Yannick wrote:
> Hi,
>
> I'm also trying to implement my own authentication package and I'd like
> to authenticate users without using their passwords. The only thing that
> matters for me is to be able to open a graphical sessions with this
> token. I don't need network access.
Are you sure? If you open a GUI session, doesn't the user expect to
be able to access the usual SMB shares, for instance?
> Considering this, I've got the following questions regarding the
> previous messages:
>
> - Is it possible to open a graphical sessions with the token you get
> from Kerberos S4U?
The returned token should have the INTERACTIVE group in the group
list. I don't know if S4U returns a token with NETWORK or INTERACTIVE
group and I have deleted my testcase in the meantime, sorry. You
should just try it, the code to use S4U from a logon application is
really simple.
Disadvantage: S4U only works on server machines, not on clients.
> - Has anybody considered the code from the CVSNT project
> (http://www.cvsnt.org/wiki/Download)? They also implement their own
> authentication package and as far as I understand the code, they get
> some informations (groups right ect...) from the AD. I think the only
> thing you need for this code to run is the SeTcbPrivilege. Is it
> possible to run the code of an Authentication Package with the
> privilege? I'm not sure how to give it.
You don't really need the TCB privilege. All the calls to fetch user
and group information to build a token (except for the credentials) is
just available.
However, CVSNT is under GPL so you should make sure you're not tainting
your own licensing by using that code as foundation.
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
date: Mon, 21 Jul 2008 13:29:14 +0000 (UTC)
author: Corinna Vinschen am
Re: Accessing security information from an authentication provider
Hi,
Thanks Corrina for your answer.
Corinna Vinschen wrote:
> Yannick wrote:
>> Hi,
>>
>> I'm also trying to implement my own authentication package and I'd like
>> to authenticate users without using their passwords. The only thing that
>> matters for me is to be able to open a graphical sessions with this
>> token. I don't need network access.
>
> Are you sure? If you open a GUI session, doesn't the user expect to
> be able to access the usual SMB shares, for instance?
Yes! This is not ideal but it will do.
>
>> Considering this, I've got the following questions regarding the
>> previous messages:
>>
>> - Is it possible to open a graphical sessions with the token you get
>> from Kerberos S4U?
>
> The returned token should have the INTERACTIVE group in the group
> list. I don't know if S4U returns a token with NETWORK or INTERACTIVE
> group and I have deleted my testcase in the meantime, sorry. You
> should just try it, the code to use S4U from a logon application is
> really simple.
>
> Disadvantage: S4U only works on server machines, not on clients.
So I've quickly tried to implement this in my AP. I'm using the code
from the MSDN example here:
http://msdn.microsoft.com/en-us/magazine/cc188757.aspx
I can get a token on a client machine, it works fine. Then I've
basically tried to re-create a token from the token handle I got from
LsaLogonUser. This using the GetTokenInformation function. This is where
my problem starts. As far as I know (tell me if I'm wrong) the token has
to be in a contiguous memory block. And since LSA_TOKEN_INFORMATION_V2
contains some pointer like PTOKEN_GROUPS I've allocated a larger memory
block with LsaAllocateHeap and made PTOKEN_GROUPS pointing after the
structure but still in the memory block I've allocated. The same for
PTOKEN_PRIVILEGES.
However I've just realized that for example TOKEN_USER contains pointers
as well. Should I also do the same with these pointers? I always get
some access violation error from lsasrv.exe, so I guess this problem
comes from some bad pointer.
I'll be really interested to know how you did this Corrina.
>
>> - Has anybody considered the code from the CVSNT project
>> (http://www.cvsnt.org/wiki/Download)? They also implement their own
>> authentication package and as far as I understand the code, they get
>> some informations (groups right ect...) from the AD. I think the only
>> thing you need for this code to run is the SeTcbPrivilege. Is it
>> possible to run the code of an Authentication Package with the
>> privilege? I'm not sure how to give it.
>
> You don't really need the TCB privilege. All the calls to fetch user
> and group information to build a token (except for the credentials) is
> just available.
>
> However, CVSNT is under GPL so you should make sure you're not tainting
> your own licensing by using that code as foundation.
>
I meant: it seems to be working for them so we should maybe look at the
method they use. I tried to integrate their code in my AP to see what
happens. The token creation seems to work fine (even though I have to
give SeTcbPrivilege to Everyone on my machine to make it work) but then
again I've got some weird error from lsasrv.exe or winlogon.exe.
Any comments?
Yannick
date: Mon, 21 Jul 2008 20:57:26 +0100
author: Yannick
Re: Accessing security information from an authentication provider
On Jul 14, 8:46 am, Corinna Vinschen <cori...@community.nospam> wrote:
> 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 :(
>
> > Seehttp://support.microsoft.com/default.aspx?scid=kb;en-us;246261for
> > 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
> share?
>
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Project Co-Leader
> Red Hat- Hide quoted text -
>
> - Show quoted text -
Corinna,
You asked:
> "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?"
I mentioned several of the parts that theoretically could do this in
an earlier post. At a conceptual level, here is what you would need to
do in order to recreate an entirely new authentication protocol that
uses different types of credentials:
- An SSP implementing the LSA and application side of the package
- A secure credential verification mechanism (the AuthN protocol you
wish to implement)
- The validation mechanism usually has to run off someplace else to
validate credentials, so you need a back-channel mechanism to talk to
either the LSA on domain controllers (recommended) or some other
server that is highly available.
- A way to generate a token that accurately expresses privileges and
token groups for the authenticated user
- You'll need to create the mechanism by which the alternative
credentials get provisioned in Active Directory. There is an interface
provided by the LSA that allows packages to get/set credentials but
you'll need to design the format. Encryption will be handled for you
at least.
- This protocol should be functionaly similiar to NTLM so that
existing callers of SSP (such as the SMB service you mention) could
use your SSP without changing
- Register your SSP on both the client and server so that negotiate
will use it
- Install the SSP on all clients and servers where it needs to be used
If you had all of these pieces in place, then the client application,
SMB for example, would try to authenticate to a remote server. If the
user logged in with a different credential set, then other authN
mechanisms would fail (NTLM, Kerb) and the authN should fall back to
your package. Inside the client side of your package you would start
an authentication sequence which if successful will finish up on the
server side with a accurate authentication token.
Commentary - You would have to have an incredibly good reason to want
to try and tackle all of this. It could literally take years to get
this all working reliably and even then you may run into a roadblock
that simply can't be overcome. This is why I recommended in previous
posts that you just do your own back channel and grab the password out
of some other database. You would then feed this password into the
existing authentication packages. No, it isn't elegant and potentially
lowers the security of Active Directory, but at least it is work that
would actually get finished.
Dave
date: Mon, 21 Jul 2008 15:41:47 -0700 (PDT)
author: DaveMo
Re: Accessing security information from an authentication provider
Yannick wrote:
> Hi,
>
> Thanks Corrina for your answer.
s/Corrina/Corinna/
> Corinna Vinschen wrote:
>> The returned token should have the INTERACTIVE group in the group
>> list. I don't know if S4U returns a token with NETWORK or INTERACTIVE
>> group and I have deleted my testcase in the meantime, sorry. You
>> should just try it, the code to use S4U from a logon application is
>> really simple.
>>
>> Disadvantage: S4U only works on server machines, not on clients.
>
> So I've quickly tried to implement this in my AP. I'm using the code
> from the MSDN example here:
>
> http://msdn.microsoft.com/en-us/magazine/cc188757.aspx
>
> I can get a token on a client machine, it works fine. Then I've
Weird. Running this on Windows XP domain member machine failed for me,
running it on the 2008 domain controller worked.
> basically tried to re-create a token from the token handle I got from
> LsaLogonUser. This using the GetTokenInformation function. This is where
> my problem starts. As far as I know (tell me if I'm wrong) the token has
> to be in a contiguous memory block. And since LSA_TOKEN_INFORMATION_V2
> contains some pointer like PTOKEN_GROUPS I've allocated a larger memory
> block with LsaAllocateHeap and made PTOKEN_GROUPS pointing after the
> structure but still in the memory block I've allocated. The same for
> PTOKEN_PRIVILEGES.
>
> However I've just realized that for example TOKEN_USER contains pointers
> as well. Should I also do the same with these pointers? I always get
> some access violation error from lsasrv.exe, so I guess this problem
> comes from some bad pointer.
Yes, that's definitely necessary.
> I'll be really interested to know how you did this Corrina.
I'm creating a datastructure which is basically a LSA_TOKEN_INFORMATION_V2
plus buffer. To get its size I'm going through all token information and
compute the size necessary for the entire data which all pointers point
to. The rest is dutyfully copy data, set the pointer, copy data, set the
pointer... It's not actually complex, it's just a lot of code.
>> However, CVSNT is under GPL so you should make sure you're not tainting
>> your own licensing by using that code as foundation.
>>
>
> I meant: it seems to be working for them so we should maybe look at the
> method they use. I tried to integrate their code in my AP to see what
> happens. The token creation seems to work fine (even though I have to
> give SeTcbPrivilege to Everyone on my machine to make it work) but then
> again I've got some weird error from lsasrv.exe or winlogon.exe.
Apart from the weird error which I can't say anything about, ouch! You
must not call LsaLogonUser from the application which is run by normal
users. Rather, create a logon application which is supposed to run as
service under a privileged account (SYSTEM for a start) which has the
Tcb privilege. From the user application call the service by some IPC
method. That's how it works in Cygwin. sshd is only capable of
switching the user context when it's running under a privileged account,
so it's typically running as service application.
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
date: Tue, 22 Jul 2008 18:16:47 +0000 (UTC)
author: Corinna Vinschen am
Re: Accessing security information from an authentication provider
DaveMo wrote:
> I mentioned several of the parts that theoretically could do this in
> an earlier post. At a conceptual level, here is what you would need to
> do in order to recreate an entirely new authentication protocol that
> uses different types of credentials:
>
> - An SSP implementing the LSA and application side of the package
> - A secure credential verification mechanism (the AuthN protocol you
> wish to implement)
> - The validation mechanism usually has to run off someplace else to
> validate credentials, so you need a back-channel mechanism to talk to
> either the LSA on domain controllers (recommended) or some other
> server that is highly available.
> - A way to generate a token that accurately expresses privileges and
> token groups for the authenticated user
> - You'll need to create the mechanism by which the alternative
> credentials get provisioned in Active Directory. There is an interface
> provided by the LSA that allows packages to get/set credentials but
> you'll need to design the format. Encryption will be handled for you
> at least.
> - This protocol should be functionaly similiar to NTLM so that
> existing callers of SSP (such as the SMB service you mention) could
> use your SSP without changing
> - Register your SSP on both the client and server so that negotiate
> will use it
> - Install the SSP on all clients and servers where it needs to be used
>
> If you had all of these pieces in place, then the client application,
> SMB for example, would try to authenticate to a remote server. If the
> user logged in with a different credential set, then other authN
> mechanisms would fail (NTLM, Kerb) and the authN should fall back to
> your package. Inside the client side of your package you would start
> an authentication sequence which if successful will finish up on the
> server side with a accurate authentication token.
>
> Commentary - You would have to have an incredibly good reason to want
> to try and tackle all of this. It could literally take years to get
> this all working reliably and even then you may run into a roadblock
> that simply can't be overcome. This is why I recommended in previous
> posts that you just do your own back channel and grab the password out
> of some other database. You would then feed this password into the
> existing authentication packages. No, it isn't elegant and potentially
> lowers the security of Active Directory, but at least it is work that
> would actually get finished.
Yes, I agree. The above sounds complex enough so that I would not be
able to do anything else for a couple of months :|
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
date: Tue, 22 Jul 2008 19:29:36 +0000 (UTC)
author: Corinna Vinschen am
Re: Accessing security information from an authentication provider
Hi,
Thanks for your answer Corinna.
I've tried to play around with the SAM database on Vista and the result
is disappointing.
So I used the OpenSamUser function to get a user handle and I invariably
got a "0xC00000BB" error which means: "STATUS_NOT_SUPPORTED". I tried
with local and domain users. It didn't change anything.
I didn't find anything on the web about this. Any ideas anyone? Am I
doing something wrong? Is Vista implementing properly this function?
Cheers,
Yannick
Corinna Vinschen wrote:
> Yannick wrote:
>> Hi,
>>
>> Thanks Corrina for your answer.
>
> s/Corrina/Corinna/
>
>> Corinna Vinschen wrote:
>>> The returned token should have the INTERACTIVE group in the group
>>> list. I don't know if S4U returns a token with NETWORK or INTERACTIVE
>>> group and I have deleted my testcase in the meantime, sorry. You
>>> should just try it, the code to use S4U from a logon application is
>>> really simple.
>>>
>>> Disadvantage: S4U only works on server machines, not on clients.
>> So I've quickly tried to implement this in my AP. I'm using the code
>> from the MSDN example here:
>>
>> http://msdn.microsoft.com/en-us/magazine/cc188757.aspx
>>
>> I can get a token on a client machine, it works fine. Then I've
>
> Weird. Running this on Windows XP domain member machine failed for me,
> running it on the 2008 domain controller worked.
>
>> basically tried to re-create a token from the token handle I got from
>> LsaLogonUser. This using the GetTokenInformation function. This is where
>> my problem starts. As far as I know (tell me if I'm wrong) the token has
>> to be in a contiguous memory block. And since LSA_TOKEN_INFORMATION_V2
>> contains some pointer like PTOKEN_GROUPS I've allocated a larger memory
>> block with LsaAllocateHeap and made PTOKEN_GROUPS pointing after the
>> structure but still in the memory block I've allocated. The same for
>> PTOKEN_PRIVILEGES.
>>
>> However I've just realized that for example TOKEN_USER contains pointers
>> as well. Should I also do the same with these pointers? I always get
>> some access violation error from lsasrv.exe, so I guess this problem
>> comes from some bad pointer.
>
> Yes, that's definitely necessary.
>
>> I'll be really interested to know how you did this Corrina.
>
> I'm creating a datastructure which is basically a LSA_TOKEN_INFORMATION_V2
> plus buffer. To get its size I'm going through all token information and
> compute the size necessary for the entire data which all pointers point
> to. The rest is dutyfully copy data, set the pointer, copy data, set the
> pointer... It's not actually complex, it's just a lot of code.
>
>>> However, CVSNT is under GPL so you should make sure you're not tainting
>>> your own licensing by using that code as foundation.
>>>
>> I meant: it seems to be working for them so we should maybe look at the
>> method they use. I tried to integrate their code in my AP to see what
>> happens. The token creation seems to work fine (even though I have to
>> give SeTcbPrivilege to Everyone on my machine to make it work) but then
>> again I've got some weird error from lsasrv.exe or winlogon.exe.
>
> Apart from the weird error which I can't say anything about, ouch! You
> must not call LsaLogonUser from the application which is run by normal
> users. Rather, create a logon application which is supposed to run as
> service under a privileged account (SYSTEM for a start) which has the
> Tcb privilege. From the user application call the service by some IPC
> method. That's how it works in Cygwin. sshd is only capable of
> switching the user context when it's running under a privileged account,
> so it's typically running as service application.
>
>
> Corinna
>
date: Wed, 06 Aug 2008 21:34:38 +0100
author: Yannick
|
|
