In version 6.1.2 permissions per task/user were implemented and this is a GREAT help. I need this to go one step further, if possible.

We have a dynamicaly changing list of users that will need access to VisualCron for various functions. Now that we can create groups within VC and set permissions, this gets me a step closer to turning them lose within VC. However, this still requires that each user have their own entry in the Users list. This can be very unclean if that user were to leave the company or no longer need access to VisualCron due to their roles in our company changing, etc...

What i'm proposing is that instead of requiring individual usernames be added to the authenication list that an 'Active Directory Group' can be added with permissions much like the way a user is given permissions in 6.1.2

We manage all of our permissions within Active Directory so if we could have a 'VC_ReadOnly' group within our domain, i'd like to add that 'DOMAIN\VC_ReadOnly' group to VisualCron with 'ReadOnly' permissions. This way I only have to add a group, instead of each user individually. If the user were to either quit, change roles, etc... I would not have to go into VisualCron and clean up any lingering entries for that user. I would just remove the user from 'DOMAIN\VC_ReadOnly' and they would immediately no longer have access to VC.

Hopefully this makes sense.

Brian

This a very good feature request - I would also like to see this implemented.

I just thought I'd check and see if there was any further thought given to this or if I explained it in a way that made sense to the developer(s).

I'm still running an early beta version of 6.1.2 in our Q environment and am about to upgrade production (6.0.6) to 6.1.2 so I can at least get some permissions going and I realized I never checked to see if 'AD Group' permissions were implemented. As far as I can tell, they have not been, which is why I ask if there's any news :)

Thanks in advance,

Brian

AD group permissions have been implemented in 7.5.0. :

http://www.visualcron.co....aspx?g=posts&t=2790 

As there is no special documentation we outline the details here:

1. AD groups have now been removed from server settings
2. you know add AD groups from Manage User permissions->Select AD groups tab->Click Add
3. In this new window you select the default VC permission groups for this AD group
4. it is recommended that you remove all existing AD users by logging in with default VisualCron account before adding
5. if you experience any problems then turn on Extended debug logging and try again. Then look at the log_serverDATE.txt file. If you cannot tell what is wrong or feel that a bug exists then email us the file with details
6. when an AD user matches a group the AD user will be created with default AD group permissions. After that you can alter the specifics of this AD users

---

6. when an AD user matches a group the AD user will be created with default AD group permissions. After that you can alter the specifics of this AD users

Does that not then still leave individual AD Users in the permissions list? I dunno about what others think, but that's still not a traditional AD implementation for permissions. If I add the 'Server Team' group as 'Administrators', for instance.... and Joe, Mary, and Todd are members of it... each of them would get a new entry upon logging in that is unique to their ID. Now, lets say Mary changes roles in the company. No longer in IT, she chose to become a personal assistant (secretary). She should no longer have access to VisualCron, but based on what you described, she still would unless i manually went and cleaned up her ID. Now, as part of a role/job change, AD Groups would be evaluated by a security person and of course she'd be removed from the VC_Admins (or the like) AD Group, but it'd have no effect on whether or not she had access to VisualCron. That's sort of the purpose of the group, to validate you're part of the group and if so... let you do things. Not just validate you're in the group, and create a separate entry with the same permissions as the group. It's still messy, unless i'm completely misunderstanding.

Ideally, you could add AD Users OR AD Groups. If you're an AD user and your entry is not specifically listed, it'd validate you're part of one of the AD Groups that also have permission. Rather than creating an entry for that user, it should just know for the purposes of the current session (instance of the client) prior to logging out or closing the client, that the user has the same perms as the group had defined. Hopefully that makes sense.

I'm seriously happy with what has already been done. I just really think it needs to go a step further before being solved/completed.

Brian

6. when an AD user matches a group the AD user will be created with default AD group permissions. After that you can alter the specifics of this AD users

Does that not then still leave individual AD Users in the permissions list? I dunno about what others think, but that's still not a traditional AD implementation for permissions. If I add the 'Server Team' group as 'Administrators', for instance.... and Joe, Mary, and Todd are members of it... each of them would get a new entry upon logging in that is unique to their ID. Now, lets say Mary changes roles in the company. No longer in IT, she chose to become a personal assistant (secretary). She should no longer have access to VisualCron, but based on what you described, she still would unless i manually went and cleaned up her ID. Now, as part of a role/job change, AD Groups would be evaluated by a security person and of course she'd be removed from the VC_Admins (or the like) AD Group, but it'd have no effect on whether or not she had access to VisualCron. That's sort of the purpose of the group, to validate you're part of the group and if so... let you do things. Not just validate you're in the group, and create a separate entry with the same permissions as the group. It's still messy, unless i'm completely misunderstanding.

Ideally, you could add AD Users OR AD Groups. If you're an AD user and your entry is not specifically listed, it'd validate you're part of one of the AD Groups that also have permission. Rather than creating an entry for that user, it should just know for the purposes of the current session (instance of the client) prior to logging out or closing the client, that the user has the same perms as the group had defined. Hopefully that makes sense.

I'm seriously happy with what has already been done. I just really think it needs to go a step further before being solved/completed.

Brian

We could add an option to optionally always inherit permissions from group instead of using it own (clone of group).

---

We are now by default inheriting from ADGroup from last build. Optionally you can set it to override an use your own permissions after the AD user has logged on.

---

Good afternoon, Henrik. I just wanted to follow up on this. it has been quite some time and we are still using 7.2.1 and i'm now evaluating 8.0.4 on our test server. I still think the permissions are not as I requested when AD Groups are involved. The same situation i described one post previously is there.

AD Group = DOMAIN\VC_Admins
AD Group members: DOMAIN\Mary, DOMAIN\Todd, and DOMAIN\Brian

I remove all AD users from VisualCron. I then add the DOMAIN\VC_Admins group with default options (Active, and Let Users Inherit (not clone) permissions).

I then log into VisualCron as DOMAIN\Brian and a new AD User is created called 'Brian' with a Name, AD (Yes), Domain (DOMAIN), and FQDN of domain. This account has admin privelages within VC and all works as expected.

Fast forward 3 weeks from now. Brian has done something bad and has been demoted. He's now working in Sanitation and has absolutely no reason to have access to VisualCron but he still has a domain account, no longer a member of the DOMAIN\VC_Admins group, for purposes of checking e-mail and doing HR related items. In VisualCron, there's still an entry for 'Brian' that is a member of the built-in VC 'Administrators' permission group. Brian can still be destructive if he wishes due to VisualCron not caring or re-evaluating his membership of the DOMAIN\VC_Admins group. If he's removed from the AD Group that gave him permissions in the first place, there should be no more access, but the access remains.

My suggestion to create temporary sessions based on AD Group membership is still likely the way to go. There should be no permanent footprint in the User list if using AD groups and not explicit User additions.

Thoughts?

Brian

Hello,

we have the same problem within our Company. If anything in AD changes, VC does not recognize it. The Suggestion of bbusse seems to be a smart way to solve it. Other solution would be to remove a user from VC userlist if he is AD user and disconnects VC.

Quick and dirty Workaround:
Delete an AD user from userlist during disconnect. Disadvantage: Fields that use the usernames are not more filled correctly.

Bug in AD implementation:
If a user has two AD Groups that are linked in VC only one Group is assingned in VC.
e.g:
User: DOMAIN/Dennis
AD Groups: DOMAIN/Development, DOMAIN/VCAdmin
VC Groups: Development
Definition in VC AD Groups:
DOMAIN/Development -> Develeopment
DOMAIN/VCAdmin -> Administrator

The result of VC permissions is not correct. Correct would be to have assigned two Groups (Development AND Administrator).

Best regards
Dennis Reddin

I think the delete of AD user during disconnect may not be the best. The problem is that we lose the relationship between the user and things he has done during the time which makes it hard to follow the Audit log. I think it might be better to create a Task that syncs users with AD.

About the two groups bug. Please do this:

1. delete a user from VC that has two of the AD groups defined in VC
2. turn on extended debugging in server settings->Log
3. logon with that user
4. send the log log_serverDATE.txt along with the username and the two group names in VC and two AD groups names to support@visualcron.com

---

Has there been further development work on this as it appears the functionality is still the same ...

VC does not detect AD user group changes and therefore does not change the users associated VC Group.
VC does not remove users (or deactivate them) in the case a user is removed from all AD groups associated with VC.

Is there any plan to fix any of this?

Thanks.

Has there been further development work on this as it appears the functionality is still the same ...

VC does not detect AD user group changes and therefore does not change the users associated VC Group.
VC does not remove users (or deactivate them) in the case a user is removed from all AD groups associated with VC.

Is there any plan to fix any of this?

Thanks.

What you describe is different than original Feature request. We have no plans at the moment but if you need this now please contact sales@visualcron.com for custom development.

---

I think you're mistaken as what I've described lines up exactly with the last two users posts on this thread.

Your software is doing a one-time AD groups comparison for a user at first login.
If it finds the user is in an AD group that matches a group that has been pre-matched by a VC admin to a VC Group, it creates them as a user and gives them the VC group that matches that AD group.
HOWEVER > IMPORTANT: THIS IS THE THING PEOPLE ARE COMPLAINING ABOUT IN THIS THREAD<
Your software then no longer looks at a users association with AD groups.
- If I change a user's AD group to a different one, their access in VC doesn't update to reflect this.
- If I remove a user from all AD groups associated with VC, the user still has access to VC and doesn't lose his access rights to login to VC.
This is the problem and it is entirely in line with what this original thread was about.
It's described in post 9 by dre, post 8 by bbusse and continues back...

Request you re-review this post and if it's still not clear, reach out to me for a demo - I'm happy to show you first hand.

I think you're mistaken as what I've described lines up exactly with the last two users posts on this thread.

Your software is doing a one-time AD groups comparison for a user at first login.
If it finds the user is in an AD group that matches a group that has been pre-matched by a VC admin to a VC Group, it creates them as a user and gives them the VC group that matches that AD group.
HOWEVER > IMPORTANT: THIS IS THE THING PEOPLE ARE COMPLAINING ABOUT IN THIS THREAD<
Your software then no longer looks at a users association with AD groups.
- If I change a user's AD group to a different one, their access in VC doesn't update to reflect this.
- If I remove a user from all AD groups associated with VC, the user still has access to VC and doesn't lose his access rights to login to VC.
This is the problem and it is entirely in line with what this original thread was about.
It's described in post 9 by dre, post 8 by bbusse and continues back...

Request you re-review this post and if it's still not clear, reach out to me for a demo - I'm happy to show you first hand.

I see, there are multiple things. Mixed this up with another request about sub-domains support for AD.

---

I see, there are multiple things. Mixed this up with another request about sub-domains support for AD.

OK, now that you seem to agree this is an issue, can we get an ETA on fix? Upcoming release would be GREAT! This along with our request for Group MSA logins is top of our wishlist. We would have very little reason to ever leave VisualCron platform if these two issues are addressed.

Has this ever been fixed? If a user is no longer a member of a configured Active Directory group, do they get removed?