Our setup is Windows 2003 FFL All DCs - Windows 2003 SP2 Recently one of the application team asked for setting up Kerberos constrained delegation to domain controllers for enabling SSO. They want to create Kerberos constrained delegation from Citrix presentation server to local DCs for CIFS and LDAP services. i.e. citrix1 à ldap/localdc.domain.com & citrix1 à cifs/localdc.domain.com I have fear that it would allow administrators on presentation server to impersonate domain admins against LDAP service on DC and make unauthorized changes in AD. Questions 1. Is my assumption correct? 2. If yes, how easy it would be to do that? 3. What are the operational repercussions of allowing such delegation on maintaining local DCs in that site? (We have 200+ DCs globally and 10 DCs in site where delegation is asked for)

Kamlesh, 1. Is my assumption correct? Yes Domain Admin can do anything they want.(impersonating an Active Directory User if you are authenticated as Domain Admin) You might not want to have your application run as Domain Admin. ASP.NET can certainly impersonate accounts. See ASP.NET Impersonation. I would suggest u posting up this thread on any security/pen testing forum for better suggestion. and please contact ur Sr. Info sec Team so that they help you in setting up this. please post this thread : http://social.technet.microsoft.com/Forums/en-US/winserversecurity/threads Gopi Kiran |Facebook| This posting is provided AS IS with no warranties,and confers no rights.

I would recommend to create new id and delegate require control and check how does it work. If there is no option an they need admin rights what you can do is create new id for them and enable auditing to check the Directory services changes made. Reference link: http://technet.microsoft.com/en-us/library/cc728087(WS.10).aspx http://support.microsoft.com/kb/232714 http://www.ultimatewindowssecurity.com/wiki/WindowsSecuritySettings/OVERVIEW-Audit-Directory-Service-Access However I would also recommend to post the query in security forum to check if get any alternate solution. Hope this helps Regards, Sandesh Dubey. ------------------------------- MCSE|MCSA:Messaging|MCTS|MCITP:Enterprise Adminitrator My Blog: http://sandeshdubey.wordpress.com This posting is provided AS IS with no warranties, and confers no rights.

I think you misunderstood the information. No one is saying the presentation server is using domain admin service account. concern is with KERBEROS DELEGATION going to LDAP service on DOMAIN CONTROLLER.

I think you misunderstood the information. No one is saying the presentation server is using admin rights. concern is with KERBEROS DELEGATION going to LDAP service on DOMAIN CONTROLLER. If that becomes true then as DA having access to LDAP on DC is a big risk. Kerberos delegation allows impersonation of any user in AD and that could easily be domain admin. Normally it is done from one application server to other and not to DOMAIN CONTROLLER.

I am not following the thread, so just some notes about the delegation: - to have some terminology, say we have: client -----> middle party which delegates -----> backend - you have actually three delegation options "unconstrained - the For Delegation to Any Service", "constrained - the For Delegation to Specified Services Only Kerberos Only" and the third "constrained with protocol transition - the For Delegation to Specified Services Only Any Protocol". These two and their differences I am covering below. - you are considering the two constrained forms, which means that the MIDDLE party (the one that delegates) is constrained only to the BACKEND party. - the Constrained/Kerberos delegation requires that the user working on CLIENT must have logged on the CLIENT with hist actual AD credentials which produced TGS for the MIDDLE party. This is important. So yes, when Administrator logs on to the CLIENT, the MIDDLE can then delegate as the Administrator to the BACKEND, right? And do whatever it wants with the Administrator credentials on the BACKED. But you can also restrict the Administrator account from accessing the CLIENT and MIDDLE party (firewall, access permissions, whatever). This way, MIDDLE would never receive Administrators' tickets to be able to delegate them to the BACKEND. - you can also consider completelly blocking delegation of the Administrator accounts in their user account properties in the Active Directory (Account tab, Account is sensitive and cannot be delegated). - so this is a common method how to protect constrained/kerberos delegation. Just prevent the Administrators from accessing the CLIENT and MIDDLE party at all or just disable their delegation at all. - the Constrained/ProtocolTransition delegation is more severe threat. With this enabled, MIDDLE can create Administrator credentials and forward them to the backed FROM NOTHING. It just asks a DC for the Administrator's credentials for BACKEND and it receives it completelly for free. It does not need the Administrator account to access MIDDLE or CLIENT at all. So even if the MIDDLE was not accessible at all, it would still be able to access BACKEND under whichever identity it likes (it only needs to know the user's login - look at this http://msdn.microsoft.com/en-us/library/td3046fc.aspx) - the Constrained/ProtocolTransition can be limited only by the "Account is sensitive and cannot be delegated" setting on the sensitive accounts. So this option is there just for very specific scenarios - such as those when the users need to be authenticated by something that is not in AD (such as SMS, fingerprint, questions, certificates in case of TMG/ISA/UAG etc.). - if the users on CLIENT have normal Kerberos access to AD, you should go for the Constrained/Kerberos and not use the Constrained/ProtocolTransition. any further questions? o.

As with most cases, it is a compromise. By using constrained delegation (ideally without protocol transition if possible) the aim is to limit the exposure by assigning specific services and delegated computers to minimise the risk. This article has some good info to suppliment the excellent info provided by Ondrej: http://www.adopenstatic.com/cs/blogs/ken/archive/2007/07/19/8460.aspx At the end of the day, if you need some form of delegation to achieve SSO, KCD is good option and arguably better than a lot of other SSO methods like NTLM or basic delegation. By constraining it, you are at least in control over which services and delegated servers are being used. KCD is also pretty much your only option if users are using certificates or Smartcards and you want some form of SSO. I guess if you want the most secure option, you need to forego SSO completely, but then things likely just won't work or you will have to live with authenticating multiple times. The age old functionality vs. security conumdrum :) Cheers JJJason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

I am not following the thread, so just some notes about the delegation: - to have some terminology, say we have: client -----> middle party which delegates -----> backend - you have actually three delegation options "unconstrained - the For Delegation to Any Service", "constrained - the For Delegation to Specified Services Only Kerberos Only" and the third "constrained with protocol transition - the For Delegation to Specified Services Only Any Protocol". These two and their differences I am covering below. - you are considering the two constrained forms, which means that the MIDDLE party (the one that delegates) is constrained only to the BACKEND party. - the Constrained/Kerberos delegation requires that the user working on CLIENT must have logged on the CLIENT with hist actual AD credentials which produced TGS for the MIDDLE party. This is important. So yes, when Administrator logs on to the CLIENT, the MIDDLE can then delegate as the Administrator to the BACKEND, right? And do whatever it wants with the Administrator credentials on the BACKED. But you can also restrict the Administrator account from accessing the CLIENT and MIDDLE party (firewall, access permissions, whatever). This way, MIDDLE would never receive Administrators' tickets to be able to delegate them to the BACKEND. - you can also consider completelly blocking delegation of the Administrator accounts in their user account properties in the Active Directory (Account tab, Account is sensitive and cannot be delegated). - so this is a common method how to protect constrained/kerberos delegation. Just prevent the Administrators from accessing the CLIENT and MIDDLE party at all or just disable their delegation at all. - the Constrained/ProtocolTransition delegation is more severe threat. With this enabled, MIDDLE can create Administrator credentials and forward them to the backed FROM NOTHING. It just asks a DC for the Administrator's credentials for BACKEND and it receives it completelly for free. It does not need the Administrator account to access MIDDLE or CLIENT at all. So even if the MIDDLE was not accessible at all, it would still be able to access BACKEND under whichever identity it likes (it only needs to know the user's login - look at this http://msdn.microsoft.com/en-us/library/td3046fc.aspx) - the Constrained/ProtocolTransition can be limited only by the "Account is sensitive and cannot be delegated" setting on the sensitive accounts. So this option is there just for very specific scenarios - such as those when the users need to be authenticated by something that is not in AD (such as SMS, fingerprint, questions, certificates in case of TMG/ISA/UAG etc.). - if the users on CLIENT have normal Kerberos access to AD, you should go for the Constrained/Kerberos and not use the Constrained/ProtocolTransition. any further questions? o.

Thanks Ondrej Citrix team is proposing to configure Constrained/Kerberos only delegation from its presentation server to LDAP service on domain controller. From your explanation, I understand only risk I have is when domain admins explicitely login to Citrix servers. so there is no risk of someone misusing the delegation and getting credential of DA without knowing the DA password. As your recommendation I will work on enabling "account is sensitive, do not delegate" bit for all DAs and other privileged accounts.