Grouper Users - Open Discussion List

[Jeffrey Williams <>]

Apologies, hit send a little early.

On Thu, Feb 15, 2018 at 4:14 PM, Jeffrey Williams <> wrote:

UNCG is running TIER's Grouper 2.3 container in production and we're looking to promote our LDAP loader config into production.

I've been working on a dual git repo setup where one contains the various Grouper configurations and needed modifications to the container, while the other contains the more senstive parts of the config that need not be included if we were to share our config with others.

vtldap seems to put a wrench into this with not seeming to handle ciphered passwords as indicated in the docs.  I had the idea of using loader.config hierarchy as follows:

# comma separated config files that override each other (files on the right override the left)  

loader.config.hierarchy = classpath:grouper-loader.base.properties, file:/opt/ext-conf/ldap.ADLdap.pass, file:/opt/etc/grouper-loader.properties, file:

/opt/etc/grouper-loader-pspng.properties

I had drop the unciphered ldap.ADLdap.pass variable into a separate file on a separate folder and let the loader read that first, followed by the rest of grouper-loader.properties.  This way, when we test ciphered LDAP loading creds again, we can reference the ciphered file in grouper-loader.properties with no additional changes.

Observations: It seems that while this configuration pans out in a loader-only scenario(i.e. apache, tomcat are not started), if I spin up a UI/WS only container, I get a bind error.  If I drop the unciphered PW back into grouper-loader.properties and restart the container, calling the loader job from the UI returns the same result as calling it from gsh session on the loader.

Question: Is there a significant difference in how the UI calls a loader job vs. how the daemon calls it?

--

Jeffrey Williams, Identity Management Specialist
Identity Architecture, ITS
University of North Carolina at Greensboro
256-TECH (256-8324)