On Tue, Mar 22, 2011 at 5:55 AM, John Hodrien <j.h.hodr...@leeds.ac.uk> wrote: > On Tue, 22 Mar 2011, Michael B Allen wrote: > >> Hi John, >> >> You would not have to create "dummy" machine records. The >> servicePrincipalName attribute on an AD account is multi-valued and >> clients can request and get a ticket for ANY principal in that list. >> So you only need one account. >> >> And you do not need special permissions if you have an existing keytab >> because you can use the keytab to authenticate with AD and add >> servicePrincipalName values to the account itself. At least in theory >> you can. I don't know if Samba's routine for adding HTTP SPNs is smart >> enough to know that it needs to not just add servicePrincipalName >> values but that it will also need to rebuild the keytab. > > Yes, but using the machine principal you're able to request any number of > service principals that are SERVICENAME/<machinename>. For this to work in a > virtual hosting environment, you need multiple machine names (since we're > talking about making a number of HTTP/<blah> principals). Whilst I accept
The "<machinename>" of the principal does NOT have to match the actual machine name. You could create a User object called "alice" with servicePrincipalName values of HTTP/as1.busicorp.local, HTTP/mycomputer.net and HTTP/test1 and requesting tickets for any of those names will work just fine. AD just searches for an account with a servicePrincipalName value that matches the principal requested for the service ticket. Pedantic note: If you have the same servicePrincipalName value on more than one account, AD will actually choke and not return a ticket at all (because the request is ambiguous), there is no constraint in AD to stop people from accidentally adding the same SPN to multiple accounts and AD will not return any kind of meaningful error about it. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
