I need to create a web-api which should authenticate a user through active directory . The api should be available publicly and need to authenticate the users which is inside a intranet. But the user authentication should also be done from outside the particular intranet. What should i do to open service avail publically
It's not secure to Authenticate external users against your production Active Directory directly. But that doesn't mean you can't accomplish your task. You should start looking into Active Directory Lightweight Directory Services
AD LDS or formerly known as ADAM will allow you to authenticate external users against your Active Directory using Proxy Authentication.
What Is Proxy Authentication?
Proxy authentication allows a user to perform a simple bind to an AD LDS instance, while still maintaining an association to an Active Directory account. Two accounts are involved in the transaction. The first is a special object in AD LDS called a userProxy object. The second is the user's account in Active Directory.
The AD LDS userProxy object is a representation of the Active Directory account. The proxy object is tied to the Active Directory account through that account's security identifier (SID). There is no password stored on the actual proxy object itself.
When a user performs a simple bind to an LDS instance with a proxy object, the bind is redirected to Active Directory by passing the SID and password to a domain controller. The AD LDS server performs the authentication, and the entire process is invisible to the end user
You can not authenticate users with AD outside your intranet. They should use an VPN connection to gain access to your network before been authenticated.
Related
I am connecting to a service account using a service account credential.
I'm trying to scale this up to be used for multiple users within the same company. All users will have Google accounts managed by this company, and I will have a gsuite service account for the entire company. How can I upload a file to users personal Google Drive based on an email address using a gsuite service account?
You want to use ServiceAccountCredential, with a User property set to the appropriate user.
Assuming you're loading the credentials using GoogleCredential, this isn't too hard. For example:
GoogleCredential credential = Google.GetApplicationDefault()
.CreateScoped(...)
.CreateWithUser("foo#bar.com");
If you wanted to use the same original credentials for many different users, you could keep the result of CreateScoped(...) around, and just call CreateWithUser to create a new user-specific credential for each operation.
Using Oauth2 you are going to have to have each of the users authentication your application. This will give you access to their drive account directly. Now you say you have a master user. You could just request that these other users share a folder on their Google drive account with the master user then it will have access. Note you can't share the root directory.
You might want to consider using a service account instead of oauth2 this the users will then have to grant the service account access to their drive account.
Now if this is a gsuite users all of this can be automatically done useing domain wide delegation of the service account.
Here in my work we have the same scenario as you, and to be able to achive this type of integration we created a service account with wide domain delegation enabled for this account.
This way we can use the service account to access users data on their behalf.
But for that, when creating the service account credential, you must impersonate the service account credential passing the user email, this way you'll be able to access user data on their behalf using the service account.
Since you're using C#, I've created a small library that create service account credentials for any type of google api services and for both JSON or P12 credentials.
https://github.com/drodriguesaar/GoogleApiServiceFactory
So I'm developing a web application that allows users to view their SQL reporting services reports externally, and users log in with a custom username the user created themselves.
I would like to authenticate these usernames against their windows domain accounts, which a check against the active directory to see if the user is in a relevant group and that will determine the access rights to certain reports.
Now I can't use windows authentication as a login procedure to my web application but I do have a SQL table which stores their custom username (which they log in with) mapped against their windows domain account, and on login I store the domain name into the session (stores the windows account credentials as a string) as a property which is exposed by my base controller.
I've already gone off and tried this solution,
http://www.benramey.com/2014/10/20/active-directory-authentication-in-asp-net-mvc-5-with-forms-authentication-and-group-based-authorization/
but as you can see from my previous post (see here Trying to authenticate users against the AD - ASP.NET MVC) i'm not getting the desired result.
Just looking for some advice on how I can achieve authenticating against the AD with my scenario.
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)
We have the following setup for authenticating users. A wcf authentication service that is hosted as a windows service on a server machine. The client is a C# CAB based application that communicates with the authentication service and other services (auditing,..) as needed.
We want to give an option of using Active directory to logon to the application.
The steps that were proposed are as shown below.
Authentication service running on server
user opens application on client
machine and chooses login by AD.
application, uses the userName and
password to authenticate user
against AD.
application sends some token from
the authenticated user to the
authentication service, to get back
information about sql server and sql
db name.
authentication service uses token against Active Directory
and verifies that user is logged on
and authenticated and returns back the required sql information.
Are steps 4 & 5 possible without the client app needing to send the username and password to the server for authenticating against AD? I want to avoid as much as possible sending passwords on the network.
You can't do that with AD and a client only, you need to involve a service in the authentication mechanism. If I were you, I'd send the username and password to the authentication service, the client shouldn't talk to the AD directly at all. And if you need some SSO, you can create a token in the authentication service. AD doesn't issue tokens, only you can, or another, more sophisticated service, like ADFS.
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.