Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Shaun E on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Requested Registry Access is Not Allowed

Status
Not open for further replies.

KreativeKai

Programmer
Nov 12, 2004
33
US
We have several applications that will be executing on multiple machines. These applications will be placed on our network and setup with an xcopy style of deployment. To accomplish this task, we had to adjust the Framework configuration, Code Access Security for the machine to Full Trust for Local Intranet applications.

We created a deployment package and we execute this on any machines that will execute the apps.

These apps also have a feature where we write messages to the eventlog when an error is encountered. This works great for our clients that have Power user or admin rights, but for a standard user the eventlog post fails with a message that "Requested Registry Access is Not Allowed".

There are Permission Sets within the framework configuration tool, but I'm not sure what the best approach is to accomplish allowing standard clients the permisiion to write to the eventlog without opening security up too much.

Any suggestions would be appreciated!
 
You should use impersination
try this code.

Code:
<SecurityPermissionAttribute(SecurityAction.Demand, _
        ControlPrincipal:=True, UnmanagedCode:=True)> _
        Private Shared Function GetWindowsIdentity(ByVal UserName As String, _
        ByVal Domain As String, ByVal Password As String) As WindowsIdentity
            Dim SecurityToken As Integer
            Dim Success As Boolean
            Success = LogonUser(UserName, Domain, Password, Logon.NetworkCleartext, Provider.Windows2000, SecurityToken)
            If Not Success Then
                Throw New System.Exception("Logon Failed. Error: " & _
                  GetLastError())
            End If
            GetWindowsIdentity = New WindowsIdentity(New _
                                                     IntPtr(SecurityToken))
        End Function

        Public Shared Sub ImpersonateAdministrator(ByVal Impersonate As Boolean)
            On Error GoTo errortrap

            Dim newidentity As WindowsIdentity
            Dim oldidentity As WindowsIdentity
            Dim Username, Domain, Password As String

            If Impersonate = True Then
                newidentity = GetWindowsIdentity("acountname", "domainname", "Password")
                NewContext = newidentity.Impersonate
            Else
                NewContext.Undo()
            End If

            Exit Sub

errortrap:
            Resume Next
        End Sub

Christiaan Baes
Belgium

If you want to get an answer read this FAQ faq796-2540
There's no such thing as a winnable war - Sting
 
I posted the problem to several websites, and you were'nt the only feedback that talked about impersination. Our team just wasn't sure if this was the right approach for us.

Here is what we came up with:
1) Security is the hitch when a standard client tries to write to the application eventlog. The app searches for the eventsource in the registry and when it cannot find it, tries to create one. Due to the rights, it fails and causes our error.

2) We have a class that we wrote for use in our shop, which can be referenced in any program, and if called, can display a message box, write to the eventlog and e-mail, depending what parameters are set. We check if the event source is there. If not, we try to create the event source. If the create fails we notify the client that they need to call us and run a process we call DeployEventSource.

3) We wrote an app (DeployEventSource) which creates the eventsource and is basically setup to be installed by our team with admin or power user rights. We wanted to try to to eliminate as much maintenance as possible and I believe we accomplished this goal. Since our class above writes to a source name that we keep consistent, and our install / create source program creates a source with the same name, we only have to run the install app when someone gets a new machine or system reload. If profiles change with terminations / new hires, we do not have to keep reinstalling or hacking a registry setting. Also we can create several apps that run on this pc which uses our class to write to the eventlog, and as long as the eventsource was created once, it will work for all apps.

I hope this follow-up might help someone else who runs into the same problem. Thanks for your input Chrissie!!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top