3

We're testing out Windows 10 Creators Update (Build 15063) here. So far this is the only unsolvable issue we've encountered.

This issue is exclusive to Creators: identical Users and GPO's work fine on Windows 10 Anniversary (Build 14393), and Windows 7 SP1, all with the latest windows updates run

We have two domains here, with no trust relationship between them. To get one particular drive mapped, we add the username and password in using group policy preferences (Used to be done with a login script, but changed to support user account control) to cross authenticate. Here's a (redacted) screenshot of the preference options in GPO:

M Drive Error

When the policy runs on 10 Creators, the other's drive map, but the M: Drive is not there. Looking at the event viewer gives this error:

The user 'M:' preference item in the 'GPO Drive mappings {C65A2351-20C1-42D4-BF2B-AE604CD9DC0A}' Group Policy Object did not apply because it failed with error code '0x80090005 Bad Data.' This error was suppressed.

The user can manually map the same drive, adding the other domain's credentials when prompted. They can also do it using the net use command.

I've tried googleing around GPO Mapping, Windows 10 Creators, and 0x80090005 Bad Data, but not found anything relevant.

Improve this question
7
  • 1
    Saving credentials in a GPO creates a security vulnerability.
    – I say Reinstate Monica
    May 13, 2017 at 3:51
  • Less so than having them in a plain text Login script. What other options are there for Cross domain authentication that don't have a trust relationship?
    – Dave
    May 13, 2017 at 14:12
  • 1
    Obviously domain-trust is the proper solution, but if that's not an option and you don't want to expose credentials, there's the painful option of having giving users identical usernames and passwords in both domains. Not trying to hijack your question though, just wanting to point out the exposure created by putting credentials in GPOs which are accessible to all domain workstations.
    – I say Reinstate Monica
    May 13, 2017 at 14:33
  • Thanks for the input, Twisty. If it was a smaller amount of users, I'll look at matched accounts, but due to the numbers and password policy, it would get quickly out of hand. Know it's less than idea, but at the moment, I'd settle for feature parity between 7/8/Anniversary and creators.
    – Dave
    May 15, 2017 at 9:44
  • At a suggestion found on the web, I unticked the Reconnect button for the M: Drive in GPO: It has not made a difference to the symptoms
    – Dave
    Jun 23, 2017 at 12:25

2 Answers 2

Reset to default
2

So, I'm one of the 10 or so GP MVPs from Microsoft.

In short: This isn't supported. @Twisty is right: This security hole was closed by modern GPMCs and not permitted anymore. The KB:

https://support.microsoft.com/en-us/help/2962486/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevati

I have two possible workarounds:

1: Try REMOVING the trailing \ at the end. So, the correct UI would be

\\server\share and not \\server\share\

2: Without testing it though, a workaround might be worth testing. Try the policy setting (on ONE MACHINE using GPedit.msc):

Computer | Admin Templates | System | Group Policy | Allow cross-forest user policy and roaming user profiles

Just set ONE machine locally with that policy.. (GPedit.msc LOCALLY on one Win10 1703 / creators edition box).. dont go crazy and enable it everywhere yet.

Then, reboot and re-test.

Did that work?

If yes, yay. If not.. that's all I have to offer.

-Jeremy Moskowitz, 15-year Group Policy MVP from GPanswers.com

Improve this answer
2
  • Thanks for the answer there, Jeremy. I'll try both of those suggestions as a short term fix. Also looking at storing the passwords for the share in Windows Credential manager, then using GPO mapping without username and passwords.
    – Dave
    Jul 27, 2017 at 8:46
  • Hi, Jeremy. Unfortunately, this didn't work, but I've come up with a horrific workaround
    – Dave
    Sep 21, 2017 at 12:33
2

I came up with a work-around, but it's really not pretty: The Old is New again.

Background: We moved from using a simple CMD login script to GPO mapped drives when we moved from Windows XP to Windows 8, and User Account control stopped mapped drives working, due to standard and admin tokens conflicting (See TechNet note here)

As Creators update removed the ability to save credentials in group policy, and I couldn't get group policy to add the details to the local Credential Manager (Tried using this script, but looks like it won't work with User Account Control and allowing unsigned scripts), I turned on the EnableLinkedConnections registry key, and mapped this one drive using the old skool net use command.

Full Details:

Step 1 Create a new WMI Filter specifically to detect Creators update (This reduces the lower security footprint to only the machines that need it):

select * from Win32_OperatingSystem WHERE Version like "10.0.15063%" AND ProductType="1"

Step 2 Add the WMI Filter to a new GPO, which:

  • Sets the DWORD regkey SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLinkedConnections to 1
  • Add a cmd Login script in the Sysvol folder

GPO Setup

Step 3

In the login script, add the following code:

net use m: /delete /y
net use m: \\[Server]\[Share]\ /user:[Server FQDN]\[Username] [Password] /PERSISTENT:YES

As a sidenote, this only fully affects users that are Local Administrators on Creator Update systems: If you have the option to take their administrator rights away, you can take out the EnableLinkedConnections step in the GPO, which improves the security for the other GPO mapped drives (The drive in question will still have a plaintext password script, though), but I'm working with a Legacy Program which needed the cross domain mapping AND Admin rights to work.

Know this is less than ideal as it goes back to the XP days of having a plaintext password in a not too hard to locate file, but it's the only workaround I've found so far to this Creators Update issue: I have a feeling programming Credential Manager via GPO or a PowerShell login script is the correct answer, but I just can't get it to work: If anyone can improve on this answer by getting that way to work, then that's what I'll go for.

Improve this answer
1
  • 1
    Thanks for sharing this, it worked for me. Ironically, this is the solution that I've tested years ago and was rejected by the management, due to having the password exposed in plain text. Ended up sticking to Group Policy Preferences and using a cPassword hash tool to create a cPassword string based on plain text. But obviously, this is now not working for me on Server 2019...
    – shadowz1337
    Dec 10, 2019 at 6:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .