On Fri, 25 Apr 2014, steve wrote:
On Thu, 2014-04-24 at 16:33 -0400, Jeremy Agee wrote:
> On 04/23/2014 05:25 AM, John Hodrien wrote:
> >
> > This is a guide for setting up against AD. Is there *any* realistic
> > circumstance where SHORTNAME$@REALM won't be available?
> If someone was creating the keytab on the windows side using
ktpass like
> the example in the Creating Service Keytab on AD section this could be
> needed. This is less common though and your correct in most setups it
> would not be needed. The powershell script in that same section would
> create both a host/fqdn@REALM and SHORTNAME$@REALM principle with a UPN,
> so the extra config line would not be needed if the keytab was create by
> ktpass in this way.
Hi
One other circumstance could be with a samba net ads join from a
previous domain join where smb.conf did not include at least:
kerberos method = system keytab
line.
Under these circumstances it would be necessary to issue:
net ads keytab create
to get the machine (and host/) key.
Yep, I can see that one.
I guess I'm personally not keen for this document to be a guide on undoing
unknown broken practice. I equally could have changed the userAccountControl
to break kerberos by only allowing unusable enctypes or similar, but I don't
think this should go into those details. Or joining when there was an
existing record in AD for a previous windows machine.
Freaky setups will go outside this document, whatever you do, but I'd choose
to have that document as lithe as possible. realmd/samba/ad-server approaches
are all listed as valid in different cases, with justification for why that is
so.
I might also prefer a bit of a restructure as I think it's a little confusing
at the minute what is required:
Joining to AD:
- realmd (does everything)
- manual setup
- generate keytab with samba
- generate keytab on ad server
jh
--
John Hodrien
Specialist IT and Unix, IT
Faculty of Engineering
0113 3435471
9.26 EC Stoner