QA: where are ox context/admin credentials stored on opendesk / nubus

Question

Where are ox context/admin credentials stored on Opendesk / Nubus

Answer

There are two primary mechanisms for configuring and storing access credentials in the OX Connector and OpenDesk environments:

configmap “ox-connector”:
The Configmap is used to store the general administrator access credentials for OpenExchange. You can validate these credentials as follows:

kubectl exec -n ${NAMESPACE?} \
  $(kubectl get -n ${NAMESPACE?} pods -l app=core-mw | tail -1 | awk '{print $1}') \
  -- /opt/open-xchange/sbin/listcontext \
  -A "$(kubectl get -n ${NAMESPACE?} configmaps ox-connector -o json | jq '.data.OX_MASTER_ADMIN' -r)" \
  -P "$(kubectl get -n ${NAMESPACE?} configmaps ox-connector -o json | jq '.data.OX_MASTER_PASSWORD' -r)"

Expectation: the available contexts will be listed, for instance:

cid fid fname       enabled qmax qused name lmappings  
 1   3 1_ctx_store true             0 1    1,context1

Unlike UCS, this administrator also appears to have access to the default contexts. This can be validated as follows, but might change in future releases:

kubectl exec -n ${NAMESPACE?} \
  $(kubectl get -n ${NAMESPACE?} pods -l app=core-mw | tail -1 | awk '{print $1}') \
  -- /opt/open-xchange/sbin/listuser \
  -A "$(kubectl get -n ${NAMESPACE?} configmaps ox-connector -o json | jq '.data.OX_MASTER_ADMIN' -r)" \
  -P "$(kubectl get -n ${NAMESPACE?} configmaps ox-connector -o json | jq '.data.OX_MASTER_PASSWORD' -r)" \
  -c 1

Expectation: The available users will be listed, in the example:

Id Name             Displayname                         Email                                               qmax qused
3 fabian.schneider fabian schneider (fabian.schneider) fabian.schneider@fschneider-opendesk.univention.dev -1         
2 oxadmin          OX Admin                            oxadmin@fschneider-opendesk.univention.dev          -1  

ox-contexts.json

Within the OX connector, the login credentials for the administrator and the individual contexts are stored separately. If problems arise, they are most likely to be found here due to the structure.

kubectl exec -n ${NAMESPACE?} \
  $(kubectl get -n ${NAMESPACE?} pods -l app=core-mw | tail -1 | awk '{print $1}') \
  -- /opt/open-xchange/sbin/listcontext \
  -A "$(kubectl exec -n ${NAMESPACE?} ox-connector-0 -- cat /etc/ox-secrets/ox-contexts.json | jq '.master.adminuser' -r)" \
  -P "$(kubectl exec -n ${NAMESPACE?} ox-connector-0 -- cat /etc/ox-secrets/ox-contexts.json | jq '.master.adminpass' -r)"

If an error occurs here, the entry (after backing up the file!) can simply be replaced in /etc/ox-secrets/ox-contexts.json with the values ​​from the config map, and the OX-Connector Pod can be restarted.

kubectl exec -n ${NAMESPACE?} ox-connector-0 -- bash -c "\
  jq --arg pass \"$(kubectl get -n ${NAMESPACE?} configmaps ox-connector -o json | jq '.data.OX_MASTER_PASSWORD' -r)\" \
  '.master.adminpass=\$pass' \
  /etc/ox-secrets/ox-contexts.json > /etc/ox-secrets/ox-contexts.json.tmp; \
  mv /etc/ox-secrets/ox-contexts.json.tmp /etc/ox-secrets/ox-contexts.json"

In addition, there are entries for the individual contexts (context admin). Here you can verify access data based on the available context IDs (1 in the example) from the last test as follows:

kubectl exec -n ${NAMESPACE?} \
  $(kubectl get -n ${NAMESPACE?} pods -l app=core-mw | tail -1 | awk '{print $1}') \
  -- /opt/open-xchange/sbin/listuser \
  -A "$(kubectl exec -n ${NAMESPACE?} ox-connector-0 -- cat /etc/ox-secrets/ox-contexts.json | jq '."1".adminuser' -r)" \
  -P "$(kubectl exec -n ${NAMESPACE?} ox-connector-0 -- cat /etc/ox-secrets/ox-contexts.json | jq '."1".adminpass' -r)" \
  -c 1

If an inconsistency exists, it should be investigated further. In the simplest case, the context administrator’s password can simply be set in the UMC to match the current password. In more complex cases, the password must be manually reset in OX using /opt/open-xchange/sbin/changeuser, following the same procedure, potentially in conjunction with temporarily disabling authentication. In this case, the procedure is no different from that used in regular UCS systems.

This topic was automatically closed after 24 hours. New replies are no longer allowed.