Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

Yes all envs read the properties files similarly

 

From: [mailto:] On Behalf Of Jeffrey Williams
Sent: Thursday, February 22, 2018 12:35 PM
To: Redman, Chad <>
Cc:
Subject: Re: [grouper-users] Re: loader.config.hierarchy question

 

Turned out to be an issue on where that instance of grouper-loader.properties was landing in the image upon build.  Once I had that adjusted, it works as expected.

 

Thanks for the follow-up.

 

 

 

 

On Thu, Feb 22, 2018 at 12:08 PM, Redman, Chad <> wrote:

Hi Jeffrey,

 

I tried to replicate this with a demo server, but in my case both gsh and the UI worked. I am trying with the most recent 2.3 source code, which should be close to a patched system but not exact. By encrypted password, I assume this means the MorphString utility, right? I tried it both encrypted and plain, and either way it worked. Does your config look similar to either one of these? Was there a stack trace with the bind error?

 

 

PLAIN

 

classes/grouper-loader.properties

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

                ldap.ADLdap.url = "ldap://localhost:389

                ldap.ADLdap.user = cn=manager,dc=example,dc=edu

 

/opt/ext-conf/ldap.ADLdap.pass

                ldap.ADLdap.pass = secret

 

 

ENCRYPTED

 

classes/grouper-loader.properties

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

 

                ldap.ADLdap.url = "ldap://localhost:389

                ldap.ADLdap.user = cn=manager,dc=example,dc=edu

                #ldap.ADLdap.pass = /opt/ext-conf/ADLdap.pass

 

classes/morphString.properties

                encrypt.key = /opt/ext-conf/morphString.pass

 

 

/opt/ext-conf/ldap.ADLdap.pass.morphFile

                ldap.ADLdap.pass = /opt/ext-conf/ADLdap.pass

 

/opt/ext-conf/morphString.pass

                Ech6Rosh9KapCas3

 

/opt/ext-conf/ADLdap.pass (this is "secret" encrypted)

                SwZFCPoqbjfg8u0nuF3O/g==

 

 

 

You can try these diagnostic calls in GSH to verify things are working, but it sounds like GSH wasn't the problem.

 

GrouperLoaderConfig.retrieveLdapProfile("ADLdap").getPass()

 

import edu.internet2.middleware.morphString.Morph

Morph.decryptIfFile("/opt/ext-conf/ADLdap.pass")

 

 

-Chad

 

 

 

From: [mailto:] On Behalf Of Jeffrey Williams
Sent: Thursday, February 15, 2018 4:27 PM
To:
Subject: [grouper-users] Re: loader.config.hierarchy question

 

final follow-up:

grouper-loader.properties has its ldap.ADLdap.pass variable commented out, so the variable read from the prior /opt/ext-conf/ldap.ADLdap.pass should have been its only definition.

 

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

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)

 

--

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

 

--

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