On Mon, Sep 26, 2022 at 02:10:29PM +0100, Entrepreneur AJ via FreeIPA-users wrote: > > We have our own ASN and IP pool and was hoping to anycast our servers so > that as our employees travel they just connect to the nearest operational > instance. > > [...] > > I have tried by just setting up an anycast IP but can't enroll using the > anycast hostname because it errors out getting the root cert with the domain > not matching. > > [...] > > Ideally we want to be able to have the dns srv records point to > ipa.eajglobal.net and nothing else, relying on anycast but looks like I > would need a way of adding a SAN to the root certificate. Can anybody advise > on the best way of doing this?
You can probably add an additional DNS-ID to each TLS server certificate on each server by carefully using getcert-request to modify the relevant certifiate tracking requests. But it's not a good idea. I think the note at <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/planning_identity_management/failover-load-balancing-high-availability_planning-identity-management#server_side_load_balancing_and_service_availability> applies here: "Red Hat recommends against combining IdM and other load-balancing or high-availability (HA) software. Many third-party high availability solutions assume active/passive scenarios and cause unnecessary service interruption to IdM availability. Other solutions use virtual IPs or a single hostname per clustered service. All these methods do not typically work well with the type of service availability provided by the IdM solution. They also integrate very poorly with Kerberos, decreasing the overall security and stability of the deployment." Would FreeIPA's concept of 'locations' work for you? Servers can be assoicated with a location and clients will preferentially talk to servers in their own location (as determined by which server answers their DNS queries). So, you'd need something routing DNS queries from your clients to an appropriate server, based on for instance their IP address. With that in place, a client in gb-lon will locate IPA servers like so: $ delv -i _ldap._tcp.domain.tld srv ; answer not validated _ldap._tcp.domain.tld. 1058 IN CNAME _ldap._tcp.gb-lon._locations.domain.tld. _ldap._tcp.stn._locations.domain.tld. 1158 IN SRV 0 100 389 ipa1.gb-lon.domain.tld. _ldap._tcp.stn._locations.domain.tld. 1158 IN SRV 0 100 389 ipa2.gb-lon.domain.tld. _ldap._tcp.stn._locations.domain.tld. 1158 IN SRV 0 100 389 ipa3.gb-lon.domain.tld. _ldap._tcp.stn._locations.domain.tld. 1158 IN SRV 50 100 389 ipa1.us-dal.domain.tld. _ldap._tcp.stn._locations.domain.tld. 1158 IN SRV 50 100 389 ipa2.us-dal.domain.tld. _ldap._tcp.stn._locations.domain.tld. 1158 IN SRV 50 100 389 ipa3.us-dal.domain.tld. _ldap._tcp.stn._locations.domain.tld. 1158 IN SRV 50 100 389 ipa1.sg-sg.domain.tld. _ldap._tcp.stn._locations.domain.tld. 1158 IN SRV 50 100 389 ipa2.sg-sg.domain.tld. _ldap._tcp.stn._locations.domain.tld. 1158 IN SRV 50 100 389 ipa3.sg-sg.domain.tld. Note that the servers in gb-lon have a lower priority, so the client will prefer to talk to them. It'll fall back to a server in another location if it can't reach any of the servers in gb-lon. The docs for this can be found at <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/planning_identity_management/failover-load-balancing-high-availability_planning-identity-management>. -- Sam Morris <https://robots.org.uk/> PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9 _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
