Incorrect LogonUserIdentity.Name

Discussion in 'ASP .Net Security' started by Scott_A, Jul 9, 2008.

  1. Scott_A

    Scott_A Guest

    We have an AD user account that was setup as R_Smith and then was changed to
    JR_Smith.

    One of our web applications does a database look up using the
    LogonUserIdentity.Name value but this is still returning R_Smith even though
    the user logged onto his box with JR_Smith.



    Also I created a page that looked at the server variables and AUTH_USER,
    LOGON_USER and REMOTE_USER all return the correct JR_Smith. This page is
    running on the same web server and in the same virtual directory as the web
    application. Why would the server variables return different values to the
    LogonUserIdentity.Name? Do they pull different attributes from AD? All the
    account settings in AD look fine.

    Any ideas?

    Thanks

    Scott

    (I have also posted this on the asp.net forums but have had no luck yet)
     
    Scott_A, Jul 9, 2008
    #1
    1. Advertising

  2. Scott_A

    Joe Kaplan Guest

    Did you try rebooting the box? Maybe something is cached somewhere in LSA
    memory? I'm uncertain why the server variables would be up to date but this
    code would be wrong, but perhaps there are different underlying API calls
    that get the data from different places.

    It will probably eventually fix itself either way.

    --
    Joe Kaplan-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    http://www.directoryprogramming.net
    --
    "Scott_A" <> wrote in message
    news:...
    > We have an AD user account that was setup as R_Smith and then was changed
    > to
    > JR_Smith.
    >
    > One of our web applications does a database look up using the
    > LogonUserIdentity.Name value but this is still returning R_Smith even
    > though
    > the user logged onto his box with JR_Smith.
    >
    >
    >
    > Also I created a page that looked at the server variables and AUTH_USER,
    > LOGON_USER and REMOTE_USER all return the correct JR_Smith. This page is
    > running on the same web server and in the same virtual directory as the
    > web
    > application. Why would the server variables return different values to the
    > LogonUserIdentity.Name? Do they pull different attributes from AD? All the
    > account settings in AD look fine.
    >
    > Any ideas?
    >
    > Thanks
    >
    > Scott
    >
    > (I have also posted this on the asp.net forums but have had no luck yet)
     
    Joe Kaplan, Jul 9, 2008
    #2
    1. Advertising

  3. Scott_A

    Scott_A Guest

    Thanks for the reply.

    Yes I have rebooted the box and have also run that code on different boxes
    that authenticate to different DC's. ("%logonserver%")

    I also think there are different API's in play but which ones and where do
    they get their info from?

    Scott

    "Joe Kaplan" wrote:

    > Did you try rebooting the box? Maybe something is cached somewhere in LSA
    > memory? I'm uncertain why the server variables would be up to date but this
    > code would be wrong, but perhaps there are different underlying API calls
    > that get the data from different places.
    >
    > It will probably eventually fix itself either way.
    >
    > --
    > Joe Kaplan-MS MVP Directory Services Programming
    > Co-author of "The .NET Developer's Guide to Directory Services Programming"
    > http://www.directoryprogramming.net
    > --
    > "Scott_A" <> wrote in message
    > news:...
    > > We have an AD user account that was setup as R_Smith and then was changed
    > > to
    > > JR_Smith.
    > >
    > > One of our web applications does a database look up using the
    > > LogonUserIdentity.Name value but this is still returning R_Smith even
    > > though
    > > the user logged onto his box with JR_Smith.
    > >
    > >
    > >
    > > Also I created a page that looked at the server variables and AUTH_USER,
    > > LOGON_USER and REMOTE_USER all return the correct JR_Smith. This page is
    > > running on the same web server and in the same virtual directory as the
    > > web
    > > application. Why would the server variables return different values to the
    > > LogonUserIdentity.Name? Do they pull different attributes from AD? All the
    > > account settings in AD look fine.
    > >
    > > Any ideas?
    > >
    > > Thanks
    > >
    > > Scott
    > >
    > > (I have also posted this on the asp.net forums but have had no luck yet)

    >
    >
    >
     
    Scott_A, Jul 9, 2008
    #3
  4. Scott_A

    Joe Kaplan Guest

    I'm not really what's going on then. I can tell you that the
    WindowsIdentity class uses the various Translate methods off the
    IdentityReferenceCollection to do name translation (really different than
    ..NET 1.x) and those use the LsaLookupSids under the hood among other things.
    It would appear that that particular API is returning the old name for some
    reason while some other APIs are not.

    I still don't know what the root of the problem is or how to get it resolved
    though, especially if rebooting didn't resolve it.

    Sorry.

    --
    Joe Kaplan-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    http://www.directoryprogramming.net
    --
    "Scott_A" <> wrote in message
    news:...
    > Thanks for the reply.
    >
    > Yes I have rebooted the box and have also run that code on different boxes
    > that authenticate to different DC's. ("%logonserver%")
    >
    > I also think there are different API's in play but which ones and where do
    > they get their info from?
    >
    > Scott
    >
    > "Joe Kaplan" wrote:
    >
    >> Did you try rebooting the box? Maybe something is cached somewhere in
    >> LSA
    >> memory? I'm uncertain why the server variables would be up to date but
    >> this
    >> code would be wrong, but perhaps there are different underlying API calls
    >> that get the data from different places.
    >>
    >> It will probably eventually fix itself either way.
    >>
    >> --
    >> Joe Kaplan-MS MVP Directory Services Programming
    >> Co-author of "The .NET Developer's Guide to Directory Services
    >> Programming"
    >> http://www.directoryprogramming.net
    >> --
    >> "Scott_A" <> wrote in message
    >> news:...
    >> > We have an AD user account that was setup as R_Smith and then was
    >> > changed
    >> > to
    >> > JR_Smith.
    >> >
    >> > One of our web applications does a database look up using the
    >> > LogonUserIdentity.Name value but this is still returning R_Smith even
    >> > though
    >> > the user logged onto his box with JR_Smith.
    >> >
    >> >
    >> >
    >> > Also I created a page that looked at the server variables and
    >> > AUTH_USER,
    >> > LOGON_USER and REMOTE_USER all return the correct JR_Smith. This page
    >> > is
    >> > running on the same web server and in the same virtual directory as the
    >> > web
    >> > application. Why would the server variables return different values to
    >> > the
    >> > LogonUserIdentity.Name? Do they pull different attributes from AD? All
    >> > the
    >> > account settings in AD look fine.
    >> >
    >> > Any ideas?
    >> >
    >> > Thanks
    >> >
    >> > Scott
    >> >
    >> > (I have also posted this on the asp.net forums but have had no luck
    >> > yet)

    >>
    >>
    >>
     
    Joe Kaplan, Jul 9, 2008
    #4
  5. Scott_A

    Joe Kaplan Guest

    Note that you might consider using a more durable key into your SQL database
    in the future to help avoid these types of problems. :)

    The ideal thing to use for AD users is the GUID (objectGUID attribute in the
    directory) since it rename safe, even across domain moves in a multi-domain
    forest, is fixed size, has convenient binary and string representations and
    also fits nicely into the SQL UniqueIdentifier type.

    Another thing you could use is the SID. It isn't as durable and is variable
    length, but it is more rename safe. It is also easier to get from the
    WindowsIdentity since it is built in where as the GUID would require some
    sort of a lookup.

    Just an idea. It sounds like that ship may have already sailed and you
    really just need to get this fixed, but this may not be the last time you
    have this problem.

    --
    Joe Kaplan-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    http://www.directoryprogramming.net
    --
    "Scott_A" <> wrote in message
    news:...
    > Thanks for the reply.
    >
    > Yes I have rebooted the box and have also run that code on different boxes
    > that authenticate to different DC's. ("%logonserver%")
    >
    > I also think there are different API's in play but which ones and where do
    > they get their info from?
    >
    > Scott
    >
    > "Joe Kaplan" wrote:
    >
    >> Did you try rebooting the box? Maybe something is cached somewhere in
    >> LSA
    >> memory? I'm uncertain why the server variables would be up to date but
    >> this
    >> code would be wrong, but perhaps there are different underlying API calls
    >> that get the data from different places.
    >>
    >> It will probably eventually fix itself either way.
    >>
    >> --
    >> Joe Kaplan-MS MVP Directory Services Programming
    >> Co-author of "The .NET Developer's Guide to Directory Services
    >> Programming"
    >> http://www.directoryprogramming.net
    >> --
    >> "Scott_A" <> wrote in message
    >> news:...
    >> > We have an AD user account that was setup as R_Smith and then was
    >> > changed
    >> > to
    >> > JR_Smith.
    >> >
    >> > One of our web applications does a database look up using the
    >> > LogonUserIdentity.Name value but this is still returning R_Smith even
    >> > though
    >> > the user logged onto his box with JR_Smith.
    >> >
    >> >
    >> >
    >> > Also I created a page that looked at the server variables and
    >> > AUTH_USER,
    >> > LOGON_USER and REMOTE_USER all return the correct JR_Smith. This page
    >> > is
    >> > running on the same web server and in the same virtual directory as the
    >> > web
    >> > application. Why would the server variables return different values to
    >> > the
    >> > LogonUserIdentity.Name? Do they pull different attributes from AD? All
    >> > the
    >> > account settings in AD look fine.
    >> >
    >> > Any ideas?
    >> >
    >> > Thanks
    >> >
    >> > Scott
    >> >
    >> > (I have also posted this on the asp.net forums but have had no luck
    >> > yet)

    >>
    >>
    >>
     
    Joe Kaplan, Jul 9, 2008
    #5
  6. Scott_A

    Scott_A Guest

    Thanks for the help and ideas. It's for a 3rd party app that I had to
    decompile a bit to see what was happening.

    I will wait another night and reboot in the morning and hope that it
    resolves itself like these usually do.

    Scott

    "Joe Kaplan" wrote:

    > Note that you might consider using a more durable key into your SQL database
    > in the future to help avoid these types of problems. :)
    >
    > The ideal thing to use for AD users is the GUID (objectGUID attribute in the
    > directory) since it rename safe, even across domain moves in a multi-domain
    > forest, is fixed size, has convenient binary and string representations and
    > also fits nicely into the SQL UniqueIdentifier type.
    >
    > Another thing you could use is the SID. It isn't as durable and is variable
    > length, but it is more rename safe. It is also easier to get from the
    > WindowsIdentity since it is built in where as the GUID would require some
    > sort of a lookup.
    >
    > Just an idea. It sounds like that ship may have already sailed and you
    > really just need to get this fixed, but this may not be the last time you
    > have this problem.
    >
    > --
    > Joe Kaplan-MS MVP Directory Services Programming
    > Co-author of "The .NET Developer's Guide to Directory Services Programming"
    > http://www.directoryprogramming.net
    > --
    > "Scott_A" <> wrote in message
    > news:...
    > > Thanks for the reply.
    > >
    > > Yes I have rebooted the box and have also run that code on different boxes
    > > that authenticate to different DC's. ("%logonserver%")
    > >
    > > I also think there are different API's in play but which ones and where do
    > > they get their info from?
    > >
    > > Scott
    > >
    > > "Joe Kaplan" wrote:
    > >
    > >> Did you try rebooting the box? Maybe something is cached somewhere in
    > >> LSA
    > >> memory? I'm uncertain why the server variables would be up to date but
    > >> this
    > >> code would be wrong, but perhaps there are different underlying API calls
    > >> that get the data from different places.
    > >>
    > >> It will probably eventually fix itself either way.
    > >>
    > >> --
    > >> Joe Kaplan-MS MVP Directory Services Programming
    > >> Co-author of "The .NET Developer's Guide to Directory Services
    > >> Programming"
    > >> http://www.directoryprogramming.net
    > >> --
    > >> "Scott_A" <> wrote in message
    > >> news:...
    > >> > We have an AD user account that was setup as R_Smith and then was
    > >> > changed
    > >> > to
    > >> > JR_Smith.
    > >> >
    > >> > One of our web applications does a database look up using the
    > >> > LogonUserIdentity.Name value but this is still returning R_Smith even
    > >> > though
    > >> > the user logged onto his box with JR_Smith.
    > >> >
    > >> >
    > >> >
    > >> > Also I created a page that looked at the server variables and
    > >> > AUTH_USER,
    > >> > LOGON_USER and REMOTE_USER all return the correct JR_Smith. This page
    > >> > is
    > >> > running on the same web server and in the same virtual directory as the
    > >> > web
    > >> > application. Why would the server variables return different values to
    > >> > the
    > >> > LogonUserIdentity.Name? Do they pull different attributes from AD? All
    > >> > the
    > >> > account settings in AD look fine.
    > >> >
    > >> > Any ideas?
    > >> >
    > >> > Thanks
    > >> >
    > >> > Scott
    > >> >
    > >> > (I have also posted this on the asp.net forums but have had no luck
    > >> > yet)
    > >>
    > >>
    > >>

    >
    >
    >
     
    Scott_A, Jul 9, 2008
    #6
  7. Did you resolve this?

    I am running into the same exact problem. Did you ever resolve this issue?

    > On Wednesday, July 09, 2008 11:36 AM Scott wrote:


    > We have an AD user account that was setup as R_Smith and then was changed to
    > JR_Smith.
    >
    > One of our web applications does a database look up using the
    > LogonUserIdentity.Name value but this is still returning R_Smith even though
    > the user logged onto his box with JR_Smith.
    >
    >
    >
    > Also I created a page that looked at the server variables and AUTH_USER,
    > LOGON_USER and REMOTE_USER all return the correct JR_Smith. This page is
    > running on the same web server and in the same virtual directory as the web
    > application. Why would the server variables return different values to the
    > LogonUserIdentity.Name? Do they pull different attributes from AD? All the
    > account settings in AD look fine.
    >
    > Any ideas?
    >
    > Thanks
    >
    > Scott
    >
    > (I have also posted this on the asp.net forums but have had no luck yet)



    >> On Wednesday, July 09, 2008 1:06 PM Joe Kaplan wrote:


    >> Did you try rebooting the box? Maybe something is cached somewhere in LSA
    >> memory? I'm uncertain why the server variables would be up to date but this
    >> code would be wrong, but perhaps there are different underlying API calls
    >> that get the data from different places.
    >>
    >> It will probably eventually fix itself either way.
    >>
    >> --
    >> Joe Kaplan-MS MVP Directory Services Programming
    >> Co-author of "The .NET Developer's Guide to Directory Services Programming"
    >> http://www.directoryprogramming.net
    >> --
    >> "Scott_A" <> wrote in message
    >> news:...



    >>> On Wednesday, July 09, 2008 2:24 PM Scott wrote:


    >>> Thanks for the reply.
    >>>
    >>> Yes I have rebooted the box and have also run that code on different boxes
    >>> that authenticate to different DC's. ("%logonserver%")
    >>>
    >>> I also think there are different API's in play but which ones and where do
    >>> they get their info from?
    >>>
    >>> Scott
    >>>
    >>> "Joe Kaplan" wrote:



    >>>> On Wednesday, July 09, 2008 2:54 PM Joe Kaplan wrote:


    >>>> I'm not really what's going on then. I can tell you that the
    >>>> WindowsIdentity class uses the various Translate methods off the
    >>>> IdentityReferenceCollection to do name translation (really different than
    >>>> .NET 1.x) and those use the LsaLookupSids under the hood among other things.
    >>>> It would appear that that particular API is returning the old name for some
    >>>> reason while some other APIs are not.
    >>>>
    >>>> I still don't know what the root of the problem is or how to get it resolved
    >>>> though, especially if rebooting didn't resolve it.
    >>>>
    >>>> Sorry.
    >>>>
    >>>> --
    >>>> Joe Kaplan-MS MVP Directory Services Programming
    >>>> Co-author of "The .NET Developer's Guide to Directory Services Programming"
    >>>> http://www.directoryprogramming.net
    >>>> --
    >>>> "Scott_A" <> wrote in message
    >>>> news:...



    >>>>> On Wednesday, July 09, 2008 2:58 PM Joe Kaplan wrote:


    >>>>> Note that you might consider using a more durable key into your SQL database
    >>>>> in the future to help avoid these types of problems. :)
    >>>>>
    >>>>> The ideal thing to use for AD users is the GUID (objectGUID attribute in the
    >>>>> directory) since it rename safe, even across domain moves in a multi-domain
    >>>>> forest, is fixed size, has convenient binary and string representations and
    >>>>> also fits nicely into the SQL UniqueIdentifier type.
    >>>>>
    >>>>> Another thing you could use is the SID. It isn't as durable and is variable
    >>>>> length, but it is more rename safe. It is also easier to get from the
    >>>>> WindowsIdentity since it is built in where as the GUID would require some
    >>>>> sort of a lookup.
    >>>>>
    >>>>> Just an idea. It sounds like that ship may have already sailed and you
    >>>>> really just need to get this fixed, but this may not be the last time you
    >>>>> have this problem.
    >>>>>
    >>>>> --
    >>>>> Joe Kaplan-MS MVP Directory Services Programming
    >>>>> Co-author of "The .NET Developer's Guide to Directory Services Programming"
    >>>>> http://www.directoryprogramming.net
    >>>>> --
    >>>>> "Scott_A" <> wrote in message
    >>>>> news:...



    >>>>>> On Wednesday, July 09, 2008 4:34 PM Scott wrote:


    >>>>>> Thanks for the help and ideas. It's for a 3rd party app that I had to
    >>>>>> decompile a bit to see what was happening.
    >>>>>>
    >>>>>> I will wait another night and reboot in the morning and hope that it
    >>>>>> resolves itself like these usually do.
    >>>>>>
    >>>>>> Scott
    >>>>>>
    >>>>>> "Joe Kaplan" wrote:



    >>>>>> Submitted via EggHeadCafe - Software Developer Portal of Choice
    >>>>>> WPF Control?s Default Style or Template by Extending the WPF Designer in Visual Studio 2010
    >>>>>> http://www.eggheadcafe.com/tutorial...g-the-wpf-designer-in-visual-studio-2010.aspx
     
    Joseph Sedlar, Aug 23, 2010
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Trevor
    Replies:
    4
    Views:
    4,547
    Peter Bromberg [C# MVP]
    May 8, 2008
  2. =?iso-8859-1?B?bW9vcJk=?=
    Replies:
    7
    Views:
    833
    Roedy Green
    Jan 2, 2006
  3. ding feng
    Replies:
    2
    Views:
    2,826
    ding feng
    Jun 25, 2003
  4. Replies:
    3
    Views:
    2,278
    Juan T. Llibre
    Nov 29, 2006
  5. senglory
    Replies:
    0
    Views:
    1,057
    senglory
    Jan 24, 2011
Loading...

Share This Page