Grouper Users - Open Discussion List

[Andrew Jason Morgan <>]

I meant to look at Grouper's logs for PSPNG actions.  However, those don't provide much detail about actions unless you turn up the log level a bit.  We use:

# Provisioning PSPNG

log4j.logger.edu.internet2.middleware.grouper.pspng = INFO

log4j.logger.edu.internet2.middleware.grouper.changeLog = INFO

It's a bit chatty, but not bad.  Otherwise, PSPNG doesn't log much at all.

I don't see anything obviously wrong with your config, but I wonder how safe it is to use cn=group.extension.  Group extensions aren't unique in Grouper unless you have a validator to block them.  Did the cn of the groups that were deleted from AD match the extensions of the groups you deleted from test:ad?  That would imply that groupSearchBaseDn isn't being applied consistently...

If that's the case, maybe you can set the log level to INFO and run a test with a group name that won't impact users.

Andy

---

From: Weston, Todd <>
Sent: Sunday, September 20, 2020 9:06 AM
To: Andrew Jason Morgan <>; <>
Subject: RE: Head Scratcher...

 

[This email originated from outside of OSU. Use caution with links and attachments.]

We have a Splunk instance running that shows security logs from AD that show the group object deletions being performed by the Grouper AD service account from the IP address of the Grouper app server – fairly certain they originated from there. And the time stamps of the deletions match when I did the GSH removeGroup commands. The Grouper app logs are sent to a syslog server that feeds into Splunk.

 

As for PSPNG configs – the basic template is:

 

changeLog.consumer.pspng_activedirectory.class = edu.internet2.middleware.grouper.pspng.PspChangelogConsumerShim

changeLog.consumer.pspng_activedirectory.type = edu.internet2.middleware.grouper.pspng.LdapGroupProvisioner

changeLog.consumer.pspng_activedirectory.quartzCron = 0 */15 * * * ?

changeLog.consumer.pspng_activedirectory.ldapPoolName = active_directory

changeLog.consumer.pspng_activedirectory.isActiveDirectory = true

changeLog.consumer.pspng_activedirectory.memberAttributeName = member

changeLog.consumer.pspng_activedirectory.memberAttributeValueFormat = ${ldapUser.getDn()}

changeLog.consumer.pspng_activedirectory.groupSearchBaseDn = OU=grouper Groups,OU=Provisioned Groups,...,DC=ad,DC=wsu,DC=edu

changeLog.consumer.pspng_activedirectory.allGroupsSearchFilter = objectclass=group

changeLog.consumer.pspng_activedirectory.singleGroupSearchFilter = (&(objectclass=group)(cn=${group.extension}))

changeLog.consumer.pspng_activedirectory.groupCreationLdifTemplate = dn: cn=${group.extension}||cn: ${group.extension}||objectclass: group||sAMAccountName: ${group.extension}

changeLog.consumer.pspng_activedirectory.userSearchBaseDn = OU=NIDs,OU=WSU Accounts,DC=ad,DC=wsu,DC=edu

changeLog.consumer.pspng_activedirectory.userSearchFilter = wsuExternalSystemID=${subject.id}

changeLog.consumer.pspng_activedirectory.userSearchScope = SUBTREE

changeLog.consumer.pspng_activedirectory.userSearchAttributes = dn,cn,userprincipalname,wsuExternalSystemID,objectclass

otherJob.pspng_activedirectory_full.class = edu.internet2.middleware.grouper.pspng.FullSyncStarter

otherJob.pspng_activedirectory_full.quartzCron = 0 0 0 * * ?

 

All lines for each provisioner are in common (copy and paste) save their _pspng_<provisioner name>_ and the OU BaseDN.

pspng_activedirectory is our ‘test’ provisioner and is not assigned to a production OU. The rest are fairly self-explanatory by name:

 

changeLog.consumer.pspng_ad_campus_affiliates.groupSearchBaseDn = OU=Affiliates,OU=Campus Groups,OU=Provisioned Groups,...,DC=ad,DC=wsu,DC=edu

changeLog.consumer.pspng_ad_campus_employees.groupSearchBaseDn = OU=Employees,OU=Campus Groups,OU=Provisioned Groups,...,DC=ad,DC=wsu,DC=edu

changeLog.consumer.pspng_ad_campus_students.groupSearchBaseDn = OU=Students,OU=Campus Groups,OU=Provisioned Groups,...,DC=ad,DC=wsu,DC=edu

changeLog.consumer.pspng_ad_role_affiliates.groupSearchBaseDn = OU=Affiliates,OU=Role Groups,OU=Provisioned Groups,...,DC=ad,DC=wsu,DC=edu

changeLog.consumer.pspng_ad_role_employees.groupSearchBaseDn = OU=Employees,OU=Role Groups,OU=Provisioned Groups,...,DC=ad,DC=wsu,DC=edu

changeLog.consumer.pspng_ad_role_students.groupSearchBaseDn = OU=Students,OU=Role Groups,OU=Provisioned Groups,...,DC=ad,DC=wsu,DC=edu

 

-

Todd Weston

Information Security Analyst

Washington State University

Phone 509.335.4479

 

From: Andrew Jason Morgan <>
Sent: Sunday, September 20, 2020 7:59 AM
To: ; Weston, Todd <>
Subject: Re: Head Scratcher...

 

Todd,

 

Do Grouper's logs show the deletion of the groups?  You may be able to gain an understanding of PSPNG's actions by following the logs.  I have not seen this problem before, but I've spent a lot of time investigating PSPNG...

 

Also, do you mind sharing your PSPNG config?

 

Thanks,

Andy

 

---

From: <> on behalf of Weston, Todd <>
Sent: Saturday, September 19, 2020 6:07 PM
To: <>
Subject: [grouper-users] Head Scratcher...

 

[This email originated from outside of OSU. Use caution with links and attachments.]

OK – this is one I cannot explain – any clues would be appreciated.

 

We are building our second instance of Grouper (Prod this time) and have used all GSH commands to build out the entire structure.

 

I added one of the seven provisioners to a test folder and made three groups which all provisioned in AD as expected. Only the “test:ad” folder below had the pspng attribute and value applied:

 

The other six provisioners defined were to be applied to the  affiliates, employees and students folders in “wsu.edu:bundle:ad:campus.groups” and “wsu.edu:bundle:ad:role.groups” folder once the test groups were confirmed. All seven provisioners have a unique OU in the directory structure – naming in AD is similar to the folder structure in Grouper.

 

While only the one test provisioner was in place, I noticed that there were two classes of employee groups and two classes of student groups that had naming capitalization inconsistencies with our AD groups. I’m not sure if that would have been a problem, but I wanted to clean them up. So I made a list of the groups needing changes, ran a GSH script to remove them and regenerate them with the updated spelling version. All of our bundle groups are composites and no provisioning attributers had yet been applied to the folders. I didn’t even think to worry. The groups I deleted (which were empty and not provisioning) via GSH caused their counterparts in AD to delete – a behavior I would expect if provisioning were in place. We were able to restore the groups via the AD recycle bin, but the result was that thousands of employees and students lost critical group memberships – but wouldn’t realize until the following day when their Kerberos and SAML tickets expired.

 

Does anyone have any idea about how this would have occurred? I’ve triple checked the folders and the groups for provisioner attributes and there are none.  I’m wondering if there is more juice in GSH to look at grouper-loader properties and find groups being removed via shell? Totally scratching my head over this. I’m fairly certain I won’t do anything to cause a repeat, but the circumstances seem fishy.

 

-

Todd Weston

Information Security Analyst, Identity |

Information Technology Services | Washington State University

Phone 509.335.4479 PO Box 641222 Pullman, WA  99164-1222