none
GetDirectories - Attempted to perform an unauthorized operation RRS feed

  • Question

  • Hi,

    The solution from this thread works (thanks Edward for sharing the code) :

    https://social.msdn.microsoft.com/Forums/vstudio/en-US/f3cb7279-3f1e-4bf1-a732-32b4bc54e9db/getdirectories-attempted-to-perform-an-unauthorized-operation?forum=wcf

    BUT !

    It only works if the user has physical access to the server. What I mean is : it works if the user can physically logon on the server. The problem is : most domain users cannot sit in front of the server screen and enter his username and password. This is simple not allowed as a regular domain user. So access is still denied for those users. We temporarily solved this by using a server admin account, so it's working for now, but I was wondering how to grant access to just a simple domain user account?

    Here is the error log :

    An account failed to log on.

     

    Subject:

           Security ID:         NETWORK SERVICE

           Account Name:        WSE2012R2$

           Account Domain:             HOLSTRA

           Logon ID:            0x3E4

     

    Logon Type:                 2

     

    Account For Which Logon Failed:

           Security ID:         NULL SID

           Account Name:        docmaster

           Account Domain:             HOLSTRA

     

    Failure Information:

           Failure Reason:             The user has not been granted the requested logon type at this machine.

           Status:              0xC000015B

           Sub Status:          0x0

     

    Process Information:

           Caller Process ID:   0x3260

           Caller Process Name: C:\Program Files (x86)\UltiDev\Web Server\UWS.AppHost.Clr4.AnyCPU.exe

     

    Network Information:

           Workstation Name:    WSE2012R2

           Source Network Address:     -

           Source Port:         -

     

    Detailed Authentication Information:

           Logon Process:       Advapi 

           Authentication Package:     Negotiate

           Transited Services:  -

           Package Name (NTLM only):   -

           Key Length:          0

     

    This event is generated when a logon request fails. It is generated on the computer where access was attempted.

     

    The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

     

    The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

     

    The Process Information fields indicate which account and process on the system requested the logon.

     

    The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

     

    The authentication information fields provide detailed information about this specific logon request.

           - Transited services indicate which intermediate services have participated in this logon request.

           - Package name indicates which sub-protocol was used among the NTLM protocols.

           - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

    Thanks a lot for any help !

    Best regards

    Friday, May 19, 2017 8:39 PM

Answers

  • Hi Steve,

    >>He wants a solution without turning on this setting. When this setting is on, it is working like a charm.

    I am afraid the only option is to use available account for all unavailable user.

    Regards,

    Edward 


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, June 29, 2017 3:01 AM

All replies

  • >>The problem is : most domain users cannot sit in front of the server screen and enter his username and password. This is simple not allowed as a regular domain user.

    How did you share the Folder? Did you set the access permission for all domain user? If so, I think you could try impersonate a client on a service to use the Folder, you could refer below link.

    #How to: Impersonate a Client on a Service

    https://msdn.microsoft.com/en-us/library/ms731090(v=vs.110).aspx

    In my option, I would suggest you keep using a server admin account. For security side, it is secure, all the client is valid by windows authentication. For operation side, you just need to set permission for this admin account instead of grant for all the users.


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, May 22, 2017 1:54 AM
  • Hi Edward,

    Thanks for the reply. For me, it's fine to use a admin account, but the network administrator here doesn't agree with me :-(

    Problem is, some customers don't buy their server from us and it will be a tough sell to tell them to use a admin account. Even it's secure, customers can be tough. The logical argument will be : "User A has access to these folders through the windows explorer. He has full access there to write/delete whatever files or folders. Why your webservice doesn't allow the same thing if User A tries to do exactly the same: writing a file to one of these folders?"

    And in fact I can't say he's wrong with his argument. I don't understand why a user account has full access to certain folders and with the same user credentials, access is denied from the webservice.

    Here is the code (the one you provided, thx again).

    using (new Impersonator(ImpersonatorUserName, ImpersonatorDomain, ImpersonatorPassword)) {
        File.WriteAllBytes(ServerPath + "\\" + request.FileName, request.Content);
    }
    

    For me, I wouldn't mind to use the solution you said: using a admin account and use that account for all users, but they don't buy it here :-(  I hope you can help me out please, I'm afraid I'm stuck.

    Many thanks and best regards, Steve

    Tuesday, May 30, 2017 10:19 AM
  • >> I don't understand why a user account has full access to certain folders and with the same user credentials, access is denied from the webservice.

    How did you get the username and password for the customers in your own service?

    It is amazing you could pass the username and password which should come from end customers.

    Anyway, I made a test with this, there is no problem.

    Here are my test steps.

    1. Create a WCF Service with the current code

    2. Share one Folder to my partner who could not login my computer.

    3. fill the username and password

    4. Run the WCF Service, it works correctly.


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, May 31, 2017 6:53 AM
  • Hi Edward,

    Thanks for reply.

    Here is how I tested it. We installed our service on the server of the customer. The webservice is part of a windows 10 app we are selling. So when a customer buys the app, a network engineer installs the webservice on their server. The customer has to provide a user account. The folder on that server is shared and that user has full access to that folder where the uploads should arrive. Form the windows explorer he can create new files or copy/paste files there.

    Let's say this is the account information we received from our customer :

    Domain: CustDomain

    User: CustUser

    Password: CustPassword

    using (new Impersonator(CustUser, CustDomain, CustPassword)) {
        File.WriteAllBytes(ServerPath + "\\" + request.FileName, request.Content);
    }
    This fails :

    Failure Information: 

    Failure Reason: The user has not been granted the requested logon type at this machine.

    This works :

    Domain: CustDomain

    User: AdminUser

    Password: AdminPassword

    Same code.

    Strange the same thing is working with you. I will try again, maybe I overlooked something.

    Thanks Edward, best regards...

    Thursday, June 1, 2017 7:05 AM
  • >> Failure Reason: The user has not been granted the requested logon type at this machine

    Per to this error, it seems the user could not login the machine. Could you share us how did you install the web service? Did the web service run under this user account? Has your service run correctly? I think you need to run the web service under local account group who are able to login in the machine or network service account.

    To check whether this error is related with “Impersonator”, I would suggest you make a test with other methods, will other methods get the same error?

    To check whether it is related with customer’s environment, I suggest you make a test in your company group.

    In addition, I suggest you check whether below link works for you which grants the permission.

    # Error Message: The user has not been granted the requested logon type at this computer

    https://technet.microsoft.com/en-us/library/cc732593%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    Friday, June 2, 2017 5:23 AM
  • Hi Edward,

    As usual sorry for the late reply. Had other priorities last week and I must say I ended up in a impasse with our network administrator.

    "Neither the user account nor any of the groups it belongs to has been granted the Allow log on locallyuser right."

    You are right : Allow log on localy is turned off and our administrator is unwilling to turn it on. According to him, it is considered a security hole. He wants a solution without turning on this setting. When this setting is on, it is working like a charm.

    I'm at my wits end...

    Best regards, Steve


    Wednesday, June 28, 2017 2:12 PM
  • Hi Steve,

    >>He wants a solution without turning on this setting. When this setting is on, it is working like a charm.

    I am afraid the only option is to use available account for all unavailable user.

    Regards,

    Edward 


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, June 29, 2017 3:01 AM
  • Hi Edward,

    Finally... Dispute settled and admin group is used for the upload...

    Thanks and best regards

    Friday, July 14, 2017 1:18 PM