StrataFrame Forum / StrataFrame Application Framework / Role Based Security / Access to registry key denied with standard user level in windows / Latest Posts

RE: Access to registry key denied with standard user level in windows

Nadr S Rajab — Tue, 23 Oct 2007 12:35:13 GMT

Thanks, the try catch seems the easiest solution.

Nadr

RE: Access to registry key denied with standard user level in windows

Ben Chase — Tue, 23 Oct 2007 08:44:24 GMT

Well, you could create a custom method to try writing to the registry within a try/catch... catch the security exception that is thrown and you'll know the user has reduced privileges. Otherwise, you're probably down to using LDAP + System.DirectoryServices.ActiveDirectory or maybe some API calls.

RE: Access to registry key denied with standard user level in windows

Nadr S Rajab — Mon, 22 Oct 2007 23:51:15 GMT

How could I test for the users windows security level(ie restricted, standard, Administrator)?. Is there any method in Statraframe or would I have to use the windows API

Nadr

RE: Access to registry key denied with standard user level in windows

Ben Chase — Mon, 22 Oct 2007 09:10:24 GMT

The login form is trying to save off the username that was entered. The custom login form template does that for you, however, with restricted rights on the computer, you won't be able to do that. So, you'll need to modify your CustomLogin class to remove the writing of the registry value from the cmdOK_Click event handler.

Access to registry key denied with standard user level in windows

Nadr S Rajab — Sun, 21 Oct 2007 08:20:44 GMT

I've installed Role based security and everything works fine based on the following conditions.

While logging into a domain and the windows user account is set as power-user or Administrator then everything is fine. If the user logging is a restricted user (Windows users group) then I get the following error:

Access to the registry key 'HKEY_LOCAL_MACHINE\Software\MicroFour\StrataFrame\Security\LoginForm' is denied.

Source : mscorlib

Stack Trace:
at Microsoft.Win32.RegistryKey.Win32Error(Int32 errorCode, String str)
at Microsoft.Win32.RegistryKey.CreateSubKey(String subkey, RegistryKeyPermissionCheck permissionCheck, RegistrySecurity registrySecurity)
at Microsoft.Win32.RegistryKey.CreateSubKey(String subkey)
at Microsoft.Win32.Registry.SetValue(String keyName, String valueName, Object value, RegistryValueKind valueKind)
at MicroFour.StrataFrame.Win32.RegistryRepository.WriteValue(String ValueName, String Value)
at Primary_Reports.CustomLogin.cmdOk_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.PerformClick()
at System.Windows.Forms.Form.ProcessDialogKey(Keys keyData)
at System.Windows.Forms.ContainerControl.ProcessDialogKey(Keys keyData)
at System.Windows.Forms.TextBoxBase.ProcessDialogKey(Keys keyData)
at System.Windows.Forms.Control.PreProcessMessage(Message& msg)
at System.Windows.Forms.Control.PreProcessControlMessageInternal(Control target, Message& msg)
at System.Windows.Forms.Application.ThreadContext.PreTranslateMessage(MSG& msg)

The only way at the moment to get everyone up and running is to change there access level in windows. Is this by design or a bug?

Thanks

Nader