I want to encrypt a file/folder using EncryptFile function while Impersonating another user, I gave the other user Full Control over the file, but I still get Access Denied.
HANDLE hUser;
if (LogonUser(L"test", L".", L"123", LOGON32_LOGON_NETWORK, LOGON32_PROVIDER_DEFAULT, &hUser) == TRUE) {
ImpersonateLoggedOnUser(hUser);
if (EncryptFile(dir_to_enc) == FALSE) {
printf("%d\n", GetLastError()); // I get 5 - Access Denied
}
RevertToSelf();
CloseHandle(hUser);
}
edit:
when I change the fourth parameter of LogonUser from LOGON32_LOGON_NETWORK to LOGON32_LOGON_INTERACTIVE, the error code changes to 87, ERROR_INVALID_PARAMETER.
I don't know why but when I change the dwLogonType to LOGON32_LOGON_BATCH everything works correctly!
It seems that it is used when we need to do something on behalf of the user.
but other types are not directly intended for that.
Related
I'm using MIP file sample command line interface to apply labelling.
When trying to apply a label that has protection set, i got "Label requires ad-hoc protection, but protection has not yet been set" error.
Therefore, I tried protecting the file using "--protect" option and got the following error message:
"Something bad happened: The service didn't accept the auth token. Challenge:['Bearer resource="https://aadrm.com", realm="", authorization="https://login.windows.net/common/oauth2/authorize"'], CorrelationId=ce732e4a-249a-47ec-a7c2-04f4d68357da, CorrelationId.Description=ProtectionEngine, CorrelationId=6ff992dc-91b3-4610-a24d-d57e13902114, CorrelationId.Description=FileHandler"
This is my auth.py file:
def main(argv):
client_id = str(argv[0])
tenant_id = str(argv[1])
secret = str(argv[2])
authority = "https://login.microsoftonline.com/{}".format(tenant_id)
app = msal.ConfidentialClientApplication(client_id, authority=authority, client_credential=secret)
result = None
scope = ["https://psor.o365syncservice.com/.default"]
result = app.acquire_token_silent(scope, account=None)
if not result:
logging.info("No suitable token exists in cache. Let's get a new one from AAD.")
result = app.acquire_token_for_client(scopes=scope)
if "access_token" in result:
sys.stdout.write(result['access_token'])
else:
print(result.get("error"))
print(result.get("error_description"))
print(result.get("correlation_id")) # You may need this when reporting a bug
if __name__ == '__main__':
main(sys.argv[1:])
I tried to change the scope to ["https://aadrm.com/.default"] and then I was able to protect the file, but when I try getting the file status or try applying label on it I get the same error message with bad auth token.
These are the permissions as configured in azure portal:
Thank you
I think that scope you have is incorrect: https://psor.o365syncservice.com/.default
It should be https://syncservice.o365syncservice.com/.default.
A good way to handle this is to just append .default to whatever resource the AcquireToken() call gets in the resource param. Something like this.
I am trying to enumerate a directory on a remote file server.
I want to use backup-semantics in order to not require administrator credentials.
On the test server, I have created a share:
Share permissions: everyone full control
NTFS permissions: only SYSTEM (I removed all others)
I am currently using this code:
static void accessWithBackupSemantics() {
NetResource netResource = new NetResource() {
Scope = ResourceScope.GlobalNetwork,
ResourceType = ResourceType.Disk,
DisplayType = ResourceDisplayType.Share,
Usage = ResourceUsage.Connectable,
RemoteName = #"\\target-srv\TargetShare"
};
// open "net use" connection
int netResult = Native.WNetAddConnection2(netResource,
#"***password***",
#"DOMAIN\backup_op_user",
0);
if (netResult == 0 || netResult == 1219) {
// enable privileges
// (this is taken from AplhaFS)
using (new PrivilegeEnabler(Privilege.Backup)) {
try {
// try open remote directory
SafeFileHandle fsHandle = Native.CreateFile(
#"\\target-srv\TargetShare",
EFileAccess.GenericRead,
EFileShare.Read | EFileShare.Write,
IntPtr.Zero,
ECreationDisposition.OpenExisting,
EFileAttributes.BackupSemantics,
IntPtr.Zero);
Console.WriteLine("Handle is valid: " + !fsHandle.IsInvalid);
}
catch (Exception ex) {}
finally {
Native.WNetCancelConnection2(netResource.RemoteName, 0, true);
}
}
}
}
PrivilegeEnabler class is taken from AlphaFS
Native win32 structures and flags are taken from pinvoke.net/kernel32.createfile
This works if I specify "DOMAIN\Administrator" in the username, but does not work (the error is 5 - access denied) if I try to use a domain account that is a member of the local "Backup Operators" on target-srv server.
I have also examined the security event log on target-srv, for every connection created with WNetAddConnection2 a "Special Logon" event is written. The details of this event include the list of privileges that the logon account was given.
In both cases (when I connect with administrator or with backup_op_user) - seBackupPrivilege is indeed listed.
I tried to give extra privileges to the "Backup Operators" so the list has all the privileges that the Administrator has - but it made no change.
Questions:
What is the right way to use Backup-Semantics over the network?
How come it works with Administrator and not with a member of "Backup Operators" - are there additional implicit permissions for the Admin?
I have seen many examples of local use of Backup-Semantics, but not one that can be used over the network - please don't reply with links to examples of local usage.
I'm trying to implement rebooting of a remote computer with InitiateShutdown API using the following code, but it fails with RPC_S_SERVER_UNAVAILABLE or 1722 error code:
//Process is running as administrator
//Select a remote machine to reboot:
//INFO: Tried it with and w/o two opening slashes.
LPCTSTR pServerName = L"192.168.42.105";
//Or use 127.0.0.1 if you don't have access to another machine on your network.
//This will attempt to reboot your local machine.
//In that case make sure to call shutdown /a /m \\127.0.0.1 to cancel it.
if(AdjustPrivilege(NULL, L"SeShutdownPrivilege", TRUE) &&
AdjustPrivilege(pServerName, L"SeRemoteShutdownPrivilege", TRUE))
{
int nErrorCode = ::InitiateShutdown(pServerName, NULL, 30,
SHUTDOWN_INSTALL_UPDATES | SHUTDOWN_RESTART, 0);
//Receive nErrorCode == 1722, or RPC_S_SERVER_UNAVAILABLE
}
BOOL AdjustPrivilege(LPCTSTR pStrMachine, LPCTSTR pPrivilegeName, BOOL bEnable)
{
HANDLE hToken;
TOKEN_PRIVILEGES tkp;
BOOL bRes = FALSE;
if(!OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken))
return FALSE;
if(LookupPrivilegeValue(pStrMachine, pPrivilegeName, &tkp.Privileges[0].Luid))
{
tkp.PrivilegeCount = 1;
tkp.Privileges[0].Attributes = bEnable ? SE_PRIVILEGE_ENABLED : SE_PRIVILEGE_REMOVED;
bRes = AdjustTokenPrivileges(hToken, FALSE, &tkp, 0, (PTOKEN_PRIVILEGES)NULL, 0);
int nOSError = GetLastError();
if(bRes)
{
if(nOSError != ERROR_SUCCESS)
bRes = FALSE;
}
}
CloseHandle(hToken);
return bRes;
}
So to prepare for this code to run I do the following on this computer, which is Windows 7 Pro (as I would do for the Microsoft's shutdown tool):
Run the following "as administrator" to allow SMB access to the logged in user D1 on the 192.168.42.105 computer (per this answer):
NET USE \\192.168.42.105\IPC$ 1234 /USER:D1
Run the process with my code above "as administrator".
And then do the following on remote computer, or 192.168.42.105, that has Windows 7 Pro (per answer here with most upvotes):
Control Panel, Network and Sharing Center, Change Advanced Sharing settings
"Private" enable "Turn on File and Printer sharing"
Set the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
LocalAccountTokenFilterPolicy=dword:1
RUN secpol.msc, then go to Local Security Policy, Security Settings, Local Policies, User Rights Assignment. Add "Everyone" to "Force shutdown from a remote system". (Just remember to remove it after you're done testing!)
Note that the following shutdown command seems to work just fine to reboot the remote computer:
shutdown /r /m \\192.168.42.105 /t 30
What am I missing with my code?
EDIT:
OK. I will admit that I was merely interested in why InitiateShutdown doesn't seem to "want" to work with a remote server connection, while InitiateSystemShutdownEx or InitiateSystemShutdown had no issues at all. (Unfortunately the latter two did not have the dwShutdownFlags parameter, which I needed to pass the SHUTDOWN_INSTALL_UPDATES flag to, which caused my persistence...)
At this point I had no other way of finding out than dusting out a copy of WinDbg... I'm still trying to dig into it, but so far this is what I found...
(A) It turns out that InitiateSystemShutdownEx internally uses a totally different RPC call. W/o too many details, it initiates RPC binding with RpcStringBindingComposeW using the following parameters:
ObjUuid = NULL
ProtSeq = ncacn_np
NetworkAddr = \\192.168.42.105
EndPoint = \\PIPE\\InitShutdown
Options = NULL
or the following binding string:
ncacn_np:\\\\192.168.42.105[\\PIPE\\InitShutdown]
(B) While InitiateShutdown on the other hand uses the following binding parameters:
ObjUuid = 765294ba-60bc-48b8-92e9-89fd77769d91
ProtSeq = ncacn_ip_tcp
NetworkAddr = 192.168.42.105
EndPoint = NULL
Options = NULL
which it later translates into the following binding string:
ncacn_np:\\\\192.168.42.105[\\PIPE\\lsarpc]
that it uses to obtain the RPC handle that it passes to WsdrInitiateShutdown (that seems to have its own specification):
So as you see, the InitiateShutdown call is technically treated as Unknown RPC service (for the UUID {765294ba-60bc-48b8-92e9-89fd77769d91}), which later causes a whole bunch of credential checks between the server and the client:
which, honestly, I'm not sure I want to step into with a low-level debugger :)
At this stage I will say that I am not very well versed on "Local Security Authority" interface (or the \PIPE\lsarpc named pipe configuration.) So if anyone knows what configuration is missing on the server side to allow this RPC call to go through, I would appreciate if you could post your take on it?
I need to know if a specified directory (local or shared path with login credentials) has write permissions or not.
I am using GetFileAttributes but it always returns FILE_ATTRIBUTE_DIRECTORY and nothing else.
My code is something like below
if(storageLocation != "")
{
//! check if local storage - user name password would be empty
if(storageUsername == "" && storagePassword == "")
{
//! local storage
//! lets check whether the local path is a valid path or not
boost::filesystem::path fpath(storageUsername.c_str());
if(boost::filesystem::exists(fpath))
{
DWORD attrib = ::GetFileAttributes(storageLocation.c_str());
if((attrib != INVALID_FILE_ATTRIBUTES) &&
((attrib & FILE_ATTRIBUTE_READONLY) != FILE_ATTRIBUTE_READONLY))
{
string strWritePermission = "TRUE";
}
}
}
else
{
uncLocation_t uncLocation;
uncLocation.m_location = storageLocation;
uncLocation.m_username = storageUsername;
uncLocation.m_password = storagePassword;
if(0 == connectToUNCLocation(uncLocation)) // My function to connect to UNC location
{
//! successful connection
DWORD attrib = ::GetFileAttributes(storageLocation.c_str());
if((attrib != INVALID_FILE_ATTRIBUTES) &&
((attrib & FILE_ATTRIBUTE_READONLY) != FILE_ATTRIBUTE_READONLY))
{
string strWritePermission = "TRUE";
}
}
}
}
I don't understand why but GetFileAttributes always return 0x16.
I have tested it by creating a shared folder and creating 2 folders in it. One with read only permissions and other with default permissions. But in all 3 cases (shared folder, read only folder and default permission folder) I am getting same return value.
There is on way to find write permission, to create a temporary file (usinf CreateFile in GENERIC_WRITE mode) and if successfully created, delete it. But I don't want to use this method as I don't want my application to create a temporary file each time user specifies a location.
Please suggest what should be done.
You would need to replicate the security checking that Windows performs. The AccessCheck function will help that. You are currently well wide of the mark in looking at the file attributes. Windows security is so much more complicated than that.
Although you said you did not want to do it, the right solution is not to try to check. Simply do whatever it is you are attempting to do. If the system decides that the user does not have sufficient rights, then CreateFile will fail, and the last error will be set to ERROR_ACCESS_DENIED. There's no need for temporary files. You just try to do whatever it is you are doing, and let it fail. You have to handle failure anyway since there are many ways for a file operation to fail, not just security.
As the saying goes, it is better to ask forgiveness than permission.
I think you are looking for AccessCheck. FYI, this is not a C++ question, but a Windows API question.
Does anybody know whether there's a way of finding out whether a particular file system location is accessible under the sandbox?
I want to test whether a particular file is accessible under the normal Powerbox rules; that is has already been added to the power box using the open/ save dialog, etc.
Can I do this before triggering a sandbox exception?
Can I catch a sandbox exception?
Best regards,
Frank
You can use the OS access() system call for a quick and simple test, from man access:
#include <unistd.h>
int access(const char *path, int amode);
The access() function checks the accessibility of the file named by path
for the access permissions indicated by amode. The value of amode is the
bitwise inclusive OR of the access permissions to be checked (R_OK for
read permission, W_OK for write permission and X_OK for execute/search
permission) or the existence test, F_OK. All components of the pathname
path are checked for access permissions (including F_OK).
If path cannot be found or if any of the desired access modes would not
be granted, then a -1 value is returned and the global integer variable
errno is set to indicate the error. Otherwise, a 0 value is returned.
You could pretty this up for Objective-C using something like:
typedef enum
{
ReadAccess = R_OK,
WriteAccess = W_OK,
ExecuteAccess = X_OK,
PathExists = F_OK
} AccessKind;
BOOL isPathAccessible(NSString *path, AccessKind mode)
{
return access([path UTF8String], mode) == 0;
}
A few things. Always use fileSystemRepresentation when you need a path string. Also, R_OK is adequate if you just want to know if there is a hole in the sandbox for the specified path.
-(BOOL)isAccessibleFromSandbox:(NSString*)path
{
return( access( path.fileSystemRepresentation, R_OK) == 0 );
}