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" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> >> 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" <[EMAIL PROTECTED]> wrote in message >>> news:[EMAIL PROTECTED] >>>> 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" <[EMAIL PROTECTED]> wrote in message >>>>> news:[EMAIL PROTECTED] >>>>>> 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 <[EMAIL PROTECTED]> >>>>>>> To: [EMAIL PROTECTED] >>>>>>> CC: Achim Grolms <[EMAIL PROTECTED]>, modauthkerb-help >>>>>>> <[EMAIL PROTECTED]>, kerberos <[email protected]> >>>>>>> References: <[EMAIL PROTECTED]> >>>>>>> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> >>>>>>> <[EMAIL PROTECTED]> >>>>>>> <[EMAIL PROTECTED]> >>>>>>> >>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> [EMAIL PROTECTED] 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 [email protected] >>>>>>> https://mailman.mit.edu/mailman/listinfo/kerberos >>>>>>> >>>>>>> >>>>>> -- >>>>>> >>>>>> Douglas E. Engert <[EMAIL PROTECTED]> >>>>>> Argonne National Laboratory >>>>>> 9700 South Cass Avenue >>>>>> Argonne, Illinois 60439 >>>>>> (630) 252-5444 >>>>> ________________________________________________ >>>>> Kerberos mailing list [email protected] >>>>> https://mailman.mit.edu/mailman/listinfo/kerberos >>>>> >>>>> >>>> -- >>>> >>>> Douglas E. Engert <[EMAIL PROTECTED]> >>>> Argonne National Laboratory >>>> 9700 South Cass Avenue >>>> Argonne, Illinois 60439 >>>> (630) 252-5444 >>> >>> ________________________________________________ >>> Kerberos mailing list [email protected] >>> https://mailman.mit.edu/mailman/listinfo/kerberos >>> >>> >> -- >> >> Douglas E. Engert <[EMAIL PROTECTED]> >> Argonne National Laboratory >> 9700 South Cass Avenue >> Argonne, Illinois 60439 >> (630) 252-5444 > > > > ------------------------------------------------------------------------ > > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos -- Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
