I have created an ASP.NET website that has to access Active Directory on another server and change users passwords. The problem is that I need to authenticate with existing AD account and I cannot send AD user's password in plaintext when communicating with the Active Directory server. How do I communicate with AD server from ASP.NET website, so that connection is secure? My AD server supports LDAP protocol, but I do not know how to enforce communication with LDAP via a secure channel.
ASP.NET Website --------------LDAP/another protocol (secure)------------> AD Server
Fairly simple, you need to do two things :
Configure your Active Directory instance to accept connections over LDAPS, or port 636. You'll need a certificate (it can be self-signed) to set that up.
Update your LDAP authorization code to use this the new connection. This shouldn't be anything more than changing the server to "ldaps://{{IP OR DNS}}", and ensuring you're setting SessionOptions.SecureSocketLayer = true;
If you want to verify that it's working properly, Wireshark the traffic leaving your ASP.Net site that's going over port 636, and you should notice it's now heavily encrypted, and impossible to discern anything meaningful from.
I've done a ton of this stuff over the years, so I've had a few other questions surrounding this that should also help you out :
Set callback for System.DirectoryServices.DirectoryEntry to handle self-signed SSL certificate?
(This contains a full implementation of LDAPS)
Custom Multi-factor Active Directory Authentication
(This is a much more simple example, but would work perfectly fine for your purposes)
Related
Well i am implementing a Account Login system in my application in which i want to make sure that all the connections are secure so the user can't simply redirect the client connection to a mimicked server and gain access to the app without my permission. So here is the procedure i am imagining.
1- The HttpClient Connects to my SSL page.
2- Makes sure that the connection is secure (maybe by checking the certificate or something).
3- If the connection is secure it sends out the login credentials.
4- It receives the answer and if the account is valid it goes on, if not it terminated the connection.
So as you see my plane is very simple and i think it will be good to prevent some abusers or hacker from gaining access to my app without my permission and it relays on the powerful SSL certificate system; However, i don't know how could i implement this in real code so i really need your help illustrating how could i make sure that the HttpClient has connected to my real server using SSL and not anyone's fake server.
Here is all you need - SSL certificate validity/match to domain name is checked by default.
var c = new System.Net.Http.HttpClient();
Console.Write(c.GetStringAsync("https://www.facebook.com/").Result);
I have a user account on a clients Salesforce. These credentials are used on our Web service to connect and upload data to that clients Salesforce account.
However I have found that only my PC will allow the logging in to the API, this is not ideal as I need to have multiple users logged in using the same account and on different PC's in our organisation.
How can I fix this issue?
a review of their policy suggests that what you want to do is prohibited, however it seems that it should be possible. There is a way to lock the account to the ip that created and perhaps that is being used as a default. please have a look here and see if it applies to your situation. https://help.salesforce.com/apex/htviewhelpdoc?id=admin_sessions.htm&language=en_US
As you have found, you need to append the Security Token to the password to allow API logins from IP addresses that aren't trusted. This is a fairly standard way of calling the API. Note that changing the password will also change the Security Token.
The alternative to using the security token is to add the IP addresses of the Server making the API calls to the Trusted IP ranges.
Setup > Administration Setup > Security Controls > Network Access
The problem was with my URL endpoints, the web server we are using does various unexpected things that I was not aware of for security purposes.
I have since devised a workaround by dumping the data into a table and then using a console app to poll this table and transmit the data to salesforce.
I am developing a TcpClient/TcpListener based client-server application.
Now I have come to the point where I need to authenticate the user. I could use the PrincipalContext-Class on the server side and request username/password/domain from the client, but I don't want to send the credentials over the network. Additionally, I don't want to ask the user for their credentials again.
So, I know the Citrix Receiver which supports pass-through authentication. It uses the current logged on user and does not request any credentials and authenticates the user against the server. It just works.
How can I do this in my application? I thought about some kind of token which can be sent to the server, but I could not find any solution.
Wrap the NetworkStream in a NegotiateStream, and call the appropriate NegotiateAs... methods on both client and server.
The client can specify what impersonation level to allow, and the server can specify what level it requires (minimally Identification in order to determine client identity, but if you need to access local or network resources as the client, you could also specify Impersonation or, with the right network configuration, Delegation).
Once authenticated, the server can determine the client's identity and/or impersonate using the NegotiateStream's RemoteIdentity property.
As I mentioned in my comment, I don't know how Citrix affects this setup (never having used it), but if it's basically completely transparent to the application and everything uses standard Windows credentials, then this should work.
The .net Framework does have functions for Diffie-Hellman Key Exchange:
http://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch
http://www.codeproject.com/Articles/24632/Shared-Key-Generation-using-Diffie-Hellman
If you are writing both the client and the server parts of the application, then you can encrypt the user's credentials for passing across the network and decrypt at the other end.
Working on the assumption that on the client machine, a malicious user could extract the encryption key from your application (using strings or similar) then symmetric encryption is not suitable. Therefore asymmetric (public-private) encryption seems suitable. Generate a pair of keys and the server's key should remain private (and only on the server) and the clients' key can be included in the application on the client machines. Then it doesn't matter if the key is extracted from the app as credentials can only be decrypted with the secret and secure private key on the server. This class has done most of the ground work for you.
So I'm working on a mobile web app using jQuery Mobile, and I need to request some data from a remote server from the app. I get the data either from a C# SOAP web service, or from an IHttpHandler that returns JSON. I need to somehow authenticate with the web service/handler before any data is returned. I was hoping to use ActiveDirectory, and somehow pass a user name and a hashed password to the server via an AJAX request. The problem is, examples of authenticating in C# with ActiveDirectory involve passing a plain-text user name and password to PrincipalContext.ValidateCredentials. Is there any way to securely pass credentials to the C# service and have it authenticate with AD, without it knowing the plain-text password?
Edit: thought maybe I could hash the password client-side, pass it to the server, let the server get the AD password for the requested user and hash it the same way, then compare, but getting the AD password isn't possible.
Edit: Looking at aSSL.
If you are developing a mobile web with jquery ui, it wont live on the device, it will live on your web server (iis, if its a web application). Your application can authenticate using windows authenticatin against the service it needs to query, however it depends on the user used to run the application / impersonation being used on ur side.
The question is how your application and this service communicate between themsleves and the internet. If the service is not accessible to the internet, i dont know how much you should worry about the transport being secure.
You also can check out ad fs / ad fs 2 based security solutions and wcf integration options, such as explained here, for example.
These solutions implement the concept you are talking about, with the AD FS being the service that authenticates/ validates the credentials passed, and returns a token to the applicatin / service. Usuaully the communication with AD FS uses ssl to secure the transport layer, and the messages are signed, to make sure no one messes with them in the middle. You can, of course, implement such a mechanism by urself. You dont need to get the password from the active directory, you only need to see if the passed credentials (username / password) can be validated, by using the code sample provided here
I am writing a ClickOnce WPF app that will sometimes be used over VPN. The app uses resources available only to domain authenticated users. Some of the things include accessing SSRS Reports, accessing LDAP to lookup user information, hitting web services, etc.
When a user logs in from a machine that is not authenticated on the domain, I need to somehow get his credentials, authenticate him on the domain, and store his credentials.
What is the recommended approach for
authenticating domain users over
VPN?
How can I securely store the credentials?
I've found several articles but, not much posted recently and a lot of the solutions seem kinda hacky, or aren't very secure (ie - storing strings clear text in memory).
It would be cool if I could use the ActiveDicrtoryMembershipProvider, but that seems to be geared for use in web apps.
EDIT:
The above is kind of a workaround. The user must enter their domain credentials to authenticate on the VPN. It would be ideal to access the credentials the user has already entered to login to the VPN instead of the WindowsIdentity.GetCurrent() (which returns the user logged into the computer). Any ideas on how that could work? We use Juniper Networks to connect to the VPN.
Answer
I ended up doing basically what was suggested in the link below. When the app starts, I'll detect whether the user is on the domain. If so, I'll use those credentials when calling services. If the user is on the VPN (but not on a domain authenticated machine), I prompt for the user's credentials and authenticate via System.DirectoryServices. If the user gives valid credentials I'll store the domain, user and password in a SecureString. The app then uses that information to create credentials to pass to various services.
Thanks!
This answer to the question might help.
--EDIT--
If the client is logging under their AD credentials then WindowsIdentity.GetCurrent() would return a valid WindowsIdentity.
If client is not logged onto the domain then you can provide a pop up that would ask for AD credentials.
Well, just thinking...