Replies inline ...
> And our setup is strange as we could never get the global AD
admins to make DNS
> entries for us among other issues so we ended up choosing a totally new
> TLD domain name to run IPA on and bind our servers against; this works
> fine except we can't leverage kerberos based features because our realm
> is different from our domain.
You can enrol IPA client through through Kerberos, this correct?
Yep! Our oddball IPA setup looks like this, due to a combination of
senior IT leadership being frightened of the cloud and global active
directory domain admins doing their usual global admin thing and
refusing to even take meetings with mortals. So we had to self-support
and only got a grudging 1-way trust set with the domain after escalating
to very high levels. It works though.
AD Domain (complex multi-child forest) ==
company-x.com with child
domains at
nafta.company-x.com,
apac.company-x.com etc. etc.
Our FreeIPA domain name is ==
company-x-ipa.com
So our REALM is COMPANY-X-IPA and that is where we bind our client
machines to when enrolling but we set the local domain name and hostname
to "company-x.com" when we enroll the host
This works well but from what I've been told we lose the ability to do
things like kerberized authentication for filessytem mounts etc. --
since all we really needed was RBAC managed SSH login with a small
smattering of custom sudo roles and a bunch of local SSH key storage it
works fine for us.
I wish its this, but I dont think so. If it was this, wouldn't
doing
dig @192.168.30.8
neptune.external.example.com work at least? The
host 192.168.30.8 being in the office? How is your VPC? Do you have
public and private and NAT between? Or just a flat public? I went
with the later as I assumed IPA don't like working over NAT.
Yeah most of this
DNS is on-premise; again because of a corporate desire
to use AD for DNS. We basically point all our nameservers at the on-prem
domain controllers and don't use FreeIPA for DNS records really much at
all (even the _SVR records that enable FreeIPA auto-discovery) -- but no
network, DNS query or technical issues at all with DNS being outside of
AWS -- works fine for us even DNS queries made on the IPA masters. For
rare cases where that did not work (HPC use cases) we did the DNSMasq
thing so we could inject custom reverse DNS responses while still
delegating other queries back to the domain controllers.
Our VPC is direct connected back to the corporate WAN; no NAT on the
private AWS subnets so it would be flat/private. Lots of security
controls and firewalls doing SSL intercept and decrypt at edges that
blocked
Thanks again for the feedback.
Regards,
William