SecLookupAccountName

All,
Our mini filter driver is calling SecLookupAccountName() from within a
thread. It is being used to resolve a user name to a SID. The computer is
part of a domain so the user name is in the form of (domain
name)(username). The call to SecLookupAccount returns successfully but the
SID is incorrect and the domain name is not updated - just the length.
Below is the code that I’m using to call the function.

Does anyone have any experience with using this function?
Thanks in advance.

// Define space for the returned SID
UCHAR sid[SECURITY_MAX_SID_SIZE];
sidSize = SECURITY_MAX_SID_SIZE;

// Setup the unicode string for the user name
WCHAR szwUserName[260];
wcscpy(&szwUserName[0], L"DHS\MarkFoo");
uniUserName.Buffer = &szwUserName[0];
uniUserName.Length = (USHORT)(2 * wcslen(&szwUserName[0]));
uniUserName.MaximumLength = uniUserName.Length + sizeof(WCHAR);

// set up the unicode string to receive the domain name
domainSize = 2*MAX_STRING;
szwDomainName[0] = 0;
uniDomainName.Buffer = &szwDomainName[0];
uniDomainName.Length = 2 * MAX_STRING - sizeof(WCHAR);
uniDomainName.MaximumLength = 2 * MAX_STRING;

sidStatus = SecLookupAccountName(&uniUserName,
&sidSize,
&sid[0],
&sidNameUse,
&domainSize,
&uniDomainName);
if (sidStatus != STATUS_SUCCESS)
{
}
else
{
}

Not necessarily helpful, but I usually do all this sort of thing in user
mode. Casual googling shows other people having unexpected issues with this
API over the years though I have no experience with it.

Where are you getting the user name from? If it’s coming from a user mode
application, can you just have them send you the SID instead?

-scott
OSR
@OSRDrivers

“JIm james” wrote in message news:xxxxx@ntfsd…
All,
Our mini filter driver is calling SecLookupAccountName() from within a
thread. It is being used to resolve a user name to a SID. The computer is
part of a domain so the user name is in the form of (domain
name)(username). The call to SecLookupAccount returns successfully but the
SID is incorrect and the domain name is not updated - just the length. Below
is the code that I’m using to call the function.

Does anyone have any experience with using this function?
Thanks in advance.

// Define space for the returned SID
UCHAR sid[SECURITY_MAX_SID_SIZE];
sidSize = SECURITY_MAX_SID_SIZE;

// Setup the unicode string for the user name
WCHAR szwUserName[260];
wcscpy(&szwUserName[0], L"DHS\MarkFoo");
uniUserName.Buffer = &szwUserName[0];
uniUserName.Length = (USHORT)(2 * wcslen(&szwUserName[0]));
uniUserName.MaximumLength = uniUserName.Length + sizeof(WCHAR);

// set up the unicode string to receive the domain name
domainSize = 2*MAX_STRING;
szwDomainName[0] = 0;
uniDomainName.Buffer = &szwDomainName[0];
uniDomainName.Length = 2 * MAX_STRING - sizeof(WCHAR);
uniDomainName.MaximumLength = 2 * MAX_STRING;

sidStatus = SecLookupAccountName(&uniUserName,
&sidSize,
&sid[0],
&sidNameUse,
&domainSize,
&uniDomainName);
if (sidStatus != STATUS_SUCCESS)
{
}
else
{
}

Thanks Scott for the suggestion. Yes we may end up being forced to interact
with a user mode component to resolve the SIDs but that would compromise
our solution. The only reason that we would go to user mode is because the
API doesn’t work. It’s hard for me to believe that the API doesn’t work - I
must be doing something wrong…

On Mon, Feb 27, 2017 at 7:47 AM, Scott Noone wrote:

> Not necessarily helpful, but I usually do all this sort of thing in user
> mode. Casual googling shows other people having unexpected issues with this
> API over the years though I have no experience with it.
>
> Where are you getting the user name from? If it’s coming from a user mode
> application, can you just have them send you the SID instead?
>
> -scott
> OSR
> @OSRDrivers
>
> “JIm james” wrote in message news:xxxxx@ntfsd…
>
> All,
> Our mini filter driver is calling SecLookupAccountName() from within a
> thread. It is being used to resolve a user name to a SID. The computer is
> part of a domain so the user name is in the form of (domain
> name)(username). The call to SecLookupAccount returns successfully but the
> SID is incorrect and the domain name is not updated - just the length.
> Below is the code that I’m using to call the function.
>
> Does anyone have any experience with using this function?
> Thanks in advance.
>
> // Define space for the returned SID
> UCHAR sid[SECURITY_MAX_SID_SIZE];
> sidSize = SECURITY_MAX_SID_SIZE;
>
> // Setup the unicode string for the user name
> WCHAR szwUserName[260];
> wcscpy(&szwUserName[0], L"DHS\MarkFoo");
> uniUserName.Buffer = &szwUserName[0];
> uniUserName.Length = (USHORT)(2 * wcslen(&szwUserName[0]));
> uniUserName.MaximumLength = uniUserName.Length + sizeof(WCHAR);
>
> // set up the unicode string to receive the domain name
> domainSize = 2*MAX_STRING;
> szwDomainName[0] = 0;
> uniDomainName.Buffer = &szwDomainName[0];
> uniDomainName.Length = 2 * MAX_STRING - sizeof(WCHAR);
> uniDomainName.MaximumLength = 2 * MAX_STRING;
>
>
> sidStatus = SecLookupAccountName(&uniUserName,
> &sidSize,
> &sid[0],
> &sidNameUse,
> &domainSize,
> &uniDomainName);
> if (sidStatus != STATUS_SUCCESS)
> {
> }
> else
> {
> }
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

In what way do you mean “compromise”? Note that per the documentation this
API talks to user mode to get the answer, so it already includes a user mode
component.

Your string handling is pretty gnarly for KM code. At a minimum
uniDomainName.Length should be set to zero. This is an output parameter, so
the API needs to know it can fill in between Length and MaxLength bytes. You
can clean up your two declarations with something like:

DECLARE_CONST_UNICODE_STRING(domainAndUser, L"FOO\Bar");
DECLARE_UNICODE_STRING_SIZE(domainName, MAX_STRING);

Also note that the DomainSize parameter is strictly Out, so you don’t need
to set it before the call.

Not sure if any of that fixes your problems but it will at least get rid of
some of this code.

-scott
OSR
@OSRDrivers

“JIm james” wrote in message news:xxxxx@ntfsd…
Thanks Scott for the suggestion. Yes we may end up being forced to interact
with a user mode component to resolve the SIDs but that would compromise our
solution. The only reason that we would go to user mode is because the API
doesn’t work. It’s hard for me to believe that the API doesn’t work - I must
be doing something wrong…

On Mon, Feb 27, 2017 at 7:47 AM, Scott Noone wrote:
Not necessarily helpful, but I usually do all this sort of thing in user
mode. Casual googling shows other people having unexpected issues with this
API over the years though I have no experience with it.

Where are you getting the user name from? If it’s coming from a user mode
application, can you just have them send you the SID instead?

-scott
OSR
@OSRDrivers

“JIm james” wrote in message news:xxxxx@ntfsd…

All,
Our mini filter driver is calling SecLookupAccountName() from within a
thread. It is being used to resolve a user name to a SID. The computer is
part of a domain so the user name is in the form of (domain
name)(username). The call to SecLookupAccount returns successfully but the
SID is incorrect and the domain name is not updated - just the length. Below
is the code that I’m using to call the function.

Does anyone have any experience with using this function?
Thanks in advance.

// Define space for the returned SID
UCHAR sid[SECURITY_MAX_SID_SIZE];
sidSize = SECURITY_MAX_SID_SIZE;

// Setup the unicode string for the user name
WCHAR szwUserName[260];
wcscpy(&szwUserName[0], L"DHS\MarkFoo");
uniUserName.Buffer = &szwUserName[0];
uniUserName.Length = (USHORT)(2 * wcslen(&szwUserName[0]));
uniUserName.MaximumLength = uniUserName.Length + sizeof(WCHAR);

// set up the unicode string to receive the domain name
domainSize = 2*MAX_STRING;
szwDomainName[0] = 0;
uniDomainName.Buffer = &szwDomainName[0];
uniDomainName.Length = 2 * MAX_STRING - sizeof(WCHAR);
uniDomainName.MaximumLength = 2 * MAX_STRING;

sidStatus = SecLookupAccountName(&uniUserName,
&sidSize,
&sid[0],
&sidNameUse,
&domainSize,
&uniDomainName);
if (sidStatus != STATUS_SUCCESS)
{
}
else
{
}


NTFSD is sponsored by OSR

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:>

No these superficial changes make no difference. If you read the
documentation on SecLookupAccountName you’ll see that DomainSize is an
*in/out* parameters that must be set to size of Reference Domain Name
buffer before making the call.

On Mon, Feb 27, 2017 at 3:19 PM, Scott Noone wrote:

> In what way do you mean “compromise”? Note that per the documentation this
> API talks to user mode to get the answer, so it already includes a user
> mode component.
>
> Your string handling is pretty gnarly for KM code. At a minimum
> uniDomainName.Length should be set to zero. This is an output parameter, so
> the API needs to know it can fill in between Length and MaxLength bytes.
> You can clean up your two declarations with something like:
>
> DECLARE_CONST_UNICODE_STRING(domainAndUser, L"FOO\Bar");
> DECLARE_UNICODE_STRING_SIZE(domainName, MAX_STRING);
>
> Also note that the DomainSize parameter is strictly Out, so you don’t
> need to set it before the call.
>
> Not sure if any of that fixes your problems but it will at least get rid
> of some of this code.
>
> -scott
> OSR
> @OSRDrivers
>
> “JIm james” wrote in message news:xxxxx@ntfsd…
> Thanks Scott for the suggestion. Yes we may end up being forced to
> interact with a user mode component to resolve the SIDs but that would
> compromise our solution. The only reason that we would go to user mode is
> because the API doesn’t work. It’s hard for me to believe that the API
> doesn’t work - I must be doing something wrong…
>
>
> On Mon, Feb 27, 2017 at 7:47 AM, Scott Noone wrote:
> Not necessarily helpful, but I usually do all this sort of thing in user
> mode. Casual googling shows other people having unexpected issues with this
> API over the years though I have no experience with it.
>
> Where are you getting the user name from? If it’s coming from a user mode
> application, can you just have them send you the SID instead?
>
> -scott
> OSR
> @OSRDrivers
>
> “JIm james” wrote in message news:xxxxx@ntfsd…
>
> All,
> Our mini filter driver is calling SecLookupAccountName() from within a
> thread. It is being used to resolve a user name to a SID. The computer is
> part of a domain so the user name is in the form of (domain
> name)(username). The call to SecLookupAccount returns successfully but the
> SID is incorrect and the domain name is not updated - just the length.
> Below is the code that I’m using to call the function.
>
> Does anyone have any experience with using this function?
> Thanks in advance.
>
> // Define space for the returned SID
> UCHAR sid[SECURITY_MAX_SID_SIZE];
> sidSize = SECURITY_MAX_SID_SIZE;
>
> // Setup the unicode string for the user name
> WCHAR szwUserName[260];
> wcscpy(&szwUserName[0], L"DHS\MarkFoo");
> uniUserName.Buffer = &szwUserName[0];
> uniUserName.Length = (USHORT)(2 * wcslen(&szwUserName[0]));
> uniUserName.MaximumLength = uniUserName.Length + sizeof(WCHAR);
>
> // set up the unicode string to receive the domain name
> domainSize = 2*MAX_STRING;
> szwDomainName[0] = 0;
> uniDomainName.Buffer = &szwDomainName[0];
> uniDomainName.Length = 2 * MAX_STRING - sizeof(WCHAR);
> uniDomainName.MaximumLength = 2 * MAX_STRING;
>
>
> sidStatus = SecLookupAccountName(&uniUserName,
> &sidSize,
> &sid[0],
> &sidNameUse,
> &domainSize,
> &uniDomainName);
> if (sidStatus != STATUS_SUCCESS)
> {
> }
> else
> {
> }
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

These changes weren’t all superficial, the length in your domainName
UNICODE_STRING was wrong. For an empty string it should be zero so that
there’s room to return output.

The annotation for DomainSize says Out so the text description and
function prototype don’t match. Looking at the usage of this variable in the
debugger it’s definitely strictly output. I have filed a doc bug to get the
description fixed.

-scott
OSR
@OSRDrivers

“JIm james” wrote in message news:xxxxx@ntfsd…
No these superficial changes make no difference. If you read the
documentation on SecLookupAccountName you’ll see that DomainSize is an
in/out parameters that must be set to size of Reference Domain Name buffer
before making the call.

On Mon, Feb 27, 2017 at 3:19 PM, Scott Noone wrote:
In what way do you mean “compromise”? Note that per the documentation this
API talks to user mode to get the answer, so it already includes a user mode
component.

Your string handling is pretty gnarly for KM code. At a minimum
uniDomainName.Length should be set to zero. This is an output parameter, so
the API needs to know it can fill in between Length and MaxLength bytes. You
can clean up your two declarations with something like:

DECLARE_CONST_UNICODE_STRING(domainAndUser, L"FOO\Bar");
DECLARE_UNICODE_STRING_SIZE(domainName, MAX_STRING);

Also note that the DomainSize parameter is strictly Out, so you don’t need
to set it before the call.

Not sure if any of that fixes your problems but it will at least get rid of
some of this code.

-scott
OSR
@OSRDrivers

“JIm james” wrote in message news:xxxxx@ntfsd…
Thanks Scott for the suggestion. Yes we may end up being forced to interact
with a user mode component to resolve the SIDs but that would compromise our
solution. The only reason that we would go to user mode is because the API
doesn’t work. It’s hard for me to believe that the API doesn’t work - I must
be doing something wrong…

On Mon, Feb 27, 2017 at 7:47 AM, Scott Noone wrote:

Not necessarily helpful, but I usually do all this sort of thing in user
mode. Casual googling shows other people having unexpected issues with this
API over the years though I have no experience with it.

Where are you getting the user name from? If it’s coming from a user mode
application, can you just have them send you the SID instead?

-scott
OSR
@OSRDrivers

“JIm james” wrote in message news:xxxxx@ntfsd…

All,
Our mini filter driver is calling SecLookupAccountName() from within a
thread. It is being used to resolve a user name to a SID. The computer is
part of a domain so the user name is in the form of (domain
name)(username). The call to SecLookupAccount returns successfully but the
SID is incorrect and the domain name is not updated - just the length. Below
is the code that I’m using to call the function.

Does anyone have any experience with using this function?
Thanks in advance.

// Define space for the returned SID
UCHAR sid[SECURITY_MAX_SID_SIZE];
sidSize = SECURITY_MAX_SID_SIZE;

// Setup the unicode string for the user name
WCHAR szwUserName[260];
wcscpy(&szwUserName[0], L"DHS\MarkFoo");
uniUserName.Buffer = &szwUserName[0];
uniUserName.Length = (USHORT)(2 * wcslen(&szwUserName[0]));
uniUserName.MaximumLength = uniUserName.Length + sizeof(WCHAR);

// set up the unicode string to receive the domain name
domainSize = 2*MAX_STRING;
szwDomainName[0] = 0;
uniDomainName.Buffer = &szwDomainName[0];
uniDomainName.Length = 2 * MAX_STRING - sizeof(WCHAR);
uniDomainName.MaximumLength = 2 * MAX_STRING;

sidStatus = SecLookupAccountName(&uniUserName,
&sidSize,
&sid[0],
&sidNameUse,
&domainSize,
&uniDomainName);
if (sidStatus != STATUS_SUCCESS)
{
}
else
{
}


NTFSD is sponsored by OSR

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:


NTFSD is sponsored by OSR

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:></http:>

If setting the value of “Length” is wrong then setting it to zero made no
difference at all.

Anyway …

Does anyone have any experience using this function?

On Tue, Feb 28, 2017 at 1:53 PM, Scott Noone wrote:

> These changes weren’t all superficial, the length in your domainName
> UNICODE_STRING was wrong. For an empty string it should be zero so that
> there’s room to return output.
>
> The annotation for DomainSize says Out so the text description and
> function prototype don’t match. Looking at the usage of this variable in
> the debugger it’s definitely strictly output. I have filed a doc bug to get
> the description fixed.
>
> -scott
> OSR
> @OSRDrivers
>
> “JIm james” wrote in message news:xxxxx@ntfsd…
> No these superficial changes make no difference. If you read the
> documentation on SecLookupAccountName you’ll see that DomainSize is an
> in/out parameters that must be set to size of Reference Domain Name
> buffer before making the call.
>
> On Mon, Feb 27, 2017 at 3:19 PM, Scott Noone wrote:
> In what way do you mean “compromise”? Note that per the documentation this
> API talks to user mode to get the answer, so it already includes a user
> mode component.
>
> Your string handling is pretty gnarly for KM code. At a minimum
> uniDomainName.Length should be set to zero. This is an output parameter, so
> the API needs to know it can fill in between Length and MaxLength bytes.
> You can clean up your two declarations with something like:
>
> DECLARE_CONST_UNICODE_STRING(domainAndUser, L"FOO\Bar");
> DECLARE_UNICODE_STRING_SIZE(domainName, MAX_STRING);
>
> Also note that the DomainSize parameter is strictly Out, so you don’t
> need to set it before the call.
>
> Not sure if any of that fixes your problems but it will at least get rid
> of some of this code.
>
> -scott
> OSR
> @OSRDrivers
>
> “JIm james” wrote in message news:xxxxx@ntfsd…
> Thanks Scott for the suggestion. Yes we may end up being forced to
> interact with a user mode component to resolve the SIDs but that would
> compromise our solution. The only reason that we would go to user mode is
> because the API doesn’t work. It’s hard for me to believe that the API
> doesn’t work - I must be doing something wrong…
>
>
> On Mon, Feb 27, 2017 at 7:47 AM, Scott Noone wrote:
>
> Not necessarily helpful, but I usually do all this sort of thing in user
> mode. Casual googling shows other people having unexpected issues with this
> API over the years though I have no experience with it.
>
> Where are you getting the user name from? If it’s coming from a user mode
> application, can you just have them send you the SID instead?
>
> -scott
> OSR
> @OSRDrivers
>
> “JIm james” wrote in message news:xxxxx@ntfsd…
>
> All,
> Our mini filter driver is calling SecLookupAccountName() from within a
> thread. It is being used to resolve a user name to a SID. The computer is
> part of a domain so the user name is in the form of (domain
> name)(username). The call to SecLookupAccount returns successfully but the
> SID is incorrect and the domain name is not updated - just the length.
> Below is the code that I’m using to call the function.
>
> Does anyone have any experience with using this function?
> Thanks in advance.
>
> // Define space for the returned SID
> UCHAR sid[SECURITY_MAX_SID_SIZE];
> sidSize = SECURITY_MAX_SID_SIZE;
>
> // Setup the unicode string for the user name
> WCHAR szwUserName[260];
> wcscpy(&szwUserName[0], L"DHS\MarkFoo");
> uniUserName.Buffer = &szwUserName[0];
> uniUserName.Length = (USHORT)(2 * wcslen(&szwUserName[0]));
> uniUserName.MaximumLength = uniUserName.Length + sizeof(WCHAR);
>
> // set up the unicode string to receive the domain name
> domainSize = 2*MAX_STRING;
> szwDomainName[0] = 0;
> uniDomainName.Buffer = &szwDomainName[0];
> uniDomainName.Length = 2 * MAX_STRING - sizeof(WCHAR);
> uniDomainName.MaximumLength = 2 * MAX_STRING;
>
>
> sidStatus = SecLookupAccountName(&uniUserName,
> &sidSize,
> &sid[0],
> &sidNameUse,
> &domainSize,
> &uniDomainName);
> if (sidStatus != STATUS_SUCCESS)
> {
> }
> else
> {
> }
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:></http:>

>“JIm james” wrote in message news:xxxxx@ntfsd…
>If setting the value of “Length” is wrong then setting it to zero made no
>difference at all.

Then I just saved you from another bug down the road. What can I say except
you’re welcome!

I would step through in the debugger at this point and gather more
information. The function isn’t that large, I had hoped to do it myself out
of curiosity.

Good luck!

-scott
OSR
@OSRDrivers

“JIm james” wrote in message news:xxxxx@ntfsd…
If setting the value of “Length” is wrong then setting it to zero made no
difference at all.

Anyway …

Does anyone have any experience using this function?

On Tue, Feb 28, 2017 at 1:53 PM, Scott Noone wrote:
These changes weren’t all superficial, the length in your domainName
UNICODE_STRING was wrong. For an empty string it should be zero so that
there’s room to return output.

The annotation for DomainSize says Out so the text description and
function prototype don’t match. Looking at the usage of this variable in the
debugger it’s definitely strictly output. I have filed a doc bug to get the
description fixed.

-scott
OSR
@OSRDrivers

“JIm james” wrote in message news:xxxxx@ntfsd…
No these superficial changes make no difference. If you read the
documentation on SecLookupAccountName you’ll see that DomainSize is an
in/out parameters that must be set to size of Reference Domain Name buffer
before making the call.

On Mon, Feb 27, 2017 at 3:19 PM, Scott Noone wrote:

In what way do you mean “compromise”? Note that per the documentation this
API talks to user mode to get the answer, so it already includes a user mode
component.

Your string handling is pretty gnarly for KM code. At a minimum
uniDomainName.Length should be set to zero. This is an output parameter, so
the API needs to know it can fill in between Length and MaxLength bytes. You
can clean up your two declarations with something like:

DECLARE_CONST_UNICODE_STRING(domainAndUser, L"FOO\Bar");
DECLARE_UNICODE_STRING_SIZE(domainName, MAX_STRING);

Also note that the DomainSize parameter is strictly Out, so you don’t need
to set it before the call.

Not sure if any of that fixes your problems but it will at least get rid of
some of this code.

-scott
OSR
@OSRDrivers

“JIm james” wrote in message news:xxxxx@ntfsd…
Thanks Scott for the suggestion. Yes we may end up being forced to interact
with a user mode component to resolve the SIDs but that would compromise our
solution. The only reason that we would go to user mode is because the API
doesn’t work. It’s hard for me to believe that the API doesn’t work - I must
be doing something wrong…

On Mon, Feb 27, 2017 at 7:47 AM, Scott Noone wrote:

Not necessarily helpful, but I usually do all this sort of thing in user
mode. Casual googling shows other people having unexpected issues with this
API over the years though I have no experience with it.

Where are you getting the user name from? If it’s coming from a user mode
application, can you just have them send you the SID instead?

-scott
OSR
@OSRDrivers

“JIm james” wrote in message news:xxxxx@ntfsd…

All,
Our mini filter driver is calling SecLookupAccountName() from within a
thread. It is being used to resolve a user name to a SID. The computer is
part of a domain so the user name is in the form of (domain
name)(username). The call to SecLookupAccount returns successfully but the
SID is incorrect and the domain name is not updated - just the length. Below
is the code that I’m using to call the function.

Does anyone have any experience with using this function?
Thanks in advance.

// Define space for the returned SID
UCHAR sid[SECURITY_MAX_SID_SIZE];
sidSize = SECURITY_MAX_SID_SIZE;

// Setup the unicode string for the user name
WCHAR szwUserName[260];
wcscpy(&szwUserName[0], L"DHS\MarkFoo");
uniUserName.Buffer = &szwUserName[0];
uniUserName.Length = (USHORT)(2 * wcslen(&szwUserName[0]));
uniUserName.MaximumLength = uniUserName.Length + sizeof(WCHAR);

// set up the unicode string to receive the domain name
domainSize = 2*MAX_STRING;
szwDomainName[0] = 0;
uniDomainName.Buffer = &szwDomainName[0];
uniDomainName.Length = 2 * MAX_STRING - sizeof(WCHAR);
uniDomainName.MaximumLength = 2 * MAX_STRING;

sidStatus = SecLookupAccountName(&uniUserName,
&sidSize,
&sid[0],
&sidNameUse,
&domainSize,
&uniDomainName);
if (sidStatus != STATUS_SUCCESS)
{
}
else
{
}


NTFSD is sponsored by OSR

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:


NTFSD is sponsored by OSR

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:


NTFSD is sponsored by OSR

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:></http:></http:></http:>

Good suggestion and thanks.

On Tue, Feb 28, 2017 at 4:08 PM, Scott Noone wrote:

> “JIm james” wrote in message news:xxxxx@ntfsd…
>> If setting the value of “Length” is wrong then setting it to zero made no
>> difference at all.
>>
>
> Then I just saved you from another bug down the road. What can I say
> except you’re welcome!
>
> I would step through in the debugger at this point and gather more
> information. The function isn’t that large, I had hoped to do it myself out
> of curiosity.
>
> Good luck!
>
> -scott
> OSR
> @OSRDrivers
>
> “JIm james” wrote in message news:xxxxx@ntfsd…
> If setting the value of “Length” is wrong then setting it to zero made no
> difference at all.
>
> Anyway …
>
> Does anyone have any experience using this function?
>
>
>
> On Tue, Feb 28, 2017 at 1:53 PM, Scott Noone wrote:
> These changes weren’t all superficial, the length in your domainName
> UNICODE_STRING was wrong. For an empty string it should be zero so that
> there’s room to return output.
>
> The annotation for DomainSize says Out so the text description and
> function prototype don’t match. Looking at the usage of this variable in
> the debugger it’s definitely strictly output. I have filed a doc bug to get
> the description fixed.
>
> -scott
> OSR
> @OSRDrivers
>
> “JIm james” wrote in message news:xxxxx@ntfsd…
> No these superficial changes make no difference. If you read the
> documentation on SecLookupAccountName you’ll see that DomainSize is an
> in/out parameters that must be set to size of Reference Domain Name
> buffer before making the call.
>
> On Mon, Feb 27, 2017 at 3:19 PM, Scott Noone wrote:
>
> In what way do you mean “compromise”? Note that per the documentation this
> API talks to user mode to get the answer, so it already includes a user
> mode component.
>
> Your string handling is pretty gnarly for KM code. At a minimum
> uniDomainName.Length should be set to zero. This is an output parameter, so
> the API needs to know it can fill in between Length and MaxLength bytes.
> You can clean up your two declarations with something like:
>
> DECLARE_CONST_UNICODE_STRING(domainAndUser, L"FOO\Bar");
> DECLARE_UNICODE_STRING_SIZE(domainName, MAX_STRING);
>
> Also note that the DomainSize parameter is strictly Out, so you don’t
> need to set it before the call.
>
> Not sure if any of that fixes your problems but it will at least get rid
> of some of this code.
>
> -scott
> OSR
> @OSRDrivers
>
> “JIm james” wrote in message news:xxxxx@ntfsd…
> Thanks Scott for the suggestion. Yes we may end up being forced to
> interact with a user mode component to resolve the SIDs but that would
> compromise our solution. The only reason that we would go to user mode is
> because the API doesn’t work. It’s hard for me to believe that the API
> doesn’t work - I must be doing something wrong…
>
>
> On Mon, Feb 27, 2017 at 7:47 AM, Scott Noone wrote:
>
> Not necessarily helpful, but I usually do all this sort of thing in user
> mode. Casual googling shows other people having unexpected issues with this
> API over the years though I have no experience with it.
>
> Where are you getting the user name from? If it’s coming from a user mode
> application, can you just have them send you the SID instead?
>
> -scott
> OSR
> @OSRDrivers
>
> “JIm james” wrote in message news:xxxxx@ntfsd…
>
> All,
> Our mini filter driver is calling SecLookupAccountName() from within a
> thread. It is being used to resolve a user name to a SID. The computer is
> part of a domain so the user name is in the form of (domain
> name)(username). The call to SecLookupAccount returns successfully but the
> SID is incorrect and the domain name is not updated - just the length.
> Below is the code that I’m using to call the function.
>
> Does anyone have any experience with using this function?
> Thanks in advance.
>
> // Define space for the returned SID
> UCHAR sid[SECURITY_MAX_SID_SIZE];
> sidSize = SECURITY_MAX_SID_SIZE;
>
> // Setup the unicode string for the user name
> WCHAR szwUserName[260];
> wcscpy(&szwUserName[0], L"DHS\MarkFoo");
> uniUserName.Buffer = &szwUserName[0];
> uniUserName.Length = (USHORT)(2 * wcslen(&szwUserName[0]));
> uniUserName.MaximumLength = uniUserName.Length + sizeof(WCHAR);
>
> // set up the unicode string to receive the domain name
> domainSize = 2*MAX_STRING;
> szwDomainName[0] = 0;
> uniDomainName.Buffer = &szwDomainName[0];
> uniDomainName.Length = 2 * MAX_STRING - sizeof(WCHAR);
> uniDomainName.MaximumLength = 2 * MAX_STRING;
>
>
> sidStatus = SecLookupAccountName(&uniUserName,
> &sidSize,
> &sid[0],
> &sidNameUse,
> &domainSize,
> &uniDomainName);
> if (sidStatus != STATUS_SUCCESS)
> {
> }
> else
> {
> }
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:></http:></http:>