Child pages
  • North Dakota State University Grouper Contribution

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Finish sentence

...

  1. AD Groups/Department share - we are slotting this solution in to our existing processes quickly. This may not be the most ideal, but it is working for. Custom template application will query AD and Grouper, and find AD groups in an OU that aren't in Grouper yet. Domain Admins will be able to pretty much do a one click create of the Grouper layout. Groovy message daemon routes these messages as a drop in replacement for legacy system. The AD code can serve out of both IAM systems for different groups during migration.
  2. AD Owners - this is just a standard owners group on an AD group, but this will be retransmitted through RabbitMQ so that a description field on the AD group is updated to match owners, making it easier on our domain admins.
  3. CMS Authors/Publishers - We run our Typo3 instance with two levels of permissions per workspace. Each is marked and will be retransmitted through the Groovy daemon
  4. Entitlements - Flung back out via RabbitMQ to be added to AD user using Powershell
  5. LISTSERV - We perform a full population of various LISTSERV lists each morning. In this case Groovy code crawls that app stem looking for groups with that marker, populating the named list in the attribute with members. We have an additional attribute on lists where necessary to populate addresses that aren't Grouper subjects.
  6. Other - Catch all of everything else. For instance we populate basis groups with student fee information, and use application groups to setup what becomes permissions to use facilities on campus. For example, staff can take classes, but don't pay fees, thus they can't use the gym for free.

...