On Wed, 16 Mar 2011, Michael B Allen wrote:
> On Mon, Mar 14, 2011 at 5:58 AM, John Hodrien <J.H.Hodrien@xxxxxxxxxxx> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
