On Wed, 16 Mar 2011, Michael B Allen wrote:
On Mon, Mar 14, 2011 at 5:58 AM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Mon, 14 Mar 2011, Michael B Allen wrote:
Hi Asya,
You must set the servicePrincipalName attribute on the service account (MYSERVER$ in this case) to include all of the hostnames that will be used to access the web server which in this case would be at least "HTTP/myserver.server.com". One way to do this would be to use setspn.exe on a Windows client but if you really have no access to the Windows side as you say, you could use the Samba keytab to acquire credentials for doing the necessary LDAP add operation using some tool (maybe there is a Samba utility for this, I don't know) or program.
That's not true, and I'm not even sure it's possible from samba (at least, I'm not sure it *should* be possible).
What's not true? That you can use the Samba keytab to acquire a ticket and perform an LDAP operation on it's own Computer account? It certainly is true. In fact Samba uses the keytab to authenticate with and at least query AD services on a regular basis to perform normal day-to-day operations.
Sorry I overquoted, I'll be more explicit. You said:
"You must set the servicePrincipalName attribute on the service account (MYSERVER$ in this case) to include all of the hostnames that will be used to access the web server"
That just isn't true. You don't need all those principals in, and I can't think of a sane way that'd even be possible. There's no sane way this host credential could be used to generate HTTP/another.fqdn@REALM credentials. Surely?
But from looking at you other response I wonder if "net ads keytab ADD HTTP" adds servicePrincipalName attribute values (I don't use Samba like that so I don't know). If is supposed to, and the AD account does not have them, then I agree, something is wrong and he should start over. It could be a replication issue.
Yes. That command creates servicePrincpalName entries for HTTP with the FQDN and the short name.
I don't know what the official view is on going through a CNAME but I think that is probably a dubious practice. The proper way to handle this scenario would be to add another servicePrincipalName value for HTTP/www.friendly and a corresponding keytab entry for HTTP/www.friendly@KRB-REALM.
Dubious why? If I go with your method at the very least I now need more records in AD for machines that don't exist, and I'm guessing I'll be creating them by being a domain administrator, which is inconvenient in large organisations.
I'm assuming I'll also be needing to add A records for these domains. Kerberos surely won't be a fan of there not being a PTR record, so I assume you'd need multiple PTR records. Is this really the path you're suggesting going down? I'm genuinely interested here, I'm not having a dig.
jh