Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Credentials not saved for connection folders
#1
Hi,

Since a while (not sure exactly when) we're having issues with Private Credentials that are saved for Folders with Connections.

We have several customers that we manage, for each customer we have separate credentials (separate Active Directory domains, one per customer).
Our admins all have their own administrator account within those domains.
Our admins save their credentials as private credentials in the ASG database.
We configure a folder with connections to be used with a set of private credentials

After refreshing the folder tree (press F5 when standing on one of the folders) the saved credentials for that folder are "missing". In the Properties > Credentials > General tab, the "Default Values" are selected, instead of the "Personal Values". We can set them again and when checking the folder, it looks ok. However, after refreshing ASG again (or restarting the application) the setting is back to "Default Values" and connections require a manual credential entry again.

Each time we refresh or restart ASG, some folders are "broken" again.

This does NOT happen for all folders with credentials, only a few.

Is this behaviour a known issue? How can we fix it? Why are only a few folders not saving the credential settings per user?
Reply
#2
One question - each user can configure "personal assigned credentials" - in that case the Button "Personal Values" (in Properties Dialog) must be checked instead of "Default Values" - if you set personal credentials on "Default values" view only this user can see the credentials because they are private

If you do so it's a realy strange behavior... in ASG-RD 2012 you could only assign private credentials for your personal use - in ASG-RD 2015 you can assign it to "Default values" but in most cases it makes no sense - we have to change that or perhaps show a message that warns the user...
Regards/Gruss
Oliver
Reply
#3
Hi Oliver,

Credentials are obviously set in the Personal Values. We do see, however, that the Default Values sometimes have "Data Exists" listed but without credentials linked.

Could it be that someone in our organisation is setting their credentials in the Default Values and that our other users cannot see what they are, because they are Personal as you explained?

Is there a way to find out?
Reply
#4
"Could it be that someone in our organisation is setting their credentials in the Default Values and that our other users cannot see what they are"

Yes, that could be - but if other users set "Personal" that settings should not be overwritten - I will check this...

And yes, you can check if somebody updates your data - use the ChangeLog - there you can see who and when was updating data...
Regards/Gruss
Oliver
Reply
#5
Hi Oliver,

We've tested and the Default Settings do not overwrite the Personal settings. However, Personal Settings are not saved for each folder. Some are, some are not. Unfortunately we can't see if the problem exists when someone saves their Personal values. Even after refreshing the folder tree, the settings are gone again and we have to set the credentials for those folders again.

Regards,

Joris
Reply
#6
Only to be sure - are you using the latest patch version? Patch7 - 8.0.4916.1

I will try to setup an environment and will work with at least 2 or 3 users and try to reproduce...
Regards/Gruss
Oliver
Reply
#7
Hi Oliver,

I've tested with a copied database (we're not upgrading just yet because of the database upgrade needed) and the same thing occurs. When setting credentials for a specific folder it works, only until the folder tree is refreshed (F5) or ASG is restarted. After that the changes are lost and the settings are not saved to the database.

If you want I can make an export of the database and send it through WeTransfer. I can list a few examples of not working folders.

Grt, Joris
Reply
#8
That would be very helpful :-) Send me a private message with the download link - thanks
Regards/Gruss
Oliver
Reply
#9
So I found the data that causes this issue - and it will be fixed in the next Patch - I'm thinking about an sql script to help you immediately - but give me some time to ensure that this will not have any side effects :-) - we have 40°C outside - perhaps it's better to wait until monday :-)
Regards/Gruss
Oliver
Reply
#10
Cheers! Keep your head cool and we'll wait for the fix Smile
Reply
#11
Ok, I give you a script to clean up the objects - I checked on how many objects this inconsistence data exists - and the result was 2 :-)

DELETE FROM ItemPropertiesUsage WHERE RolePropertyId = 'DE830943-8687-4C45-AADE-1FC83C5BEDB6' AND UserId = '00000000-0000-0000-0000-000000000000'
Regards/Gruss
Oliver
Reply
#12
Hi Oliver,

Users report problems being solved! Thanks a bunch Smile

Regards,

Joris
Reply
#13
Thanks for give me access to the database - else I had never found this issue...
Regards/Gruss
Oliver
Reply




Users browsing this thread: 1 Guest(s)