Archive for the 'Windows 7' Category

Active Directory Management Gateway Service (ADMGS) Errors and McAfee Anti-Virus Software

I posted last month about an issue with the Active Directory Management Gateway Service (ADMGS) on Windows Server 2008. The ADMGS  (which runs as the Active Directory Web Services, ADWS, service) allows you to use the Active Directory module for Windows PowerShell to manage AD remotely in domains where there are no Server 2008 R2 domain controllers running.

I saw the following error messages when running the “import-module activedirectory” command in PowerShell.

The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.

I was able to diagnose the ultimate cause based on my previous post but still was receiving errors even after mucking with NTFS directory permissions for temporary .NET files. I finally had the idea to check on anti-virus software to see if that was blocking the communication. Wallah! The domain controller had anti-virus software installed (in this case it was McAfee) and as soon as I adjusted the AV software configuration the AD connection was allowed. The log entries below help pinpoint the cause.

1/19/2012        5:22:05 PM        Blocked by Access Protection rule         NT AUTHORITY\SYSTEM        C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe        C:\Windows\TEMP\t0sggpq5.dll        Common Maximum Protection:Prevent creation of new executable files in the Windows folder        Action blocked : Create

1/19/2012        5:22:07 PM        Would be blocked by Access Protection rule  (rule is currently not enforced)         NT_DOMAIN\SRS-RMRES2-02$        System:Remote        C:\Windows\SYSVOL\domain\Policies\{1C9122E4-78CD-4001-A2E7-8BBCA348C893}\GPT.INI        Anti-virus Outbreak Control:Block read and write access to all shares        Action blocked : Read

So make sure to check your AV software if you have this kind of problem…it just might be the key to a solution!

Diagnose Active Directory Management Gateway Service (ADMGS) Errors

I recently worked on a Windows Server 2008 system with the Active Directory Management Gateway Service (ADMGS) installed. The ADMGS allows you to use the Active Directory module for Windows PowerShell to manage AD remotely in domains where there are no Server 2008 R2 domain controllers running.

The ADMGS service (which runs as the Active Directory Web Services, ADWS, service) worked fine for several months but decided to begin having problems recently. We saw the following error message when running the “import-module activedirectory” command in PowerShell

The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.

Needing to troubleshoot the source of the issue, I messed with the IncludeExceptionDetailInFaults attribute in the C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe.config file. However, this proved to be a daunting task for a number of reasons so I moved on to another solution. (View an example of setting the IncludeExceptionDetailInFaults attribute.)

Finally, I located a post that helped break this open. Adding a couple of debug keys in the <AppSettings> section of the config file allowed me to log the ADMGS error on the server and diagnose the real source of the error.

<add key="DebugLevel" value="Info" />
<add key="DebugLogFile" value="C:\Windows\Debug\adws.log" />

Use the following valid string values (not numeric values) for the DebugLevel value.This will add diagnostic info into the debug log at the DebugLogFile path you specify.

  • 0 – No logging
  • 1 – Error (this logs critical errors only)
  • 2 – Warn (this logs warning events as well as error events) – Recommended value to use unless you need full tracing
  • 3 – Info (verbose)

Once I set up debugging and restarted the ADMGS service, I got to the bottom of the problem with the error below and I can now address the permissions issue that is causing connection problems with the “import-module activedirectory” PowerShell command.

ActiveDirectoryWebServices: [xx/xx/2011 6:14:15 PM] [3] Get: Unhandled Exception System.UnauthorizedAccessException: Access to the temp directory is denied. Identity 'YOUR_DOMAIN\YourAccount' under which XmlSerializer is running does not have sufficient permission to access the temp directory. CodeDom will use the user account the process is using to do the compilation, so if the user doesnt have access to system temp directory, you will not be able to compile. Use Path.GetTempPath() API to find out the temp directory location.

A Workaround in IIS 7 for the “User Must Change Password at Next Logon” Flag in Active Directory

In yesterday’s post we looked at an issue with the IIS 7 architecture where Windows and Basic authentication fail when the “User must change password at next logon” flag is set for an Active Directory user. Microsoft engineered IIS 7 to deny access to users who have this flag set. This change from previous versions of IIS causes problems when you want to use tools like IISADMPWD to allow web application users to change their Active Directory password.

Web Active Directory looked at this situation and created a solution that allows you to bypass the issue in IIS 7. Understanding that the problem stems from the fact that IIS 7 denies access to users who need to change their password at the next logon, we took an approach to use Anonymous authentication in IIS  and avoid the denial issue.

The small web application we produced provides a logon screen and then checks the status of the “User must change password at next logon” flag before performing authentication against Active Directory. This allows you to provide a customizable logon form with instructions and your own branding instead of using the default browser pop-up dialog.

Best of all, if the user needs to change her password you can route the web application to the IISADMPWD replacement web app we also created. If the user does not have to change her password and the credentials check out, the application passes the authentication credentials down the way and everything proceeds as normal.

Contact Web Active Directory for more information about this solution and the IISADMPWD replacement tool for IIS 7.

Adding Windows Computer Accounts from Active Directory to NTFS ACLs to Control Permissions

When writing web applications, you often must grant permissions to an application to do something on other machines in a Windows domain or forest. IIS 6, 7 and 7.5 all allow you to configure IIS application pools to run under specific, rather secure identities like NETWORK SERVICE and the Application Pool Identity.

When accessing resources over the network using these identities, remember one simple rule: You must ensure to search computer accounts in Active Directory when granting access to a resource. We commonly add a computer account to an NTFS ACL to allow a web application to create directories on a remote machine. Computer accounts take the form of <DomainName>\<ComputerName>$ when accessing resources over the network and make sure you include the dollar sign ($) on the end of the computer name.

Tip

When locating the security principal (account) to add to the ACL, make sure you search computers in addition to the standard users, groups and built-in security principals. If you don’t do this you will pull your hair out trying to figure out why Active Directory can’t resolve your computer account name and let you assign permissions.

The following screen shots illustrate the bad and the good on Windows Server 2008 R2 for adding a security principal to a NTFS ACL.

The BAD

This will drive you nuts because AD can’t resolve the computer account name. Why? Because you’re not searching computers…only users, groups and built-in security principals.

Computer Name Resolution Failed

Cannot resolve the computer name because AD is not searching computer objects

The GOOD

Mucho better when we add computers to the object types to search!

Computer Name Lookup

Change the Object Types to include computers

Now you’re in business!

Computer Name Resolution Success

Computer account resolves now!

PowerShell Hosting in ASP.NET: Resolving Errors with PowerShell Set-ExecutionPolicy

One of the great innovations in Windows PowerShell is the ability to host the PowerShell run-time environment in any number of run-time hosts. We use this capability to host PowerShell in an ASP.NET web application process for our PeopleProvision solution. Everything works great once you get over a couple of big security hurdles.

  1. File SomePowerShellFile.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see “get-help about_signing” for more details.
  2. Access to the registry key ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell’ is denied.

Many sources on the web document exactly what is going on with these error messages. Basically, Microsoft architected PowerShell and Windows Server 2008 R2 so the operating environment is protected from unauthorized PowerShell script execution. This is a good thing. However, it’s not so good when you need to run your own PowerShell script in a host other than the standard PowerShell command shell. You can’t just right-click and choose Run as administrator when your PowerShell host environment doesn’t have a GUI. In a scenario where you host PowerShell in an ASP.NET process, how do you get around this?

It turns out that you can securely run scripts on your system by changing the PowerShell execution policy. In your script, include a command to set the execution policy to an acceptable level for your needs. For example, the command below allows local scripts and signed scripts from the Internet (RemoteSigned policy) to run only in the current PowerShell process (Process scope). This is a great way to run your trusted scripts in an ASP.NET process without opening up tons of security holes.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

After you add this to your script, save the script and then try to run your ASP.NET application. If you see the following error then you might need to restart IIS (or at least unload the application pool by stopping and starting the web site) to get your changes to take effect.

Access to the registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell' is denied.

That should be all you need to safely execute your PowerShell scripts from an IIS application pool. Check out the PowerShell Set-ExecutionPolicy cmdlet documentation for more options to set the appropriate PowerShell execution policy for your needs.

Microsoft Problem Steps Recorder for Windows 7

If you are a Windows 7 or Windows Server 2008 user, this utility might be useful to you.  Problem steps recorder allows you record the activities leading up to a problem, then save that to a mht file that you can send to support.  If you have an error on an IIS application (yellow screen) then it will even copy all that information out as text and put it as part of the capture.  I like this utility because it’s easy for the user and useful for support…in fact I’m not only a fan, I’m a user of it!

http://technet.microsoft.com/en-us/windows/dd320286.aspx

http://blogs.technet.com/appv/archive/2010/04/12/document-sequencing-on-windows-7-with-the-problem-sequencing-steps-recorder.aspx

For more information contact us at www.webactivedirectory.com, or call us at (+1) 800-747-3565


Slipstick Systems Outlook and Exchange Solutions Center
Utilities, how to's and other solutions for Microsoft Outlook and Microsoft Exchange users, administrators and developers

Share this blog

Facebook Twitter More...

Enter your email address to subscribe to WebActiveDirectory blog via email.

Join 243 other followers


Follow

Get every new post delivered to your Inbox.

Join 243 other followers