Creators Update Stops Cross Domain GPO Drive mapping working ('0x80090005 Bad Data)
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:
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.
Dave2 Answers
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:
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
Jeremy Moskowitz
CommunityI 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
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.
User contributions licensed under CC BY-SA 3.0