Re: Windows Server 2008 impersonation.

ADSI was more limited years ago so perhaps that was the issue. In some cases, the SetPassword method can be a pain to deal with in general and some use cases may actually require the impersonation.

It is often cleaner just to set up a separate app pool for this app on the server, run it as the admin user, add the user to the appropriate IIS_WPG group and get rid of the impersonation AND the hard coded credentials. The key is getting the right windows identity to do the work on the remote machine and any of those approaches could work but this one is probably easiest and most secure in that the admin is more in charge since the config change to the app pool is made externally.

Best of luck!

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Ron" <Ron@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:7CB7DB99-D0EF-40FF-8A64-1F857515485E@xxxxxxxxxxxxxxxx
When that was first developed, we could not get the password to reset without
doing the impersonation. That was several years ago, however.

Thanks for your help...I will try it with the authorization in the
DirectoryEntry constructor.

"Joe Kaplan" wrote:

Invoke of the ADSI SetPassword method should throw an exception if the
password modification operation fails. So, it seems like something may be
getting lost in translation here.

Normally, you don't need impersonation code for this. You would just put
the creds used for impersonation directly into the DirectoryEntry
constructor. That's quite a bit less code. :)

Normally I'd use a network login type for this sort of impersonation too
rather than interactive, but as long as the user has interactive login
rights on the server where this runs, that should still work.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Ron" <Ron@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:92143117-C7E8-46FA-B1EE-B68670FCB84C@xxxxxxxxxxxxxxxx
>I have an application that ran fine under Server 2003 x32 and now has
> intermittent failures under Windows Server 2008 x64.
>
> The application allow users to reset their password in the active
> directory
> when the have lost their password entirely.
>
> When the problem occurrs, no error is returned, but the password is not
> reset.
>
> I suspect that the problem may be with the impersonation, but I have > not
> been able to locate any documentation on the correct way to accomplish > an
> impersonation under Windows Server 2008. Any help would be appreciated.
>
> There was no change to the domain when we started using Windows Server
> 2008
> and the website appears to run just fine on the old Windows Server 2003
> machine.
>
> One issue that I am not sure of…the impersonator uses the advapi32.dll > and
> kernel32.dll libraries. Note that the machine is a Windows Server 2008 > x64
> machine.
>
> Basically it does the following.
> 1) Impersonate a user with password set access to the OU that contains > the
> user.
> 2) objUSer.AuthenticationType = AuthenticationTypes.Secure
> 3) objUSer.Invoke("SetPassword", strPassword)
> 4) objUSer.CommitChanges()
> 5) Undo Impersonation
>
> Impersonation is by:
> Public Function ImpersonateUser( _
> ByVal Domain As String, _
> ByVal userName As String, _
> ByVal password As String) As Boolean
> Dim tempWindowsIdentity As WindowsIdentity
> Dim token As IntPtr = IntPtr.Zero
> Dim tokenDuplicate As IntPtr = IntPtr.Zero
> Dim iError As Integer
> Dim ret As Integer
> Dim strErr As String
>
> Try
> If RevertToSelf() Then
> iError = LogonUserA(userName, Domain, password,
> LogonType.LOGON32_LOGON_INTERACTIVE, _
> LogonProvider.LOGON32_PROVIDER_DEFAULT, token)
> If iError <> 0 Then
> If DuplicateToken(token, 2, tokenDuplicate) <> 0 Then
> tempWindowsIdentity = New WindowsIdentity(tokenDuplicate)
> impersonationContext = tempWindowsIdentity.Impersonate()
> If Not impersonationContext Is Nothing Then
> ImpersonateUser = True
> Else
> ret = Marshal.GetLastWin32Error()
> strErr = "No Context returned:" & ErrorMessage(ret)
> Throw New ApplicationException(strErr)
> End If
> Else
> CloseHandle(token)
> ret = Marshal.GetLastWin32Error()
> strErr = "Failed To Duplicate Token:" & ErrorMessage(ret)
> Throw New ApplicationException(strErr)
> End If
> Else
> ret = Marshal.GetLastWin32Error()
> strErr = "LogonUser failed:" & ErrorMessage(ret)
> Throw New ApplicationException(strErr)
>
> End If
> Else
> ret = Marshal.GetLastWin32Error()
> strErr = "RevertToSelf Failed:" & ErrorMessage(ret)
> Throw New ApplicationException(strErr)
> End If
> If Not tokenDuplicate.Equals(IntPtr.Zero) Then
> CloseHandle(tokenDuplicate)
> End If
> If Not token.Equals(IntPtr.Zero) Then
> CloseHandle(token)
> End If
>
> Catch appEx As ApplicationException
> sError = appEx.Message
> 'objErrorLog.WriteTOErrorLog(sLoginUserName, Err.Number,
> appEx.Source,
> appEx.TargetSite.Name, appEx.Message, appEx.StackTrace)
> ImpersonateUser = False
>
> End Try
>
> End Function
>



.

Relevant Pages

  • Windows Server 2008 impersonation.
    ... intermittent failures under Windows Server 2008 x64. ... I suspect that the problem may be with the impersonation, ... Dim tempWindowsIdentity As WindowsIdentity ... Dim ret As Integer ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Windows Server 2008 impersonation.
    ... You would just put the creds used for impersonation directly into the DirectoryEntry constructor. ... intermittent failures under Windows Server 2008 x64. ... Dim tempWindowsIdentity As WindowsIdentity ... Dim ret As Integer ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Windows Server 2008 impersonation.
    ... you don't need impersonation code for this. ... intermittent failures under Windows Server 2008 x64. ... Dim tempWindowsIdentity As WindowsIdentity ... Dim ret As Integer ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: SetPassword access denied
    ... That said, I think one thing worth pointing out is that in both cases here, your code is supplying credentials to the DirectoryEntry constructor. ... the identity of the current thread (established either via impersonation or using the process token without impersonation) is NOT the account that is used for performing remote activities in the directory. ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ...
    (microsoft.public.windows.server.active_directory)
  • Re: Impersonation headache
    ... These both sound like double-hop delegation issues. ... impersonation token that WIA creates cannot hop to another machine on the ... > Dim impersonationContext As WindowsImpersonationContext ... > Dim currentWindowsIdentity As WindowsIdentity ...
    (microsoft.public.dotnet.framework.aspnet.security)
Loading