Thank you Sam, I will look over the documentation you referenced.
On 26/09/2022 17:33, Sam Morris via FreeIPA-users wrote:
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>.
_______________________________________________
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
