Skip to main content

"You do not have permission to change your password"

I haven’t posted anything in a while, sorry about that. I’ll try to post more often. :-)

We had a call recently regarding users changing their expired password whilst logging on to a computer attached to another domain. Unfortunately or fortunately, depending on which way you look at it, almost all of our clients are Windows XP, so our initial response to these sort of queries is to ask the Local IT Administrator to fully patch the client experiencing the problem. Taking an XP client to SP3 usually solves most of the problems listed on TechNet for this particular error.

Unfortunately, patching didn’t work in this instance, and we weren’t sure why this was happening, so we logged a call with Premier Support. One of the articles we had missed in our initial investigations was highlighted to us by Microsoft -

The article explained that we needed to reverse a change that was made on our Domain Controllers by the application of Server 2003 Service Pack 1 that had cleared the list of Pipes configured on the “Network Access: Named pipes that can be accessed anonymously” property in our Default Domain Controllers Policy. The article explains that we should enable the new defaults introduced in Windows Server 2003 SP1 (COMNAP, COMNODE, SQL\QUERY, SPOOLSS, LLSRPC, BROWSER, NETLOGON, Lsarpc, samr) for that property to restore the ability for users logging on to a computer from another domain to change their password when it has expired.

The reason this happens is because an expired password prompt on a client appears before a user has actually logged on. To change the password at this point, a computer from another domain has to open a null session with a domain controller in the domain of the user, using an Anonymous connection to those named pipes that were removed with the installation of SP1.

You may ask, why I’m posting about this when it’s already detailed in the TechNet article above. Not entirely happy that we would enable anonymous access to all of the Named Pipes listed in the article, we asked Microsoft to identify specifically what Pipes we needed to enable to resolve the issue regarding changing expired passwords from computers on other domains. They came back to us with only two Pipes that needed to be enabled, LSARPC and SAMR.

These Named Pipes that allowed null sessions, have specific vulnerabilities and exploits that exist, hence the reason for their removal by Microsoft. In the end we decided not to make the change and migrate the affected computers to the users domain, but i thought it would be interesting to share that you didn’t need to allow anonymous access to all the named pipes detailed in the article above, if you need to make this work, you can now do it with as little risk as possible.


Popular posts from this blog

Convert Linked Mailboxes to User Mailboxes in Bulk

My organisation has gone through a massive migration project to unify Active Directories and Exchange organisations. As a result of these migrations a lot of mailbox migrations have resulted in a lot of mailboxes ending up as linked mailboxes even though their not. The official TechNet article on this explains how to disconnect the mailbox and re-attach it to the user account correctly as a user mailbox. Another way to make this appear to be corrected is to manually change the “Recipient Type” AD property on the affected mailboxes. This though, is unsupported. Using the official method from Microsoft results in the loss of any specific mailbox information such as SMTP, x400 & x500 addresses, mailbox sizes and any other individual mailbox settings. Only e-mail addresses and mailbox sizes were important to me (I must admit, I forgot about mailbox sizes at first). I came up with the script below that would properly con

Upgrading Exchange 2007 Clusters to SP2 – Workaround

I posted last month about a problem delegating installs of Exchange 2007 SP2. Delegated Admins will receive an error message stating the following… You must be a member of the 'Exchange Organization Administrators' or 'Enterprise Administrators' group to continue. Have been looking into the issue and have had a case open with Microsoft. Turns out that you only get this issue on a fully patched server. If you try upgrading or installing as a delegated admin on a fresh install of either server 2008 or 2003 you don’t see the problem either with Exchange SP1 or SP2. I haven’t had time to identify exactly what patch causes this yet, if I’ll bother at all. If you have patched your server though, MS came up with this workaround. Disable update checking for the BPA by heading into the registry and HKCU\Software\Microsoft\Exchange\ExBPA and either creating or modifying a DWORD named “VersionCheckAlways” and set it to ‘0’ Copy the installation files to a local drive and replace S

Creating a Windows PE 3 Bootable USB device

I’ve used Windows PE for a long time. And I’ve grown to love it. It’s an extremely useful tool, not just for OS installation, but for diagnostics. Since there’s a version of WinPe for x64 & x86 (& itanium) I like to keep both x64 & x86 on my USB stick. Essentially copying the each version to the root of the USB stick as needed. Meaning at any one time I have three copies of WinPE on my USB stick. Other applications I copy directly to my USB stick, so that I don’t have to remount the image every time i need another application added. Shortly after Windows 7 was released came a new version of WinPE, WinPE 3.0 on the Windows Automated Installation Kit. Preparing the USB stick. You’ll need to prepare the USB stick. To do this open a command prompt using Run As Administrator and use the following commands. diskpart list disk select disk 7 clean create partition primary select partition 1 active format quick fs=fat32 assi