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?

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?

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.

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.

I had a question today where the user wanted to know how to delete an SSL Certificate, so I thought that I would quickly add this How to! Article for your reference.
WHY WOULD YOU WANT TO DELETE A CERTIFICATE?
1. If an incorrect certificate was …

I was supporting a handful of Windows 2008 (non-R2) 2 node clusters with shared quorum disks. Some had SQL 2008 installed and some were just a vendor application that we supported. For the purposes of this article it doesn’t really matter which so w…

This tutorial will walk an individual through the steps necessary to install and configure the Windows Server Backup Utility.
Directly connect an external storage device such as a USB drive, or CD\DVD burner:
If the device is a USB drive, ensure i…

This tutorial will walk an individual through setting the global and backup job media overwrite and protection periods in Backup Exec 2012.
Log onto the Backup Exec Central Administration Server. Examine the services. If all or most of them are stop…