Since Windows Server 2012, deploying DirectAccess became so simple, too simple (It’s by design now ). We just need domain admin privileges to perform the operation. That’s far away from a least privilege level. From a security guy point of view we should be able to deploy DirectAcecss with the least privileges as possible. fasten your seatbelt and take an aspirin, you’re welcome to that journey.
Let’s start easy
Let’s see how to perform a DirectAccess deployment with limited set of privilèges with a DirectAccess infrastructure based on Windows Server 2012. Starting point, this TechNet section :
According to this documentation, its possible and even documented :
- GPOs must exists before configuration activation
- User activating DirectAccess configuration must have “Full GPO permission” on created GPOs
- GPOs should be linked but it’s not mandatory
I provided all theses detailed information to the Active Directory team. I was ready to deploy DirectAccess for my customer. That’s now that problems appears. First problem located in the Remote Access Management Console. I logged onto my URA server with an account having the following privileges :
Local administrator level of the URA Server
Full control permission on GPO “GPO DA CLIENT”
Full control permission on GPO “GPO DA SERVER”
OK, it’s not a problem, just a warning. Technically speaking, my user account performing the operation have no delegation to create and manage WMI filters in group policies for my Active Directory Domain. Could it be a problem? No, unless you need to use the “Enable DirectAccess for mobile computers only” Option. In my case, I don’t need this privilege.
I follow my path into DirectAcecss configuration without problem until activation process :
Technically, the wizard cant create GPOs with default name using my least privilege account. We will use the change link to see that deeper.
Simple problem and simple solution. The wizard try to create DirectAccess GPOs with default names. Because my account have least privileges, it’s not possible. Let solve this minor problem with the browse button and select our pre-existing GPOs.
One problem closed, a new one arise. It could be so simple. Here again, it’s just a warning. In my case, the wizard is unable to link my GPOs at the root of the Active Directory because my account does not have required privileges for that. This is only a warning. I will have to ask the Active Directory team to link my GPOs. From a security guy point of view it’s a good thing.
Until now, deploying DirectAccess with a least privilege account seems to be an easy thing. In illustration bellow I can the that the red cross icon was replaced with a simple warning. Let’s apply this configuration and celebrate a new successful DirectAccess deployment.
Ouch. Congratulations will have to wait. We have a major problem here.
Is there a doctor in the place?
Yes I need a doctor for that (now your aspirin should be useful). How is it possible to have a denied access error to a group policy witfor witch we have a “Full control” permission on a GPO. I need a doctor, the doctor with his tool. Doctor, would you lend my your sonic screwdriver?
Let’s start with a small tip from the doctor, with the help of his sonic screwdriver. Let’s grab the Powershell command that generated this error.
And see what it look like in PowerShell mode.
It seems to be a permission problem on the GPO, there is no doubt about it. I asked the Active Directory team to verify permission on the GPO. They confirm the “Full control” permission on the GPO. That’s strange because the wizard did not warn me about that.
That’s here begin the twilight zone
It’s the twilight zone because here what we have in the Group Policy Management Console.
We can see my least privileges account having exactly the same permissions on the Group Policy “GPO DA Server”. If we have the same permission (and there is no deny permission), how could it be possible to have an access denied error. OK, let’s go deeper in the twilight zone and compare detailed permissions with the ”old school method”, before GPMC. Here is the “Domain admin group” detailed permissions :
And the “least privilege account”. OK, we have something strange.
In the GPMC console, both security objects objects have the same level of privileges but if we have a closer look at detailed permissions, it’s not the case. Let sum up :
Both security objects have the same permission level in GPMC but It’s not the case in the “Group Policy Editor”
“Domain Admin group” does not have “Full control permission” and my least privilege account have it
“Domain Admin group” does not have “Apply group policy permission” and my least privilege account have it
“Domain Admin group” have “special permissions” and my least privilege account not.
It’s interesting. My least privilege account seems to have more permissions than the default domain admin group. Why would I have an access denied error message in such situation? Let’s have a global view of the permissions with the “Advanced button”.
Doctor do you have an idea or do you escape?
That was a shock for me but the advanced view confirmed that my least privilege account have more permissions than the default domain admin group.
Doctor response was easy.
But let’s be more logic. Full control level is only a combination of permission on specific attributes. Let’s see the combination for the domain admin group.
So the only missing permissions are “Full control » and “All extended rights”. Let’s remove theses permissions for my least privilege account.
Now, both accounts have the same permissions. Let’s check that.
Almost perfect. We just need to remove the “Apply group policy permission”. Now we have exactly the same permissions for both security objects.
We will apply the same fix to the other group policy object. In GPMC, there is no change, even if we fixed some special permissions (if the doctor have an opinion about it, …).
Does my least privilege account had too much privilege? It’s not possible. Yes, but someday with a little help of bugs, … I removed permissions given to my least security account to solve the problem. And the problem is solved.
At last, we can see that because my least privilege account does not have permission on attribute “GPLINK” at the root of the domain the wizard cant link my GPOs. It’s normal, the Active Directory team did not linked my GPOs at the moment I generated my DirectAccess configuration.
This experience lead to multiple conclusions :
There might be something wrong with the URA activation process, code review might be necessary at this level
Don’t trust the first error message you see. In our case, I did not have exact required permission.
Stop watching Doctor who series
Doctor I give you back your sonic screwdriver.
BenoîtS – Simple and Secure by Design but Business compliant (And Doctor Who addict)