Re: Use of SPNs

• Previous message: Ken Yu: "Re: Group Police Question !"
• In reply to: Danny Cooper: "Re: Use of SPNs"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Mon, 8 Nov 2004 20:28:43 -0700

Right, constrained delegation (as compared to prior all or
none grants) is a much needed improvement.
Of course, if you are dealing with a software that does not
do any impersonating it is impossible to use it to explore this.

-- 
Roger
"Danny Cooper" <danny.cooper@bbc.co.uk> wrote in message 
news:8sluo05n5cj4brjknke2141q58itgegsqa@4ax.com...
>
> Ah, thank.On the Microsoft papers there is great play on the new
> constrained delegation feature, but almost no practical example of its
> use outside of IIS and SQL Server - hence why I was experimenting.
>
>
>>
>>Danny,
>>
>>SPN is a name mapping technique defined in the Kerberos GSS
>>(General Security Service) technology.  Since Backup Exec does
>>not, as you say, use SPNs defining an SPN for the account used for
>>the Backup Exec service(s) will have no effect (i.e. Backup Exec
>>is not written as a Kerberos aware application).  If you want to
>>understand SPNs you can look these up in any decent reference
>>for Kerberos.  Since Windows names do not have the same form
>>as defined for services in a Kerberos realm SPNs are needed in
>>a Windows AD system for all accounts used for Kerberos based
>>services to establish the "aliasing" for the Windows principal to
>>its naming in Kerberos-speak.  SPNs in a Unix based Kerberos
>>realm are used for similar "aliasing" situations where defaults
>>will not allow correct location of the service based on the name
>>of the principal.
>>
>>When you have defined a Windows account with sufficient rights
>>that it may be used as the service account for Backup Exec, it is
>>not surprising that this same account can be used for a number of
>>other services.  That is, since that account is configured with needed
>>rights (like log on as a service) so that the account is enabled to
>>register service instances at startup, so it would work also for other
>>services unless it does not have access to some needed resources
>>(service specific files, enterprise components, etc..) or attempts
>>things only allowed to the Administrators group (or to System).
>>
>>Enabling an account for delegation is saying that the account can
>>assume the credentials of another account, if that account allows
>>the impersonation.  Saying an account is sensitive and cannot be
>>delegated is flagging that account so that it cannot be impersonated
>>by an account that has been trusted for delegation.  These are
>>independent from, but usable together with, Kerberos, and so with
>>"Kerberized" services.
> 

• Previous message: Ken Yu: "Re: Group Police Question !"
• In reply to: Danny Cooper: "Re: Use of SPNs"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]