Posts Tagged 'windows server 2008 R2'

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

Published January 20, 2012 Active Directory , Active Directory Management Gateway Service , Microsoft Active Directory , PeopleProvision , Powershell , Windows 7 , Windows Server 2008 , Windows Server 2008 R2 Leave a Comment
Tags: , , , , , , ,

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

Published December 15, 2011 Active Directory , Active Directory Management Gateway Service , Microsoft Active Directory , PeopleProvision , Powershell , Windows 7 , Windows Server 2008 , Windows Server 2008 R2 Leave a Comment
Tags: , , , , , , ,

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.

Edit 64-bit File with a 32-bit Editor on Windows 2008 64 or R2

Published October 31, 2011 Windows Explorer , Windows Server 2008 , Windows Server 2008 R2 Leave a Comment
Tags: , , , , , ,

I worked recently on a project where I needed to make a change to an IIS 7.5 configuration file on Windows Server 2008 R2. While trying to edit the file, I kept getting an error message trying to use my default text editor, TextPad.

C:\Windows\System32\inetsrv\config\administration.config was not found.
File Not Found

File Not Found

I also noticed that Windows Explorer rendered the files on the file system with some strange lock icons I don’t recall seeing before.

Strange File Lock Icons

Strange File Lock Icons

After several attempts to open the files for editing in TextPad, I began searching the interwebs looking for an answer and stumbled across a post that helped me break through. Rick Strahl mentions an issue using a 32-bit application to edit certain files in the System32 folder.

Since all Server 2008 R2 flavors run as a 64-bit OS, I decided to try using the native Notepad installation instead of my 32-bit TextPad editor. Wallah! The file opened just fine and I was able to make my changes and move along once I got past the annoyances of Notepad…but I digress. ;-)

So remember that if you see a strange lock icon or you try to use a 32-bit editor to open files on a 64-bit platform, things may not work out. Try opening the file in Notepad to see if that will work to get you by while you get a 64-bit editor installed.

Addressing the PowerShell Script Error for AuthorizationManager check failed

Published October 21, 2011 Powershell , Security , Windows Server 2008 , Windows Server 2008 R2 2 Comments
Tags: , , , , , , , ,

I was recently working in a client environment and running a PowerShell script that calls a bunch of other scripts on the file system using the dot sourcing technique. The scripts run fine in a number of other customer environments as well as our test environment but I kept seeing an “AuthorizationManager check failed” when several scripts were called from the main script.

I messed around with permissions for while and then drank a few beers to see if things with PowerShell were now better. The PowerShell wasn’t better but I felt okay with the addition of the beers. I still needed to find a solution, though, and decided to approach this fresh after a few days (and possibly more beers!).

With a fresh approach, I found a simple post that sprung the entire solution for me. I had used Internet Explorer (I know, I know…I was on a Windows Server 2008 R2 box in a customer environment…not much choice there) to pull down a few PowerShell files over HTTP from our website. Guess which files I pulled down using IE. Yep! You betcha…the very script files that all failed when the AuthorizationManager calls ran! Needless to say, you should unblock PowerShell script files downloaded using IE, even if they’re from your own web site!

The key is to unblock files that you’ve downloaded so PowerShell will run them!

Check out the screen shot below to make the simple unblock from the PowerShell script file properties. Just right-click the file and choose Properties from the context menu.

Windows File Properties - Unblock File

Windows File Properties - Unblock File

PowerShell Errors Connecting to Active Directory Domains and Forests

Published October 13, 2011 Active Directory , Microsoft Active Directory , Powershell Leave a Comment
Tags: , , , , , , ,

I needed to work with data from a child domain in our test environment so I tried to access the child domain using the Get-ADDomain cmdlet from the Active Directory module for PowerShell. When that operation failed, I attempted to map a PS drive to the child domain instead, but this operation failed as well. However, both the Get-ADDomain and New-PSDrive cmdlets work fine in the root domain of the forest.

I noted the following errors messages with each cmdlet and the New-PSDrive error message holds the key to solving the problem.

Get-ADDomain : Cannot find an object with identity: ‘child.root.local’ under: ‘DC=root,DC=local’.

New-PSDrive : Unable to contact the server. This may be because this server does not exist, it is currently down, or it does not have the Active Directory Web Services running.

Resolution

The New-PSDrive error message best exposes the source of the problem. I know the server and domain exist so that’s not the problem. Instead, the Active Directory module cmdlets cannot contact the domain because it does not have at least one Windows Server 2008 R2 domain controller in the domain or at least one instance in an AD LDS configuration set that is running on a Windows Server 2008 R2 server.

Aha! My child domain does not have any Server 2008 R2 DCs or LDS instances. So how can I address this? There are a few options.

  1. Install the Active Directory Management Gateway Service on at least one non-2008 R2 domain controller, including Server 2003 and 2008. This provides a Web service interface to Active Directory domains and instances of Active Directory Lightweight Directory Services (AD LDS) or Active Directory Application Mode (ADAM) that are running on the same server as the Active Directory Management Gateway Service.
  2. Promote an existing Server 2008 R2 member server in the domain to a domain controller.
  3. Upgrade at least one DC in the domain to Server 2008 R2.

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

Published September 30, 2011 HTML , IIS , Windows 7 , Windows Server 2008 , Windows Server 2008 R2 1 Comment
Tags: , , , , , ,

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.

A Replacement for IISADMPWD in IIS 7

Published September 29, 2011 Active Directory , IIS , Tools , Windows Server 2008 , Windows Server 2008 R2 2 Comments
Tags: , , , , , , , ,

Many organizations have employed Microsoft’s IISADMPWD tool to allow password changes in Active Directory for web applications. Originally intended as the way to change passwords for access in Outlook Web Access (OWA), IISADMPWD became quite a useful solution for any organization that wanted to delegate access to AD password changes via a web application.

With the release of IIS 7 and its architectural and security changes from previous versions of IIS, there are certain situations where the old IISADMPWD will not work. In fact, Microsoft doesn’t even support IISADMPWD on IIS 7 and later although some organizations have been able to deploy it in an unsupported fashion.

The main situation where IIS 7 behaves differently from previous versions of IIS is when a user needs to change her password and the “User must change password at next logon” flag is set in Active Directory. In this situation, we’ve not found a way to authenticate a user with either Windows or Basic authentication in IIS and the old IISADMPWD tool cannot meet the requirements to allow the password change for users with this flag set. This is problematic since the scenario where a user needs to change her password after an administrative reset is very common.

Web Active Directory has developed a replacement for IISADMPWD that uses anonymous authentication to work around the IIS 7 authentication issue when the ”User must change password at next logon” flag is set for a user. Tomorrow we will take a closer look at the architectural approach and a new tool that WebAD developed to help in this scenario.

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

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

Published September 2, 2011 Active Directory , Development , IIS , Microsoft Active Directory , Windows 7 , Windows Server 2008 , Windows Server 2008 R2 Leave a Comment
Tags: , , , , , , , , , , , ,

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!

IISADMPWD: IIS 7 Authentication with “User must change password at next logon” Flag Set in Active Directory

Published July 25, 2011 .NET , Active Directory , ASP.NET , Exchange , IIS , Microsoft Active Directory , Tools , User Experience , Windows Server 2008 , Windows Server 2008 R2 2 Comments
Tags: , , , , , , , ,

We’re working with a customer to replace the Microsoft IISADMPWD tool the customer uses to allow Active Directory password changes in their hosted software offering. This tool, a legacy ASP application that runs on IIS 5 and 6, has been around for a while to allow AD password changes using OWA, Outlook Web Access. Beginning with IIS 7 on Windows Server 2008, support for IISADMPWD was dropped and users can now change passwords directly in OWA on Exchange 2007 and 2010 without IISADMPWD.

But what if you’re in a situation like our customer and you use IISADMPWD to change passwords in your Active Directory credentials store? There are several ways to port IISADMPWD to IIS 7 and Server 2008 but these are outside the context of Microsoft technical support. Plus, IISADMPWD does not work on IIS 7/7.5 when a user account has the “User must change password at next logon” flag set in Active Directory. Why?

As far as I can tell from experimenting in our test environment and searching the web, IIS 7 and later versions do not allow a user to access a site secured with Basic or Windows authentication if the ”User must change password at next logon” flag is set in AD. IIS 7 was completely re-architected from previous versions and the “back door” ISAPI DLL access that previously allowed this feature has now been turned off since its primary reason to exist—resetting AD passwords for OWA—now is properly built into OWA.

There is a pretty simple workaround if you want to still use a tool like IISADMPWD. Web Active Directory provides several AD management tools that change passwords and we have a replacement for IISADMPWD that runs on IIS 7 and later. The tool uses Anonymous IIS authentication but you can pre-populate the username for changing a password using the URL query string or passing the username value in a custom HTTP header. Using Anonymous authentication allows the application to run without asking the user for credentials and all AD password changes are securely executed under a Windows service account security context.

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 33 other followers

Web Active Directory Products

Download PDF product data sheets: