Trust user for delegation: AD access denied

Douglas E. Engert deengert at anl.gov
Tue Oct 30 09:44:35 EDT 2007



pher wrote:
> So what ? Back on Monday morning and I can now check the "Trust for 
> delegation" checkbox !!! I can also trust computers for delegation. All that 
> was impossible on Friday.
> ?????
> Is there any delay somewhere for the changes to propagate to all servers 
> involved in the delegation chain ?


With AD, yes there is some propagation delays between servers. I don't know the
details, but would suspect that policy on the AD controllers might take longer
then a password change.

Google for site:microsoft.com Active Directory replica replication

This seems to be prety good:
http://technet2.microsoft.com/windowsserver/en/library/1465d773-b763-45ec-b971-c23cdc27400e1033.mspx?mfr=true


> 
> Pierrot
> 
> 
> 
> "Douglas E. Engert" <deengert at anl.gov> wrote in message 
> news:mailman.17.1193423208.9118.kerberos at mit.edu...
>>
>> pher wrote:
>>> That's exactly the point where I have the problem: I did add the user 
>>> "Administrator" and the group "Domain Admins" into Group Policy 
>>> Management --> Default Domain Policy (of the domain controller) --> 
>>> Computer configuration --> Windows Settings --> Security Settings --> 
>>> Local Policies --> User Rights Management --> Enable computer and user 
>>> accounts to be trusted for delegation.
>>> I even rebooted the DC, one never knows (no problem, it's a test 
>>> environment).
>> OK, that is the bit to say you, as an Administrator, can update the 
>> userAccountControl
>> TRUSTED_FOR_DELEGATION bit in the acocunt of a server.
>>
>>> But I still cannot trust a user or a server for delegation, I always get 
>>> the same error "Your security settings do not allow you to specify 
>>> whether or not this account is to be trusted for delegation".
>> Do you get this message when trying to update an account, or do you get 
>> this
>> message when the user tries to delegate.
>>
>> If the later, do you have this situation:
>>> To restrict delegated authentication
>>> 1. In Active Directory Users and Computers, right-click the computer or 
>>> user account and select Properties.
>>>
>>> 2. On the Account tab, under Account Options, select the Account is 
>>> sensitive and cannot be delegated check box, and click OK.
>>>
>>> 3. You can also restrict delegated authentication to prevent the 
>>> delegation of sensitive user accounts by marking the account as not 
>>> enabled for delegation. Restrict delegated authentication for accounts 
>>> that are less secure or that are particularly powerful.
>>>
>> I thing the above is referring to the userAccountControl:
>>
>> • NOT_DELEGATED - When this flag is set, the security context of the user 
>> is not
>>   delegated to a service even if the service account is set as trusted for 
>> Kerberos delegation.
>>
>>> Pierrot
>>>
>>>
>>> "Douglas E. Engert" <deengert at anl.gov> wrote in message 
>>> news:mailman.14.1193322215.9118.kerberos at mit.edu...
>>>> pher wrote:
>>>>> Thank you, but I cannot change anything in the AD, although I am the 
>>>>> Domain Admin.
>>>>> I always get error messages "Your security settings do not allow you to 
>>>>> specify whether or not this account is to be trusted for delegation".
>>>> There is a Group Policy setting *on the Domain Controller* that must be 
>>>> changed.
>>>> It lists the users and groups of users that can set this bit in the 
>>>> userAccountControl
>>>> It defaults to Administrators. I am not an Admin9istrator, but am in 
>>>> another
>>>> roup that can create accounts for unix hosts, and can set this bit.
>>>> Our AD admind spent some time looking for it. With AD2003 There is a GUI
>>>> interface to set it.
>>>>
>>>> Start here:
>>>> http://technet2.microsoft.com/windowsserver/en/library/a9fd0aa2-301c-42b3-a7b1-2595631c389f1033.mspx?mfr=true
>>>>
>>>> Then look for
>>>> "For a Group Policy object, when you are on a domain controller or on a
>>>> workstation that has the Windows Server 2003Administration Tools Pack 
>>>> installed."
>>>>
>>>> You must be on the DC to set the policy.
>>>>
>>>>
>>>>> I almost know by heart all technet articles about delegation, but I'm 
>>>>> still unable to trust computer or users for delegation.
>>>>> I'm desperate
>>>>>
>>>>> Pierrot
>>>>>
>>>>>
>>>>> "Douglas E. Engert" <deengert at anl.gov> wrote in message 
>>>>> news:mailman.26.1192804737.4570.kerberos at mit.edu...
>>>>>> This sounds like what you are looking for:
>>>>>>
>>>>>>> -------- Original Message --------
>>>>>>> Subject: Re: Negotiate on Windows with cross-realm trust AD and MIT 
>>>>>>> Kereros.
>>>>>>> Date: Wed, 18 Jul 2007 09:04:12 -0500
>>>>>>> From: Douglas E. Engert <deengert at anl.gov>
>>>>>>> To: mikkel at linet.dk
>>>>>>> CC: Achim Grolms <kerberosml at grolmsnet.de>,  modauthkerb-help 
>>>>>>> <modauthkerb-help at lists.sourceforge.net>, kerberos <kerberos at mit.edu>
>>>>>>> References: <1184231952.3026.34.camel at tux.lib.cbs.dk> 
>>>>>>> <f76c3n$1bb$1 at sea.gmane.org> <1184658106.3276.3.camel at tux.lib.cbs.dk> 
>>>>>>> <200707172125.18286.kerberosml at grolmsnet.de> 
>>>>>>> <1184745677.3078.5.camel at tux.lib.cbs.dk>
>>>>>>>
>>>>>>> You asked how to do this is AD...
>>>>>>>
>>>>>>> An AD admin set the TRUSTED_FOR_DELEGATION in UserAccountControl for 
>>>>>>> the server.
>>>>>>> But not just any admin can set this, who can set the bit is 
>>>>>>> controlled by a group
>>>>>>> control policy on the DC. In 2000 you had to edit a file. In 2003 
>>>>>>> there is a way to
>>>>>>> set it see below.
>>>>>>>
>>>>>>>
>>>>>>> UserAccountControl definitions:
>>>>>>> http://support.microsoft.com/kb/305144
>>>>>>>
>>>>>>>
>>>>>>> Some pointers to trusted for delegation
>>>>>>> http://support.microsoft.com/kb/250874
>>>>>>> http://support.microsoft.com/kb/322143/EN-US/
>>>>>>> http://technet2.microsoft.com/windowsserver/en/library/72612d01-622c-46b7-ab4a-69955d0687c81033.mspx?mfr=true
>>>>>>>
>>>>>>>
>>>>>>> Enable computer and user accounts to be trusted for delegation
>>>>>>> http://technet2.microsoft.com/windowsserver/en/library/a9fd0aa2-301c-42b3-a7b1-2595631c389f1033.mspx?mfr=true
>>>>>>>
>>>>>>
>>>>>>
>>>>>> pierrot.heritier at unifr.ch wrote:
>>>>>>> Hello all
>>>>>>> I'm trying to setup Kerberos on my Windows 2003 domain. I already had
>>>>>>> to raise the domain functional level to Windows 2003 in order to get
>>>>>>> the Delegation tab in the SQLservice account. Now, when I try to 
>>>>>>> "trust this user  for delegation to any service
>>>>>>> (Kerberos only)", I get an Access Denied from the Active Directoy,
>>>>>>> although I'm logged in as domain admin.
>>>>>>> I suppose I'm missing something somewhere, but what ?
>>>>>>> Pierrot
>>>>>>> ________________________________________________
>>>>>>> Kerberos mailing list           Kerberos at mit.edu
>>>>>>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>>>>>>
>>>>>>>
>>>>>> -- 
>>>>>>
>>>>>>  Douglas E. Engert  <DEEngert at anl.gov>
>>>>>>  Argonne National Laboratory
>>>>>>  9700 South Cass Avenue
>>>>>>  Argonne, Illinois  60439
>>>>>>  (630) 252-5444
>>>>> ________________________________________________
>>>>> Kerberos mailing list           Kerberos at mit.edu
>>>>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>>>>
>>>>>
>>>> -- 
>>>>
>>>>  Douglas E. Engert  <DEEngert at anl.gov>
>>>>  Argonne National Laboratory
>>>>  9700 South Cass Avenue
>>>>  Argonne, Illinois  60439
>>>>  (630) 252-5444
>>>
>>> ________________________________________________
>>> Kerberos mailing list           Kerberos at mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>>
>>>
>> -- 
>>
>>  Douglas E. Engert  <DEEngert at anl.gov>
>>  Argonne National Laboratory
>>  9700 South Cass Avenue
>>  Argonne, Illinois  60439
>>  (630) 252-5444 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444



More information about the Kerberos mailing list