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