Hi,
This is a weird use case. Our JIRA environment is technically in our production environment, since we have a lot of automation that ties JIRA to various production monitoring and tools. Currently we have our Crowd instance in a DMZ zone, so that it can enable our environment to authenticate with our corporate Active Directory (non-prod environment) via ldap servers that are also in a non-prod environment. This works most of the time – except that the DMZ zone is in a data center that is less than stable, and we have taken outages because the crowd server goes offline occasionally.
We do have a fail-over crowd instance in our production environment as well – but since it can't directly communicate with our non-prod ldap servers, we end-up having to use locally-based authentication when we have an outage for our ldap users – not ideal. However, this environment works fine for our external customers, who are already locally authenticated in crowd.
Our production environment, despite network limitations re: connectivity to the non-prod ldap servers, is much more stable than the DMZ zone we currently use for crowd. We'd like to make the production instance of our crowd our primary instance, and find some means of having crowd talk to the non-prod ldap servers, without the need of the DMZ zone. Our Security team has already nixed the idea of some sort of direct connection between prod and non-prod. (understandable).
We do have several reverse-proxy apache servers in our production environment however – is it possible to set up a reverse proxy between crowd and an ldap server? Our Security team says if we could do something like that, it would satisfy their concerns about a production instance of crowd talking with a non-prod ldap server.
Anyone run into something like this before?
Oh, and if you are curious, we are already using SSL certs between crowd and our ldaps.
Hope that made sense.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.