You can create a vanity URL for your site. When doing so, please be aware of the following:
Complete the Following Steps:
For the following examples, assume that a firm named Sample Enterprises Inc is implementing IdentityNow on their own domain "sample.com".
1. Decide on the appropriate URLs for hosting IdentityNow on your own domain:
NOTE: All URLs must be unique. For deployments that use multiple sites such as a production and sandbox site, append a postfix like "sandbox" or "sb" to the domain for the Sandbox site to meet this requirement.
2. Obtain the necessary TLS certificates and keys. We support the following options for obtaining TLS certificates. Only one of the options may be used for a specific site:
3. Send your hosted zone names and SSL/TLS certificate(s) to SailPoint. Refer How do I generate a TLS certificate and key for my vanity URL? for details.
4. SailPoint sends you the NS records you need to set up in both internal (if applicable) and public DNS.
5. You create NS records for each site on your DNS registrar. This requires creating a subdomain delegation (also know as 'NS' record) entry inside your zone, with the value being the nameservers we provided in step 4. This needs to be done for all IdentityNow sites that are part of your engagement. To see the proper delegation of your subdomain entries to the Amazon authoritative nameservers, see the FAQs.
NOTE: Your virtual appliances must be able to resolve both records (sites) with the same NS information. As a result, you might also need to create records on your internal DNS servers. This might be true if:
6. After these steps have been completed, SailPoint provisions your site. Once complete, you and your SailPoint engagement team may start setting up the site for your use cases.
Refer to the following frequently asked questions for more information about the process:
NOTE: For cert-specific questions, see How do I generate a TLS certificate and key for my vanity URL?
We no longer use a separate hostname for the SSO component. This means that for each deployment, only a single DNS zone with a single certificate needs to be generated.
We're unable to use static IPs due to limitations in AWS. Their load balancing service uses DNS, but they rotate the machines so we're unable to identify a single address to use.
The Sample company might request the following URLs:
Due to a problem in Microsoft's IWA (Kerberos) implementation in certain products, domains has to resolve to an A record in order for them to authenticate successfully (as described here). To ensure operability of all products IdentityNow currently support, we only support domain delegation as described above.
Although we refer to DNS records in this document, when it comes to delegation, you will technically delegate an entire subdomain for each site. Going with our Sample Enterprise example, they will need to delegate the subdomain 'iam.sample.com' to the Nameservers we provide. Note that they do not have to delegate 'sample.com'. In this subdomain, we will create the record 'iam.sample.com' to point to the correct resources that serve your IdentityNow site. The record is indeed the same as the subdomain.
The DNS entries have to be public because SailPoint staff, external employees, and any external integrations you build also needs to be able to communicate with your IdentityNow site.
In step 5, it says I must create NS records for each site on your DNS registrar, which requires creating a subdomain entry inside your zone. The values are the Nameservers we provided in step 4.
The screenshot below demonstrates the proper delegation of your subdomain entries to the Amazon authoritative nameservers. Once the request reaches these nameservers, the correct record will be returned.