i have windows service which is deployed using service.msc using c#,
i want to access the current logged in users download folder
eg: if the current logged in username is admin, then i want to access
C:\Users\admin\Downloads
and if the current logged in username is tomas, then i want to acess
C:\Users\tomas\Downloads.
You can use SHGetKnownFolderPath(FOLDERID_Downloads), passing in a token for the desired user account. The trick will be in knowing which user you want. There may be more than one user logged in at the same time. There may be no users logged in at all. If your service is running under the SYSTEM account, it can enumerate active user sessions via WTSEnumerateSessions() and get their user token via WTSQueryUserToken().
Related
I have a web application which is largely a content system - that is, it displays help for another system. It doesn't matter who views it. However, there is a list of users I would like to display, and also provide a way to edit the list. On that one page I want to detect the user's Active Directory information, and if the user is in the list of users authorized to change the data, then display an edit icon button to provide a means of editing some element. I do not need nor want Windows Authentication determining whether the user can get to the page, only to discobver the user's logon creds.
In short, I want this:
// Get the user's creds
// Is user a page editor?
if (IsPageEditor(UserCreds))
{
// put icon buttons for editing
}
else
{
// don't put icon button there
}
First of course is, getting the user credentials. I should add that this will all be on a private company intranet, and every user will be signed into the network.
I do not need nor want Windows Authentication determining whether the user can get to the page, only to discobver the user's logon creds.
Why not? Windows Authentication is the obvious, secure way to discover the Windows identity of the connected user.
Any other mechanism is insecure, i.e. a user who is not authorized to edit could spoof an authorized user's identity. Using Windows Authentication doesn't preclude you from allowing any user to access the application.
My understanding of setting Windows.Authentication ON is that it will challenge the user to give user name and password before allowing to view the page
No, this isn't correct. If the server is in the same domain as the client, and the server is configured to allow all domain users to connect, there doesn't need to be a prompt to the end user.
Our trouble ticket system "knows" who we are when we access the page -- it must be getting this information from Active Directory, from the current logged in user.
Probably it is using Windows authentication. Try examining the HTTP flow between the browser and your trouble ticket system with a tool such as Fiddler: you'll probably see an authentication challenge/response.
To get the current logged in user you need to call WindowsIdentity.GetCurrent();
From there you can do a lot of things depending on your requirement, get users groups, get OU information etc. For a full AD wrapper I have a full article here
http://macaalay.com/2010/06/28/active-directory-c/
I am trying to use active directory to tell if a user is logged in currently. Is this possible with active directory?
I can check what role the user has User.IsInRole(#"domain.com\TeamLead")
But I'm not seeing anything to see if they are currently logged in or not.
By strictly using Active Directory, you will not be able to get this information. Active Directory doesn't store this type of information. You can turn on Login Auditing through GPO and query individuals computers, but that could be messy.
An outside solution could be psloggedon:
http://technet.microsoft.com/en-us/sysinternals/bb897545.aspx
Though that is hardly ideal.
AFAIK there is no out of the box datastore that keeps track of which users are currently logged into a domain.
Another alternative could be to craft a logon/logoff script that writes to a particular file/database and you could monitor that file to see who is logged in.
I'm trying to use Windows Identity Foundation for authorization in my WPF client/server (WCF) application that may or may not be run in the same trust environment as the active directory that provides authentication. For example, authentication may be provided by the active directory, but the application may run in the cloud and the user's profile roles/permissions for the application will be provided by the application database.
I feel I'm missing a fundamental piece of the WIF process in my head in order to fully understand what I'm supposed to do:
User logs into the Windows domain using an Active Directory Username/Password
The user opens my application.
I reference the WindowsIdentity of the logged in user and can now look at their login token and all their configured roles/claims - but just like they can log into the domain, they could log into their own machine and would still have a WindowsIdentity token.
I can tie the user's Windows Identity to their user profile in my database and grant them access to the specific functionality in my application that their profile allows them to.
The piece I am missing is that I have this WindowsIdentity instance from WindowsIdentity.GetCurrent()... how do I verify what generated this? i.e. Is it a local machine user or an active directory user and if it's an active directory user, how do I know that it's my bona fide active directory server?
For instance - a couple of scenarios:
Scenario 1
The user names their local computer with the same name as my active directory domain
The user creates a local user on that computer with the same username as a user they know exists on my active directory that has full administrative access to my application.
They log into my application and for all intensive purposes they appear to have the same username as if the administrative user had logged onto my active directory.
In this scenario, the user has a local user account and not an active directory account and it has a spoofed identity created to purposefully circumnavigate application security.
I assume that there's some way to determine that this is a Windows Local User account and not an Active Directory user? I could make a call to my active directory for the user account with the username found in the WindowsIdentity and compare the SIDs to determine that this is in fact a spoofed user account and the user should be denied access.
Is this the correct way to do this? Is there some way I can tell from the WindowsIdentity that it was issued by my active directory and that this identity hasn't been tampered with?
Scenario 2
The user creates a spoofed Active Directory server with the same name as my active directory and creates an account mimicking the same process as the local user described in scenario 1.
Now I have an active directory user with the same domain name and username the same solution I suggested for scenario 1 would solve the issue for this scenario as well, but it would again be nice to determine that this token wasn't created by my active directory just by examining the token.
Can someone clear up what I'm missing - or am I missing anything at all? Should I just be making a call to Active Directory to authenticate that the WindowsIdentity provided is allowed access to my application?
Simple answer:
Your active directory is identified by more than just the name. When your computer joins the domain it exchanges a set of credentials. Spoofing an active directory or any other computer is much harder than merely creating a computer with the same name.
Windows takes care of all the behind the scenes authentication between machines. Bugs and vulnerabilities aside you can be pretty sure that when you call WindowsIdentity.GetCurrent() there is an unbroken chain of thrust backed by different credentials to authenticate the user.
More complete answer:
There are two types of windows authentication:
The first type is among peers in a network (i.e. outside of a domain). In this case when a user in computer A is connecting to computer B it's actually using a local user of B. If the user in B happens to have the same name and password as the user in A then the authentication happens without user intervention. If not a login screen appears and the user needs to provide credentials for some user in B. In any case the user is actually loging in to computer B, and B doesn't need to trust or know about the local use in computer A.
The second type is in a domain. I believe you can only add users from a domain if the computer itself is in part of the domain or in a domain with a trust relationship with it. In any case when the computer B will have a different set of credentials which allows it to authenticate the domain controller(s). Now when the user from computer A wants to login computer B asks the domain controller (which it knows and trusts) to authenticate the user. Once it gets the OK from the domain controller the user is accepted.
Windows supports various protocols for authentication some newer and more robust than others. The network administrator configures which protocols are accepted. Most (all?) protocols do not involve sending the actual password over the network (look at digest authentication for an example of such a protocol or read about the old NTLM protocols)
I have two executables. My first is running under administrative privileges. I want to start another process with current logged in user. I don't know password of the current logged in user. How do I do that?
You can do this by impersonating the logged on user. Here is a link which specifies 3 ways of doing this (not much of a detail though) Run an application under current logon user's privileges
First you need to know who is logged in and in this user has an active desktop, then, get process handle started by this user and grab credentials from this process. You can then sart process with those credentials
If I have a basic web form for our company's intranet and all users are logged in to the domain via AD authentication, can I extract a visitors user name in c#?
Use the User property on the current Page, like so,
var username = this.User.Identity.Name
If you are using Windows Authentication, and don't allow anonymous access, then HttpContext.Current.User.Identity.Name will have the name of the currently logged on user in the format domain\username.
If you want more info from AD (e.g. a display name), then you need to use the classes in the System.DirectoryServices namespace. You may need to provide credentials to access AD if your site is running under a restricted account such as the Network Service account.