Dear Aqua Engineers, support
We are getting a lot of scrutiny, as ADS (we use 20.5) caches the connection property details and this can cause inadvertent auto-logins in query-analyzer and mishaps with users getting disciplined for PRODUCTION dataserver access.
For now, we are doing some quick after-the-fact monitoring on such accidental logins via ADS/query-analyzer.
Is there a feature we can file to prevent Password retentions in the .\datastudio\connections\<dataserver/connection File> so the user will be forced to re-enter the password and not accidentally connect
We are more concerned with standard logins, as integrated sqlserver logins will go through Kerberos via Active Directory.
"I showed the user the options settings for disabling the password but he wants a permanent option"
So is there a way for us to permanently disable "remember password" for users, as they could get savvy and enable "the remember password" ? we are coming under strict controls for ADS access to PRODUCTION, so this is a high priority for us.
Could we file this request for a future release ? this will come up more often due to security and regulatory purposes, as we are seeing folks transfer the connections files from one ADS to another and reuse connections :( a huge security hole).
229 KB
8 KB
Lisa, Lets discuss.
User also asked for the following if possible, "So where will the file -options -general save that setting in %USER%\.datastudio\XXXX. If you can let me know the XXX file we can do a windows CACLS attribute change and prevent them from overwriting it when we package the ADS20.5".
User also asked for the following if possible, "So where will the file -options -general save that setting in %USER%\.datastudio\XXXX. If you can let me know the XXX file we can do a windows CACLS attribute change and prevent them from overwriting it when we package the ADS20.5".
The customer is asking for an update on this request and asked that we escalate it. They are also asking for a one-off so that they can disable the password.
The customer is asking for an update on this request and asked that we escalate it. They are also asking for a one-off so that they can disable the password.
Let them know that we are investigating it...
Let them know that we are investigating it...
Ask the user if this disablement is company wide or for selected individuals/areas?
Ask the user if this disablement is company wide or for selected individuals/areas?
Its company-wide 100%.. we are using single-signon via kerberos predominantly, but this is mainly to thwart the password being transported under the guise of ADS.. Ideally if the users identity on windows/linux was hashed into the password , it would be less of a risk, as the userB would not be able to use it from UserA's ADS connection property file.
Its company-wide 100%.. we are using single-signon via kerberos predominantly, but this is mainly to thwart the password being transported under the guise of ADS.. Ideally if the users identity on windows/linux was hashed into the password , it would be less of a risk, as the userB would not be able to use it from UserA's ADS connection property file.
Hi John,
Actually, the file already exists. See attached. When the user opens and checks file->options->general->disable password saving and saves the options, a file called datastudio-lock.properties is generated. This file can then be locked, This file can also be generated and propagated to other users. One caveat that I found, if the user already has connections set up, they will have to open the server properties and save it in order for this to take effect.
And No, there is nothing in the documentation about this.
Hope it helps,
Tom
Hi John,
Actually, the file already exists. See attached. When the user opens and checks file->options->general->disable password saving and saves the options, a file called datastudio-lock.properties is generated. This file can then be locked, This file can also be generated and propagated to other users. One caveat that I found, if the user already has connections set up, they will have to open the server properties and save it in order for this to take effect.
And No, there is nothing in the documentation about this.
Hope it helps,
Tom
Customer comments:
Yes.. but the user can go in and change the datstudio-lock.properties and unlock it as it will be in %USER%\.datastudio and is editable location. We would want this to be in the c:\program files\aqua data studio 20.5 (x64) \datastudio-lock.properties as the user will not be able to edit it..
Customer comments:
Yes.. but the user can go in and change the datstudio-lock.properties and unlock it as it will be in %USER%\.datastudio and is editable location. We would want this to be in the c:\program files\aqua data studio 20.5 (x64) \datastudio-lock.properties as the user will not be able to edit it..
Hi John,
Per our conversation, this solution seems to work given this request. Now the customer is asking for something different. Please get them to clarify exactly what they need us to do because it is not completely clear to me.
Thanks,
Tom
Hi John,
Per our conversation, this solution seems to work given this request. Now the customer is asking for something different. Please get them to clarify exactly what they need us to do because it is not completely clear to me.
Thanks,
Tom
New comment from the customer:
So we have 1 user per 1 computer, and the connection propertiy file is on a NAS driver (z:) which is mapped to %USER%, so its private.
So userA before leaving the firm, copied his folder z:\.datastudio to userB who then try to access the Sybase dataserver with userA's saved credential.. got a failure and it was flagged as we have network filter based host filters which will catch userB trying to connect as he was not entitled to connect to that dataserver.
So are you saying that the password hash in the file, is strictly predicated on the user's credential as well, so its not really transferable?
All I am saying is::
Even if we have a disable (lock ) ADS property file, the user potentially can copy the folder from c:\program files \aqua data studio 20.5 x64 to a writeable folder c:\temp for example, remove the disable-save-password property and relaunch datastudio.bat (calling datastudio.exe).
So I am more looking for something bake into datastudio.exe which they cannot edit..
New comment from the customer:
So we have 1 user per 1 computer, and the connection propertiy file is on a NAS driver (z:) which is mapped to %USER%, so its private.
So userA before leaving the firm, copied his folder z:\.datastudio to userB who then try to access the Sybase dataserver with userA's saved credential.. got a failure and it was flagged as we have network filter based host filters which will catch userB trying to connect as he was not entitled to connect to that dataserver.
So are you saying that the password hash in the file, is strictly predicated on the user's credential as well, so its not really transferable?
All I am saying is::
Even if we have a disable (lock ) ADS property file, the user potentially can copy the folder from c:\program files \aqua data studio 20.5 x64 to a writeable folder c:\temp for example, remove the disable-save-password property and relaunch datastudio.bat (calling datastudio.exe).
So I am more looking for something bake into datastudio.exe which they cannot edit..
Hi John,
Since we don't know their environment, more questions. Is the ADS executable directory locked down for each user? Is there one copy that every one uses. If so, we can add a parameter in the ini to shut off password saving.
Thanks,
Tom
Hi John,
Since we don't know their environment, more questions. Is the ADS executable directory locked down for each user? Is there one copy that every one uses. If so, we can add a parameter in the ini to shut off password saving.
Thanks,
Tom
Yes, so every user has a separate desktop (and hence c:\program files aqua data studio 20.5 x64) and yes, this directory is absolutely locked down, so they cannot make changes in this directory.
But they can make changes in the z:\.datastudio directory (which is on a network drive but users are not able to access each others z: drive, so we are trying to stop malicious misuse which can be inadvertent as users tend to use ADS for weekly migrations).
So yes, if you can add it in the datastudio.ini, that will be locked down, and the users even if they make a copy, they will get flagged by the techrisk window10 check on running datastudio.exe from another nonstd location. We don't run this on linux, so we should be all cool if you can change the datastudio.ini to prevent ANY saving of password.
Yes, so every user has a separate desktop (and hence c:\program files aqua data studio 20.5 x64) and yes, this directory is absolutely locked down, so they cannot make changes in this directory.
But they can make changes in the z:\.datastudio directory (which is on a network drive but users are not able to access each others z: drive, so we are trying to stop malicious misuse which can be inadvertent as users tend to use ADS for weekly migrations).
So yes, if you can add it in the datastudio.ini, that will be locked down, and the users even if they make a copy, they will get flagged by the techrisk window10 check on running datastudio.exe from another nonstd location. We don't run this on linux, so we should be all cool if you can change the datastudio.ini to prevent ANY saving of password.
Hi John,
Asif is coding up a change that will allow Ivan to set a parameter in the .ini file. that disables password saving. This parameter will override the optional parameter in ADS. The .ini can be locked down and his users should not have the ability to enable it. More details to come. Please let Ivan know our strategy. We should be able to distribute it in a patch for 20.5. Need to do QA on it first.
Thanks,
Tom
Hi John,
Asif is coding up a change that will allow Ivan to set a parameter in the .ini file. that disables password saving. This parameter will override the optional parameter in ADS. The .ini can be locked down and his users should not have the ability to enable it. More details to come. Please let Ivan know our strategy. We should be able to distribute it in a patch for 20.5. Need to do QA on it first.
Thanks,
Tom
Thanks Tom. I've let Ivan know and he responded that this should fill the bill.
Thanks Tom. I've let Ivan know and he responded that this should fill the bill.
Hi,
We have introduced a new runtime property, -Dconnection.disable.save.password=true
If user sets the above Java runtime property to true, the Server Properties > Save password option will be ignored. While connecting to the DB server, user will be prompted for password including the ones which already have password saved.
The changes are available in SVN branch v20.5 r#58264.
@Tom, please review the changes and do some sanity testing.
Thanks
Asif
Hi,
We have introduced a new runtime property, -Dconnection.disable.save.password=true
If user sets the above Java runtime property to true, the Server Properties > Save password option will be ignored. While connecting to the DB server, user will be prompted for password including the ones which already have password saved.
The changes are available in SVN branch v20.5 r#58264.
@Tom, please review the changes and do some sanity testing.
Thanks
Asif
Hi Asif,
I did a build and got the ADS package ready for deployment. I did some basic testing and your fix is working fine. The only concern that I have is that the user has to type the password for different connections multiple times. That might get old but I think unavoidable since we can't store the password. Will do more testing over the weekend.
Thanks,
Tom
Hi Asif,
I did a build and got the ADS package ready for deployment. I did some basic testing and your fix is working fine. The only concern that I have is that the user has to type the password for different connections multiple times. That might get old but I think unavoidable since we can't store the password. Will do more testing over the weekend.
Thanks,
Tom
Thanks Tom for the update.
>> The only concern that I have is that the user has to type the password for different connections multiple times.
Since the customer does not want to save the password; there is nothing much we can do here.
Thanks Tom for the update.
>> The only concern that I have is that the user has to type the password for different connections multiple times.
Since the customer does not want to save the password; there is nothing much we can do here.
Hi John,
Please let our customer know that the new ADS version is available - V20.5.0-6 for them to download. To enable this feature, have them add something like vmarg.5=-Dconnection.disable.save.password=true to their C:\Users\...\ads-windows-x64-20.5.0-6\datastudio\datastudio.ini file. Please have them give it a try.
Thanks,
Tom
Hi John,
Please let our customer know that the new ADS version is available - V20.5.0-6 for them to download. To enable this feature, have them add something like vmarg.5=-Dconnection.disable.save.password=true to their C:\Users\...\ads-windows-x64-20.5.0-6\datastudio\datastudio.ini file. Please have them give it a try.
Thanks,
Tom
Hi,
Added the patch provided by Asif for the issue.
To prevent password detention and picking up already saved password from the configuration files:
add the runtime property
vmarg.5=-
Dconnection.disable.save.password=true to datastudio.ini file present in the installation directory.
SVN revision: #58495.
Thanks
Hi,
Added the patch provided by Asif for the issue.
To prevent password detention and picking up already saved password from the configuration files:
add the runtime property
vmarg.5=-
Dconnection.disable.save.password=true to datastudio.ini file present in the installation directory.
SVN revision: #58495.
Thanks
assigning to Amar for further action on this
assigning to Amar for further action on this
Issue #15816 |
Resolved |
Fixed |
Resolved |
Completion |
No due date |
Fixed Build 6 |
No time estimate |
Lisa, Lets discuss.