Changes in 5.6.5

[FEATURE] Client: Added Active Directory filter for searching groups/users
[BUGFIX] TrayClient: Settings are now saved in Local application data folder
[BUGFIX] Server: Fixed a problem deleting empty sub folders in File Delete Task
[BUGFIX] Client: Fixed some issues in Permissions (Add) created in 5.6.4.

---

Hi,

Again I will test to make an AD login user and will try to login with it.

1st issue:
When I add a AD user in the 'Manage Servers' window, it stills shows up as an admin user, but it isn't. One is the AD user. It is not clear which is which. I like to see something like [AD User] as username.

2nd issue:
There is no popup anymore telling you to enable the AD login process. Was this intentionally left out?

3th issue:
I can not add/delete users anymore in the Users/Logon tab of the server settings. My settings are discarded after clicking on Apply Settings. Same for groups.
In previous beta I setup some users, they are still checked so I can login with these users for now.

4th issue:
When I logged with the AD user (yes it worked!!) I still see the admin username in the client as logged on user. However, the good username is showing up in the user permissions and in the modified by fields of jobs/tasks.

5th issue:
see my comment about the run job with/without conditions in previous beta. It is still an issue.

6th issue:
see my comment about the task 'List AD Object Paths' in previous beta. It is still an issue.

7th ... no there is no 7th...
The AD filter is working nicely.

This was a fast check.

Regards,
Erik

---

4th issue:
When I logged with the AD user (yes it worked!!) I still see the admin username in the client as logged on user. However, the good username is showing up in the user permissions and in the modified by fields of jobs/tasks.

Where in the Client do you see the wrong/bad username?

---

5th issue:
see my comment about the run job with/without conditions in previous beta. It is still an issue.

I am not sure where you click. Please remember that it is context sensitive in a way that Run with Conditions is not visible if no Conditions exists in the Job. Perhaps we should make it disabled instead of hidden.

---

4th issue:
When I logged with the AD user (yes it worked!!) I still see the admin username in the client as logged on user. However, the good username is showing up in the user permissions and in the modified by fields of jobs/tasks.

Where in the Client do you see the wrong/bad username?

I highlighted in the picture what I mean.
I logged on with an AD user, but due to the fact that the Manage Servers user is still admin I can not see my logged on username.

Regards
Erik

---

5th issue:
see my comment about the run job with/without conditions in previous beta. It is still an issue.

I am not sure where you click. Please remember that it is context sensitive in a way that Run with Conditions is not visible if no Conditions exists in the Job. Perhaps we should make it disabled instead of hidden.

Here you can see my right click on a job when I just started the client.
The 2nd picture shows the same right click on a job, but I clicked on the cross sign in front of the job, selected the 1st task and reselected the job. Than I right clicked the job again, and now you can see the difference.
The job and all the tasks arn't using any conditions.

Regards,
Erik

---

3th issue:
I can not add/delete users anymore in the Users/Logon tab of the server settings. My settings are discarded after clicking on Apply Settings. Same for groups.
In previous beta I setup some users, they are still checked so I can login with these users for now.

I managed to add one more user today, but I can't reproduce it...

Regards,
Erik

---

There is also an issue with loosing credentials in the file rename task.

See this post 

Regards,
Erik

---

Here is the latest version which should include most of the fixes to what is mentioned here.

---

HI,

Thanks for this new release. 😁

I checked the same points and I must say this is a big visual improvement.

1st issue:
solved.

3rd issue:
solved.

4th issue:
solved.
I have one remark however: I think you should add the '[AD]' text also in the CreatedBy and ModifiedBy fields in the job. What if a local user is called the same way as the AD user? You won't see the difference.. So adding the '[AD]' to the name should fix most cases.

6th issue:
solved.

Issue 2 may not be an issue any more, that's up to you.
Issue 5 however is still there.

---

😨 😨
I was thinking, hmmm now I can add a AD user to the manage servers window, and I see directly which user I am. What if the AD user I want to add isn't myself...
Than I remembered that these settings are user dependent, so the other AD user himself has to add an entry into the list. What about the rights at this time?
Does this new AD user have admin rights?
It is not possible to previously add an AD user to the user permissions list. It looks like (at the moment) that this is an easy way to get all the right there are. Not something you want 😊.

So how to solve this..

I think when you add the users/groups in the AD logon list, you have to create these also in the user permission list. The admin can than setup the rights before the AD users login.
Got me thinking how to solve this for an AD group, the users are dynamic...
One other thing is that I can delete the user permission role of the currently logged on user. This is funny.. What rights do I have at that moment?

So there are some things to think about..

Thanks for so far, good job all!

Regards,
Erik

---

Thanks for the feedback Erik.


2. This should be fixed

4. We agree and will make this change for next version

5. not sure if this can be fixed - I mean, if clicking on the + will let us be able to retrieve the right row but we will test this

To our questions and some questions Anton had:

There seems to be no way of pre registering a AD user. The only way to add a AD user to VC is for him to logon.

Our idea was initially that we should not have AD search etc in two different places. We were thinking that since AD is used most of the administration should be done outside VC like creating a special VC group in AD and add users from there.

You cannot clone an existing AD users permissions

No, we probably need to disable this if we do not allow the former.

This implies that any group/user you give permission to – the users would have full access to the system until an administrator assign individual permission restrictions.

We had one idea that you should be able to select between two predefined permission roles. Admin and Reader/Viewer. All new users that logs in will get this role and then the Admin can update it later.

One other thing is that I can delete the user permission role of the currently logged on user.

We will fix this. Thanks for notifying us.

---

Please let us know what you think about the above answers and solutions.

---

We were thinking that since AD is used most of the administration should be done outside VC like creating a special VC group in AD and add users from there.

The VC security model has no concept of what a Group/Role is. I really think that introducing the AD Group concept is a bad idea until you can map it to something similar in VC. You now have to maintain the users in a Group both in AD and have individual accounts in VC; There is really no benefit because you still maintain individual rights per VC Account (which you cannot clone). The trouble with the current implementation is that the authentication of a user using AD (which is all this feature should be doing) is changing how VC behaves and creating forks in the security code, in effect, 'the tail is wagging the dog’.

We had one idea that you should be able to select between two predefined permission roles. Admin and Reader/Viewer. All new users that logs in will get this role and then the Admin can update it later.
....
Quote:
You cannot clone an existing AD users permissions
No, we probably need to disable this if we do not allow the former

Things are administratively more complex instead of easier. We maintain 5 VC servers each with potentially different security settings; Now I have to wait until a user actually logons to a VC Server so that their account gets created, if they have access to all servers, that is 5 phone calls to set them up. Because I cannot clone the security rights from another user I have to remember and manually give each user their correct rights. There is no report in VC that allows me to compare the security matrix of all users. Cloning is the only way I can correctly sync security rights amongst a group of VC Users….

As a way forward, allow the Admin when adding or cloning a VC user to update the IsAd flag to true and let them type in the AD account into the Username Field. The only additional check is to make sure the AD account is unique which you do in anycase.


Regards
Anton

The VC security model has no concept of what a Group/Role is. I really think that introducing the AD Group concept is a bad idea until you can map it to something similar in VC. You now have to maintain the users in a Group both in AD and have individual accounts in VC; There is really no benefit because you still maintain individual rights per VC Account (which you cannot clone). The trouble with the current implementation is that the authentication of a user using AD (which is all this feature should be doing) is changing how VC behaves and creating forks in the security code, in effect, 'the tail is wagging the dog’.

I am not sure if we are talking about the same thing here. There is no way to map Windows security to VC security restrictions. That is why our security will be a layer on the Windows security.

I was just saying it is easier to point out a group. However, as I mentioned we are not complete with the current implementation. Please read next reply.

Things are administratively more complex instead of easier. We maintain 5 VC servers each with potentially different security settings; Now I have to wait until a user actually logons to a VC Server so that their account gets created, if they have access to all servers, that is 5 phone calls to set them up. Because I cannot clone the security rights from another user I have to remember and manually give each user their correct rights. There is no report in VC that allows me to compare the security matrix of all users. Cloning is the only way I can correctly sync security rights amongst a group of VC Users….

I am not sure cloning is the best alternative. I am thinking that we could add a button that adds all users allowed - and users in group as a user permission whenever you want. So, pressing this button (which is located in the Logon settings tab) will add all non-exising users. You can then go and edit the permissions. What do you think about that?

We believe that cloning may just be error prone when you enter details, especially as some details like SID may be hard to look up. Adding another search/find in the permissions is not a good option as well. It is better to control this in one page.

---

I agree, that authentication into VC should not affect the security rights. But at the moment it does, in that you have chosen to include AD Groups as a method of authentication. This is a dynamic list of users and possibly nested groups, hence that although you can reliably authenticate the user there is no way to link a user to a correct security profile until an intervention from a VC Administrator after the fact (at the moment the new user takes on Admin status). This is very different to using just an AD User since there is a one-to-one relationship to a VC user; you should be able to create a VC User, link the VC User to an AD Account and create or hopefully copy an existing security profile before the user logons onto a VC Server. I am not dismissing AD Groups at all, but I think the functionality is premature. If you were able to create roles in VC (requested for a while now) with its own security profile, link an AD Group to this role, then the problem of the dynamic nature of groups would be partly resolved in that any new user created via an AD logon would inherit the Roles profile.

That said, I really require 2 things to work.
To be able to link an AD Account to an existing VC user or when creating a new VC user. Administratively you cannot wait until a user decides to logon to a VC server (so that the VC account can be created) and then create the necessary security profile.
Secondly to accurately copy the security profile of one user to another.

Regards
Anton

To be able to link an AD Account to an existing VC user or when creating a new VC user. Administratively you cannot wait until a user decides to logon to a VC server (so that the VC account can be created) and then create the necessary security profile.

I was suggesting the button where you add all selected users (in Logon tab of server settings - then you don't have to wait for logon). Maybe this is not interesting at all.

We will look into in adding a very simple user-only search to the "Add" permissions tab.

Secondly to accurately copy the security profile of one user to another.

We will test various ways to do this.

Main reason that we hesitated for the search in Add window is that we did not want two instances of same functionality. Creating clone/copy without search would be hard to do without search.

---

Quote:
To be able to link an AD Account to an existing VC user or when creating a new VC user. Administratively you cannot wait until a user decides to logon to a VC server (so that the VC account can be created) and then create the necessary security profile.

I was suggesting the button where you add all selected users (in Logon tab of server settings - then you don't have to wait for logon). Maybe this is not interesting at all.

I don't mind this at all - it will certainly work.

You can then go and edit the permissions. What do you think about that?

If you can then clone/copy the permissions from one user to another or many users (even better).

Regards
Anton

Attached is an updated version with a search button in the Permissions window. Cloning should also work.

We removed user search in Server settings because these two settings collided a bit. Still, group search is in settings.

---

Hi,

I did some testing with the 5.6.5-3 version.

When I delete my own user permission I get an pop-up telling me that deleting will end my current session. Nice.
When I do so, I'm still in business, I'm not disconnected. I can edit a task. The change of a taskname isn't showed in the main overview, but when I edit the task again I can see my changed name. This might not be an issue when I'm really logged off.

I deleted my own user permission and wanted to create it again. I searched for my AD account and added it... VC is now not responding and the add user permission window is not closing for more than a minute. After the windows closes I'm not in the list of users. So the adding had failed, but again, I'm logged in as an AD user and I deleted my user permissions. This might not be an issue when I'm really logged off.

When I delete a user permission, the user permission window closes. This is unhandy. The window should stay until I want it to close.

I disconnected myself and logged on again... did not work due the the fact of the missing user permissions. That's good.

I logged on as admin and added my AD user account again. The Name field is empty in my AD and so it is empty in the user permission listing. I only see [AD]. You might ant to place the ad username in here. This field is always filled.
Due to the empty name field, I see also only the [AD] in the modified-/created by fields in the main overview.

I can also inactivate my own user permissions by clicking on the checkbox in my user permissions. This gives me no visual feedback that this results in a disconnect. It should behave the same as deleting the account.

With inactive user permission s I'm still able to edit jobs and I can see the changes directly in the main overview.

When I disconnect and want to log in again, I get the message that the user is inactive so it doesn't log in. That's good.

I can see the cloning works for AD users. Also the permissions are set.


I do like the discussion about custom permission roles and attach an AD user/group or a local VC user to it. When an AD user logs in, his username should be used in all the modifications.

Now we have two places for adding AD content, one for groups and one for users. I think it is better to have it in one place.


Lot of text this time.

Regards,
Erik

---

Hi,

I did some testing with the 5.6.5-3 version.

When I delete my own user permission I get an pop-up telling me that deleting will end my current session. Nice.
When I do so, I'm still in business, I'm not disconnected. I can edit a task. The change of a taskname isn't showed in the main overview, but when I edit the task again I can see my changed name. This might not be an issue when I'm really logged off.

I deleted my own user permission and wanted to create it again. I searched for my AD account and added it... VC is now not responding and the add user permission window is not closing for more than a minute. After the windows closes I'm not in the list of users. So the adding had failed, but again, I'm logged in as an AD user and I deleted my user permissions. This might not be an issue when I'm really logged off.

When I delete a user permission, the user permission window closes. This is unhandy. The window should stay until I want it to close.

I disconnected myself and logged on again... did not work due the the fact of the missing user permissions. That's good.

I logged on as admin and added my AD user account again. The Name field is empty in my AD and so it is empty in the user permission listing. I only see [AD]. You might ant to place the ad username in here. This field is always filled.
Due to the empty name field, I see also only the [AD] in the modified-/created by fields in the main overview.

I can also inactivate my own user permissions by clicking on the checkbox in my user permissions. This gives me no visual feedback that this results in a disconnect. It should behave the same as deleting the account.

With inactive user permission s I'm still able to edit jobs and I can see the changes directly in the main overview.

When I disconnect and want to log in again, I get the message that the user is inactive so it doesn't log in. That's good.

I can see the cloning works for AD users. Also the permissions are set.


I do like the discussion about custom permission roles and attach an AD user/group or a local VC user to it. When an AD user logs in, his username should be used in all the modifications.

Now we have two places for adding AD content, one for groups and one for users. I think it is better to have it in one place.


Lot of text this time.

Regards,
Erik

Thanks Erik,

yes, the popup works but we had some problems notifying the Client fully that it was disconnected. Adding this would require a change in the protocol etc. which in turn would require that Client and Server would be the same version. We will probably fix this for next "big" change which requires protocol.

For now, the Client is disconnected from Server - hence the hanging and strange behavior as the Server is not responding. Not optimal but will be fixed another time.

As for the name we do not want to mix to much of "username" and name. Maybe we will add a username column instead (in the permissions window). This way you will see everything that is missing and there in the AD.

Same with changing permissions on yourself. We will fix that for next protocol change.

It is complex where to store information and display configuration and still be backwards compatible. That is why we needed to split the allowed Groups and individual permissions. There is a big difference in background functionality as well. I think we need to keep it this way,

---

I finally got a chance to look at the new changes to the AD Integration. I am really happy with the new implementation of registering a VC user to an AD account. The main benefit I believe is that there is now a consistent way a VC user is managed with either native security or AD security. You can also clone the permissions across VC Users which will save a lot of frustrations.

Personally I still don’t see much benefit for adding in AD Group functionality right now; IMHO the entire Logon Settings Tab can be removed.

I would really like to advance the discussion of Role based security where the current permission structure is moved away from VC Users into Roles (Groups); VC users are then simply linked into a Role. It will make maintaining a consistent permission set across numerous users a lot easier to manage. Hopefully one day we could link Roles to Tasks ...

To the VC development team thanks for allowing and responding so positively to input from your customers.

Anton

I finally got a chance to look at the new changes to the AD Integration. I am really happy with the new implementation of registering a VC user to an AD account. The main benefit I believe is that there is now a consistent way a VC user is managed with either native security or AD security. You can also clone the permissions across VC Users which will save a lot of frustrations.

Personally I still don’t see much benefit for adding in AD Group functionality right now; IMHO the entire Logon Settings Tab can be removed.

I would really like to advance the discussion of Role based security where the current permission structure is moved away from VC Users into Roles (Groups); VC users are then simply linked into a Role. It will make maintaining a consistent permission set across numerous users a lot easier to manage. Hopefully one day we could link Roles to Tasks ...

To the VC development team thanks for allowing and responding so positively to input from your customers.

Anton

We will continue soon with discussion about roles. Thanks for your patience.

---

Please continue discussion about Roles here:

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

---

A user found a security issue in Active Directory logon which is fixed in a version attached to this post:

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

---