LDAP Group

[Carolanne Fougerat]

Is there a way to control the depth TES 6.1 can query AD Groups?          

For example, I created AD sec groups TESScheduler, TESMIgrators, TESOperator and TESInquiry. 

Inside AD group TESScheduler, I want to add another AD security group instead of an AD Account (user).

When I tried it, TES 6.1 will not recognize the AD security group inside the AD security group, it only works when I put in users.

Also, since moving the security policy to be associated to the LDAP Group, I can no longer impersonate the users.  I may have read this somewhere (probably since sec policy is no longer associated with user) does someone remember where this way mentioned?

[Marc Clasby]

I found similar limitation in our testing as well. I think that you will also notice the logging does translate the users in an ad group which was missing before. It looks like they addressed some 5.3.1 AD group issues that I had noticed but I think at the sacrifice of group within a group (Trade off)

This could probably be addresed in a future release, might be worth opening a case..

Marc

[Carolanne Fougerat]

Thanks for the response - I just wanted to check if maybe thre is a configuration setting that can be tweaked currently.  I will log a case since this will make it easier for me to get away from managing users.

Did have a followup question to get idea on how everyone else is using the LDAP group capability.    We are a very distributed in terms of the teams/workgroups - each team has total autonomy over their jobs and objects they own and job activity functions.

With help of consultants, this is what we have deviced and outline the challenges with it:

First we decided to use team's existing AD sec group to control the functional aspect of security (as in workgroup they have access to).  This ensures that Tidal access to workgroups  is always up to date - in case someone joins the team or leaves the team.

We then create an LDAP group for each workgroup (associating runtime users and agents on the LDAP group).  We took out any userse and agents out of the workgroups and moved them to LDAP group.

Then we created four new AD sec group to control what users can with the objects they have access to.

- TESScheduler

- TESOperator

- TESMigrator

- TESInquiry

Lastly in Tidal, we create the 4 LDAP groups for the security policy access linking it to the new AD sec groups.

So that for example, if Pete belongs to the Finance team and is a scheduler.  He is automatically in the Finance team AD sec group as soon as he is hired.  Then someone (TIdal Admind) adds him manually to the TESScheduler AD sec group - then voila he can log into Tidal with the appropriate access.

Challenges with this (aside from the bug I encounter when adding LDAP group to workgroup >_<):

- it wold be nice if I can add the team's AD sec group into TESScheduler (as mentioned in my orignal post)

- I am still having to be in the picture whenevr someone needs Tidal access granted or revoked because a central body needs to make sure that user is not in more than one of the sec policy AD group (TESScheduler, TESOperator, ...)  We have sold this LDAP group thing as a way for teams to finally control their own access but that is not the case really.

We have decided to live with this model but wondered if other implementations with distributed user bases have other ways to deal with this.  I can obviously open the 4 new sec policies for the teams to edit on their own but I cannot guarantee they will check for duplicates and not accidentally delete other folks etc.  Also, some folks who belong to multiple workgroup have to be handled differently since they may want to be schedulers for Finance but Marketing requires them to be operator only - which means they really can't be a scheduler.  In this case, they have to be an operator only to belong in both groups or not be in Marketing at all to get Scheduler privs.  Kind of goes against the cumulative access model that TIDAL 6 is based on.

[pmeyenburg]

First our experience is the same. TES can not read an AD-tree, You have to put users directly in the AD-groups in question for use in TES.

Second you have to be aware of that users (all including admins) should only have access through an LDAP group.

If a user is created directly in TES the security settings seems to be unpredictable, in the sense that the security settings on the user seems to take precedence over the LDAP-group/work-group settings.

In our installation we have completely erased all manual created users, and now access in only automatically given by the appropiate LDAP group.

[Carolanne Fougerat]

Thank you, yes I am currently piloting a few workgroups since we are still in our first pass of the upgrade so I can  understand and document quirks before rolling out to other workgroups.  The ones I have converted I did end up deleting their interactive user account first. 

One other thing that I have lost too after the conversion to LDAP Group  is the ability to see a user's workgroup and security policy easily.  Which means I have to go hunting on AD.  Am I missing something, this seems like a grave omission for TES Admins to not be able have within the GUI -  especially with losing the ability to impersonate an LDAP created user.

[Marc Clasby]

Carollane,

you bring up some interesting points I hope someone form the tidal side comments oin the cumulative access.. I am going to dig arround for the presentation/documentation that I remember seeing on how this should work. I think  that an individual user settings would trump the group so you could make your "multiple" group users individuals as a work arround. (however that gets you out of the automated add scenario).

on a side note you could keep AD groups in synch with windows powershell commands or scripts using the AD Module in a windows envrionment. Given the right rights you could event use a runtime users to keep this in synch for you on a scheduler basis.

Our needs are pretty simple from a security perspective as most users do not run jobs here so we don't have the need for multiple levels of AD groups. 

[Carolanne Fougerat]

Thanks Marc, yes I just took an excellent powershell training class prior to this upgrade so I intended to probably use powershell to generate my audits and potentially manage adding/deleting AD users to the sec policy AD groups.

Ironically, we have moved to Linux for this upgrade so I was a tad bummed that I can't use PowerShell now to manage the TES components.

From what I have read on this cumulative model - a user never loses privs, they just gain more.  Even in 5.3 this was always our dilemma, would be nice if a user can have multiple sec policy based on the workgroup.  Of course it will be messier to implement in LDAP group since I will require more AD sec groups (UGH).  And if I go to the LDAP model, I really do not want a mix of LDAP created and non LDAP created users.