Is Active Directory user account delegat used on the same computer

Hi,
In the User Properties for Active Directories there is a tab for 'Security.'
In that Security tab there is a check box for "Account is sensitive and cannot be delegated."
As I understand it, if this box is checked, then other accounts on other computers can not impersonate this account; but what about on the same computer.
My question is this, will another account or another application on the same computer be restricted if this box is checked?

For example, suppose we have two domain accounts:
DMN\GeoAdmin
DMN\GeoMapServices .

Suppose that a scheduled task on a Win2K8r2 machine uses DMN\GeoAdmin to start a scheduled task, and that scheduled task starts a PowerShell session that runs a script on the same machine that manipulates a third party Windows service on the same machine; and that Windows service uses the DMN\GeoMapServices.

Normally, the scheduled task that runs with DMN\GeoAdmin is able to successfully run the PowerShell script that manipulates the DMN\GeoMapServices .
If the "Account is sensitive and cannot be delegated" box is checked for DMN\GeoMapServices' user properties, might that prevent the PowerShell script from manipulating the Windows service as was previously done?

Would it make a difference if the Windows service was on a different machine? For instance, what if a regular user like DMN\regUser, from his Win7 computer wanted to access a service that runs under DMN\GeoMapServices on the Win2K8 server?

What if the IIS account like, IIS_IUSRS wanted to impersonate the DMN\GeoMapService?

Would checking the "Account is sensitive and cannot be delegated" box for DMN\GeoMapService disrupt any of those activities?
XTOAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
David Paris VicenteConnect With a Mentor Systems and Comunications  Administrator Commented:
If the account is using accross network the restrictions will be applied, if you are directly use the account/computer the restrictions will no be applied.

Ex: If you are using an accoutn with special permissions directly (no impersonation in place), you can do everything define for that account,  but if your account is going to be impersonated and you have restrictions that the account can´t be impersonated  when the impersonation contact AD will receive the status that the account can´t be impersonated and service will fail locally or across network.

Here are an explanation how the  Constrained Delegation and single sign onKerberos Protocol Transition and Constrained Delegation

I hope this can help you.
Regards.
0
 
David Paris VicenteSystems and Comunications  Administrator Commented:
That option is mostly used for guests or temporay accounts and cannot be assigned for delegation by another account.

So if I understood your question, and my advice is not use that option fro accounts that you want to use in services or impersonations.

Regards.
0
 
XTOAuthor Commented:
Thank you granwizzard.

The order to do this is coming from upper management from a bigger company that acquired our company. I need to be able to make a logical case for not doing this. Could you give me some technical details based on the scenarios above?

So, if DMN\GeoMapService has that option clicked, does that mean that DMN\GeoMapService:
1. Can not be impersonated by another service
or
2. Can not impersonate another service
or
3. Both?

Also, does that option cause restrictions only across networks, or does it also cause restrictions on the same computer?
0
 
David Paris VicenteSystems and Comunications  Administrator Commented:
Hi XTO,


1.Constrained delegation enables impersonation without having the user's credentials or authentication token.

2.In a more typical meat-and-potatoes unconstrained delegation scenario, whether it is windows integrated authentication or forms authentication, having delegation access to a user's authentication token is very powerful. That literally means that token can be used to impersonate that user to access any network resource. Anyone involved in that process, such as a developer, could use that in a nefarious way to obtain unauthorized access.

In both examples, if the box is checked for "account is sensitive and cannot be delegated", these are not security issues. It's also possible to architect a system/feature where these capabilities do exist, but are tightly controlled.

That box should be checked for administrative accounts, such as members of the Enterprise Admins group, because (hopefully) those accounts rarely need to use applications that require impersonation. It is also be a good idea for senior executives who have access to sensitive information, such as a CIO, COO, head of Finance/Treasury, etc.

So the bottom line is, Microsoft provided that checkbox and the accompanying warning for a very good reason, and it should not be dismissed or taken lightly unless it can be demonstrated that a particular scenario does not have undesirable risk exposure, or some compensating control. This usually involves vetting by some qualified person(s) that are not involved in the actual implementation or development of an application or system.


I hope this could help you understand the concept.

Sorry if I couldn´t explained the concept in a better way.

Regards
0
 
XTOAuthor Commented:
Hi granwizzard, Does constraining delegation cause a restriction on
1. Both across the network and on the same computer
or
2. Only across the network?

Thanks.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.