Re: Borderline offtopic: OpenAFS as ~ for Samba AD?
Måns Nilsson <[email protected]>
| Newsgroups | gmane.comp.file-systems.openafs.general |
|---|---|
| Message-ID | <[email protected]> |
Subject: Re: [OpenAFS] Borderline offtopic: OpenAFS as ~ for Samba AD? Date: Sat, Feb 15, 2020 at 04:11:46PM -0500 Quoting Jeffrey E Altman ([email protected]): > On 2/15/2020 7:55 AM, Måns Nilsson wrote: > > Subject: Re: [OpenAFS] Borderline offtopic: OpenAFS as ~ for Samba AD? Date: Mon, Jan 20, 2020 at 04:42:24PM -0500 Quoting Jeffrey E Altman ([email protected]): > >> No need for cross-realm. Create an afs/[email protected] service principal > >> with a kvno > >> that differs from the afs/[email protected] service principal and add the > >> key to your > >> AFS servers as well as adding both realm names to the AFS servers' krb.conf. > > > > Thanks! > > > > I've finally mustered enough bravery to tackle this. Would proper DNS > > find-a-bility for Kerberos serve as complete substitute for "as adding > > both realm names to the AFS servers' krb.conf" ? > > NO! The list of realms in the krb.conf are used to specify which realms > will be chopped off the authenticated principal name so there will be a > match with protection service user or group entries. > > Kerberos DNS SRV records are used by clients to find the Kerberos KDCs > for the realm. The AFS servers never contact the KDCs themselves. Yes! This works. Like a charm. Thanks a lot! > You only would create a system:[email protected] group and then > create <user>@samb4.realm entries if you were treating the two sets of > identifies as unique. My first impression is that this is something one does only if there is no other way. Keeping accounts as similar across the board seems a bit easiser, if doable. Here it is so, so we'll stick to that. Thanks. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Is this an out-take from the "BRADY BUNCH"?
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEpp2QVFhCcv+wDUfCDgtx4NP2G7QFAl5IbAEACgkQDgtx4NP2 G7Q8Tw/8D7fchJqyV4XGT6XEC1AfaKi/1BHRLyNbHAY+rnTsew9MBB+aiTiSGYkT g/cVR71AR8Sp3hm+no8X9xPXVB57x4VBW0YjdXvjMI0zv+YwvrpuvqSKdd3jAYvQ rgr4sMYJMSDof1wv3b9+cRgqRf6u8yZE8yH7boA7j2bsn1l/mEah8l3ab9D4NnDT ZUwACPo9fZ3smOxdCcdDmjRgh4rbpAsm/qhp2oqz0sXlAGNgsPETut9I/fu2DtQj NXzpJW7FxNJEiIxW8nVAVi3dpyuauVE2ZKdTCKovxc+VLyGy4SIIpE/ITlbC+eZh FaJFqfVHxOQWogVeBXEPrgXJqc9uADw8E5N+LTWq80/hs937c0XF6SXvqbdXPMJm 3VXIHzr5ebaUJ44mGVHvFXEW0Q3zCAaSXz4qZFB6CNx1t3rHwE6IGDgn+v7DKdWJ PjvUCiHGEdtMadJRtavJLWpI8A9xh72tCPUj7+1Xuao3ezi1iLRCullIkyPiiLuH V33akpo3193mAf/JGnEGwSjTmpQeCJToj4vJjL7IeD26q7Q3pMz2bJNWJBd5bTB7 GJ654dSJy6S584n/Gy/nHWrYkjU3eqyShQrCUxRxpwGYcqFBBjIB9ORm5Y7GBa12 WjWh6IedTRdqlxQAK6k+R7FjCqhwKPQOQaVio0kPF+MP4toFZz4= =+IZS -----END PGP SIGNATURE-----