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