Hi Bryan, I think essentially the issue/question that comes up is what happens when you have say 5 domains, and you have people with the say domain name in those 5 domains.
So here's the use case: Let's say I have 5 domains: Synterex.com Boston.synterex.com Ny.synterex.com Miami.synterex.com Dallas.synterex.com When I move to Office 365, I have to make my SMTP and UPN match. This will now make it so everyone in all 5 domains has a UPN ending in synterex.com So, now I have an issue where you have user accounts in 5 domains all with the same REALM of SYNTEREX.COM. In this situation, there's only two ways this can still work: 1. You move everyone to the synterex.com domain which can be a real nightmare 2. You find a way to point all authentication against the Synterex.com KDC and still be able to get tickets for users living in the sub-domains I'm not sure if you can actually make #2 work or not. When I have tried, I get user not found in the database issues. Jon Towles CTO, Synterex (m) 978-609-5545 -----Original Message----- From: Bryan Mesich <bryan.mes...@digikey.com> Sent: Monday, July 13, 2020 11:01 PM To: Jonathan Towles <jjtow...@synterex.com> Cc: kerberos@mit.edu Subject: Re: Kerberos Database Sync with Sub-Domains On Mon, Jul 13, 2020 at 06:58:39PM +0000, Jonathan Towles wrote: > Hi All, Hello, > I wanted to ask a question that I have been unable to get clear information > on. > > Is it technically or functionally possible to get a Kerberos ticket for > someone in the sub-domain against the parent domain > > Example: > User j...@boston.synterex.com<mailto:j...@boston.synterex.com> wants to get a > Kerberos ticket against dc01.synterex.com but will fail because that user is > not found in the database on that Domain Controller. It is unclear to me based on your example if you are using one or multiple realms in your environment. Either way, you would want to have a properly configured krb5.conf that contains the Kerberos Realm(s) and domain-to-realm mapping information. A single realm might look like the following: [realms] SYNTEREC.COM = { kdc = dc01.synterex.com admin_server = dc01.synterex.com } [domain_realm] .synterex.com = SYNTEREC.COM The above configuration would cause the client to request tickets from the SYNTEREC.COM realm if the domain name contains .synterex.com (which covers all subdomains as well). A multiple realm configuration might look like the following: [realms] BOSTON.SYNTEREC.COM = { kdc = dc01.boston.synterex.com admin_server = dc01.boston.synterex.com } ATLANTA.SYNTEREC.COM = { kdc = dc01.atlanta.synterex.com admin_server = dc01.atlants.synterex.com } [domain_realm] .boston.synterex.com = BOSTON.SYNTEREC.COM .atlanta.synterex.com = ATLANTA.SYNTEREC.COM In this case, each subdomain has its own kerberos REALM. The domain_realm section maps the domain to the correct realm. It is also possible to request a service ticket from a different realm from which you have a valid TGT. A cross-realm trust would need to be setup to allow this. We have this setup between our MIT Kerberos realm and Active Directory realm (works quite nicely). "User is not found in the database" can often point at user mapping issue between your Unix/AD environment. In your example, you would want to make sure your AD user account "jon" exists (or change the userPrincipalName attribute in AD to match your Unix account). You can also try specifying the principal name manually using kinit: kinit j...@synterex.com Based off your email address and the fact that the domains being used in your example match, your AD user name could be jjtowles. In that case, make sure your krb5.conf is configured properly and try using kinit with: kinit jjtow...@synterex.com If the above works, then you'll have to change your userPrincipalName attribute in AD to match your Unix account, or change your Unix account name to match your AD account. Without making the change, using Kerberos with ssh is useless due to the fact your principal name doesn't match your Unix ID. > I didn't think that it was, but I wanted to check and see if anyone knows. Good luck! Bryan > Jon Towles > CTO, Synterex > (m) 978-609-5545 > > [VMware Certified Professional - Digital Workspace 2020][VMware Certified > Professional - Desktop and Mobility 2020][cid:image003.jpg@01D65926.16A527C0] > [cid:image004.png@01D65926.16A527C0] [cid:image005.png@01D65926.16A527C0] > [cid:image006.png@01D65926.16A527C0] > ________________________________________________ > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos -- Bryan Mesich Sr. System Administrator DIGI-KEY ELECTRONICS +1 218.681.8000 x16104 Powered by Linux 4.18.0-147.0.3.el8_1.x86_64 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
