According to this web site about SMB access masks,
MAXIMUM_ALLOWED (0x02000000) - This value indicates that the client
is requesting an open to the file with the highest level of access
the client has on this file. If no access is granted for the client
on this file, the server MUST fail the open with
STATUS_ACCESS_DENIED.
GENERIC_ALL (0x10000000) - This value
indicates a request for all the access flags that are previously
listed, except MAXIMUM_ALLOWED and ACCESS_SYSTEM_SECURITY.
I'd like to know what are common use cases for using these. Specifically, if I wanted to be maximally permissive, shouldn't I use GENERIC_ALL? And though it says in its description that it doesn't include MAXIMUM_ALLOWED, because it includes the previously mentioned access flags wouldn't GENERIC_ALL therefore also subsume MAXIMUM_ALLOWED? I have a feeling I'm missing some important concept.
Related
I'm currently trying to integrate an SSO with Active Directory. The SSO Service has told me that my server is responding with LDAP "referrals".
Is there a way to disable these referrals? There is only one server/domain, and the server is the domain controller, so I don't know why I would even be getting these in the first place. Any help is appreciated. Thanks!
Turns out it was that the "base DN" in the search wasn't specific enough. Apparently you'll get a referral if you don't pinpoint into the exact OU or CN that the user resides. Since I only really have one active OU I just hard-pointed it to there and everything seems to be working now.
Instead of port 389, use the Microsoft-specific port 3268.
From MSDN:
Avoid unnecessary SearchResultReference referral chasing
With referral chasing enabled, your code could go from domain to domain in the Active Directory tree trying to satisfy the request if the query cannot be satisfied by the initial domain. This method can be extremely time-consuming. When performing a query for objects and the domain for the objects is unknown, use the global catalog as a base for the search instead of using referral chasing.
then:
Connecting to the Global Catalog
There are several ways to connect to a global catalog. If you are using LDAP, then use port 3268 in the ldap_open or ldap_init calls.
You may think everything is satsified by the initial (only!) domain, but...this is a bureaucracy, and list of 1 thing is still a list.
When you create a Security Group, you can make it Global or Domain Local. If the user belongs to a Global Group, like my case, AD automatically assumes there may be more information to be found in the Global Catalog, so a query to port 389 will generate 3 references. There's probably other reasons references are triggered.
I had to solve this issue because I had many OUs directly below the top level, all of which I wanted to query in one authentication pass.
In particular the mod_ldap.c of ProFTPd was distracted by these referrals. It followed them in separate LDAP transactions without binding with the same credentials as the initial query. Although they added nothing, the ldap library must have returned an opaque error.
I have been attempting to access different OID's with no luck and significant research has lead me to believe that snmp is just configured to protect these parts of the system and I simply don't have access. How do I change the configuration to allow access to all OID's?
Or, how do I create a user who requires no authentication and no encryption (no priv)?
I looking for an API method that retrieve the info that "net view /domain" does.
namely, I'm looking for a way to enumerate the visible domains within a forest, using win32api (in C environment)
thanks.
Update:
it seems that DsEnumerateDomainTrusts can do what I need, however, it doesn't looks like net.exe importing it, so I'd still like to know of other options.
Update2:
as it's name imply, the function only enumerate trusted domain, even when DS_DOMAIN_IN_FOREST is specified,
so I'm in square 1.
I think that in your case the best way is to interrogate Active directory.
You will find in this answer the way to get all the domains in your directory, first requesting "rootDSE" to find the configuration naming context, second requesting for crossRef with nETBIOSName to retreive domain entries
As you are interested in how to interrogate active directory from native code, you may have a look to LDAP C-Binding API as discribed in RFC 1823 specifies, Microsoft support it, see MS Strategy for Lightweight Directory Access Protocol (LDAP). You'll find the using and reference manuals of the Microsoft API in Lightweight Directory Access Protocol.
In Unix, when doing some action on behalf of some user, a system program usually calls seteuid(UID) (with accompanying setegid()) to switch to that user first, perform the action, and on finish switch back to superuser using seteuid(0). I time seteuid() and it's in the order of one to several microseconds (meaning, it's quite cheap relative to the action that needs to be done like manipulating files or running a CGI program).
I'm not familiar with Windows API. Do we do the same thing on Windows (but using ImpersonateLoggedOnUser() + RevertToSelf() API functions)? In general, how fast are these functions?
It is mostly the same, but there is one important difference to keep in mind : the Windows API you mentionned require a HANDLE to a valid token.
In other words, even running as SYSTEM (or any process that has SeTcbPrivilege), you need to impersonnate a logged on user.
The user can be logged on many ways :
Interactive with at a physical computer
Through a Remote Desktop Session
Pretty much any Microsoft network connections like file shares, name pipes, mailslots, RPC and all the others built on top.
Creating a process will make it inherit the current token in most cases.
It does not matter whether you used Kerberos, NTLM or maybe HTTP BASIC auth in IIS. It's all authenticated by Windows, so you get a token. On the other hand, an HTTP BASIC authentication in Tomcat will not give you a Windows token, so impersonation is out of reach.
Now with the tricky part.
When you think about it, a token is really just a memory structure with access control lists for authorisation (DACL) and auditing (SACL). It is created by an Authentication Package (AP). It is the AP that creates the token. And somewhat like a PAM in Unix, an AP can be replaced by custom code.
As a matter of fact, an open source setuid Authentication Package exist. Folks who ported CVS to Windows NT did the work of writing an AP that creates a token out of thin air, as long as your have the SeTcbPrivilege (root equivalent). I have never tried it, but it could give a token on the local machine for a user that is absent. The code is rather old (it will only create elevated tokens) but besides that, it LGTM. There is no authentication, no password or smart card involved, so a process running with that made up token will not be able to use it to authenticate to another computer.
To conclude :
The general idea is the same
If you play by the rules, you will only be able to impersonate a logged on user, regardless of the login procedure or location
You can change that behavior, but it
Impersonation is probably just as fast in Unix and Windows, as the inner workings are roughly similar. Chances are you will not notice the difference.
A suggestion : my copy of Programming Windows Security is all yellow from coffee, with post-it notes hanging out and torn pages. The best text ever on the subject, a must read if you want to understand Windows security.
follow up to: Windows Filesystem Minifilter Drivers: can I monitor and prevent FS operations using them?
I'm looking for a method to filter access to certain file system resources.
This includes removable media and non-ntfs file systems - so standard ACL won't work.
from what I read, a files system driver filter might be helpful - but I didn't find a way to get the user id of the initiating user.
Is this possible?
other recommendations \ references to existing tools are also welcome.
I am not sure what does "user id" mean. But this might be useful:
When handling IRP_MJ_CREATE look at IrpSp->Parameters.Create.SecurityContext->AccessState.
ACCESS_STATE contains SecurityDescriptor and SubjectSecurityContext.
From SubjectSecurityContext you can retrieve PACCESS_TOKEN if you need it (call SeLockSubjectContext and SeQuerySubjectContextToken).
Have a nice day!
In most cases obtaining security information (token) of the user that initiated the call is possible, at least for operations such as file open and directory enumeration (and these are main points of filtering when you plan to prevent access of the user to the resource). And then you can cancel or modify request as you need. The only limitation I can think of is when the network redirector accesses the disk on behalf of the remote user impersonated as local system account. But these are border cases that you would need to investigate yourself in your particular task.