# Access denied when using CNAME

**URL:** <https://discourse.openondemand.org/t/access-denied-when-using-cname/3108>\
**Category:** Get Help\
**Tags:** question\
**Created:** [November 20, 2023, 4:48pm UTC](https://discourse.openondemand.org/t/access-denied-when-using-cname/3108 "2023-11-20T16:48:18Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![HPC](https://avatars.discourse-cdn.com/v4/letter/h/71c47a/32.png) [@HPC](https://discourse.openondemand.org/u/HPC)\
**Post date:** [November 20, 2023, 4:48pm UTC](https://discourse.openondemand.org/t/access-denied-when-using-cname/3108/1 "2023-11-20T16:48:18Z")

</div>

After upgrading from OoD-2.0.32 to OoD-3.0.3 our portal doesn’t accept logons through a CNAME.  
We have four servers running OoD which are all reachable through a shared CNAME (round-robin DNS). This worked well with OoD-2.0.32. After the upgrade users get:  
`HTTP ERROR 403: Access Denied`

We temporarily worked around this by setting (in /etc/httpd/conf.d/ood-portal.conf)  
`SetEnv OOD_ALLOWED_HOSTS "<FQDN CNAME>,<FQDN A-record>"`

This config is automatically generated at every boot through the ood-portal-generator, where the `<FQDN A-record>` is a variable for every host. This means that the work-around will be overwritten after a reboot, so we would like to configure this somewhere in de YAML-files. Could anyone help us achieve this?

---

<div class="post-metadata">

**Author:** ![hrandquist](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/hrandquist/32/2536_2.png) [@hrandquist](https://discourse.openondemand.org/u/hrandquist)\
**Post date:** [November 20, 2023, 7:57pm UTC](https://discourse.openondemand.org/t/access-denied-when-using-cname/3108/2 "2023-11-20T19:57:07Z")

</div>

Can you supply the `servername` and `proxy_server` configurations from your `ood_portal.yml`? This should have just worked and we’d like to investigate further. As for a workaround, you might be able to supply something in `pun_custom_env` ([nginx\_stage.yml — Open OnDemand 3.0.3 documentation](https://osc.github.io/ood-documentation/latest/reference/files/nginx-stage-yml.html)):

```auto
pun_custom_env:
   ALLOWED_HOSTS: "the FQDN"

```

---

<div class="post-metadata">

**Author:** ![HPC](https://avatars.discourse-cdn.com/v4/letter/h/71c47a/32.png) [@HPC](https://discourse.openondemand.org/u/HPC)\
**Post date:** [November 21, 2023, 8:44am UTC](https://discourse.openondemand.org/t/access-denied-when-using-cname/3108/3 "2023-11-21T08:44:27Z")

</div>

servername is set to ‘null’, proxy\_server is not set

```auto
servername: null
#proxy_server: null

```

Setting a fixed value would be problematic since our servers are all running from the same image, so they have identical yaml-files but different servernames, which would have to be dynamically configured during generation-time. Is there a variable for FQDN or hostname I can use in the yaml-file (i.e. derived from /etc/hostname of the hostname command)?

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [November 21, 2023, 2:02pm UTC](https://discourse.openondemand.org/t/access-denied-when-using-cname/3108/4 "2023-11-21T14:02:54Z")

</div>

> [@hrandquist](#):
>
> ```auto
> pun_custom_env:
> ALLOWED_HOSTS: "<FQDN CNAME>"
> 
> ```

This in `nginx_stage.yml` should be a workaround for you as the `FQDN CNAME` is static and well known before the image is created (or booted). This workaround should work until we fix the system upstream.

We should be populating `OOD_ALLOWED_HOSTS` correctly for you and obviously we’re not.

Do you use `ServerAlias` anywhere - we have support for that although I’m finding now it’s not documented.

If you have `servername: null` how does apache route the request (I’m guessing the requests/users use `FQDN CNAME`?) to the right configuration?

---

<div class="post-metadata">

**Author:** ![HPC](https://avatars.discourse-cdn.com/v4/letter/h/71c47a/32.png) [@HPC](https://discourse.openondemand.org/u/HPC)\
**Post date:** [November 21, 2023, 3:40pm UTC](https://discourse.openondemand.org/t/access-denied-when-using-cname/3108/5 "2023-11-21T15:40:14Z")

</div>

Thanks @jeff.ohrstrom and @hrandquist I really appreciate your help.

> [@jeff.ohrstrom](#):
>
> This in `nginx_stage.yml` should be a workaround for you as the `FQDN CNAME` is static and well known before the image is created (or booted). This workaround should work until we fix the system upstream.

`FQDN CNAME` is indeed fixed, but we want the servers also to be accessible on their individual name.  
We have login[01-04].domain and a shared CNAME login.domain. We could of course configure all 5 names on all servers and that might work. But it’s ‘wrong’. 😉

> [@jeff.ohrstrom](#):
>
> Do you use `ServerAlias` anywhere - we have support for that although I’m finding now it’s not documented.

No, we don’t use `ServerAlias`. At least it’s not in our `ood_portal.yml`. How should we use it to get OoD to work on both the shared name and the individual name.

> [@jeff.ohrstrom](#):
>
> If you have `servername: null` how does apache route the request (I’m guessing the requests/users use `FQDN CNAME`?) to the right configuration?

I suppose the use of `servername: null` results in a default vhost config:

```auto
<VirtualHost *:80>
and
<VirtualHost *:443>

```

Which is fine at this moment, since this is the only website running on these hosts. Of course it would be better to explicitly naming the vhost with all desired names.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex015/uploads/osc/original/2X/b/bae70bd0ed39a3ae769c2108155f4cb3e9da8385.png) [@system](https://discourse.openondemand.org/u/system)\
**Post date:** [May 19, 2024, 3:40pm UTC](https://discourse.openondemand.org/t/access-denied-when-using-cname/3108/6 "2024-05-19T15:40:52Z")

</div>

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.