I need to implement application that supports LDAP authentication.
I want to know in detail how such network works. Can you recomend some reading about it, a book perhaps with broader explanation of LDAP authenticated networking or at least some online tutorials. I would like to see step by step guide of creating such network and if possible, cross platform theory with samples in Win and *nx systems.
Thanks.
LDAP System Administration is the book I read when I first started with LDAP.
That and the OpenLDAP Administrators Guide.
In addition to gacrux, I'd suggest looking at
Lightweight Directory Access Protocol (Wikipedia) for an introdcution
LDAP Linux HOWTO by Luiz Ernesto Pinheiro Malère
Understanding LDAP (part 1) and Understanding LDAP (part 2) on devshed.com
LDAP and OpenLDAP (on the Linux Platform) slides
Are you looking to build new LDAP server infrastructure, or are you looking to use an existing service?
If you're building infrastructure, then Understanding and Deploying Directory Services has long been the book to get. It clearly explains what LDAP is, how to design your schema and directory information tree layout, and how to choose an appropriate directory topology.
If you're trying to authenticate users against an existing LDAP service, you would be best served by reading the library docs for your language. The typical process for authenticating users goes like this:
Take the user's user id and search against LDAP for that user to obtain the disinguished name (or DN, a unique name for each entry in the LDAP tree).
Use the retrieved DN and the password the user provided to "bind", or authenticate against the LDAP server as that user.
Check the return code from the server to determine whether the bind was successful.
Based on the results of the previous step, allow or disallow the user.
Related
I need a little guidance on how to implement signing of documents in a web based document distribution system we are developing.
At its simplest, user A will be logging into the website and create a Data Package. Word/Pdfs can be added to the package. User A will sign this document(s) using a digital certificate. User A might assign this to other users for reviewing the documents. They may sign the documents as well.
Now I know how to digitally sign data with C#. What I don't know is how to generate a certificate when each user logs into the website. The site is secured with DigiCert certificate.
What approach should I take to generate a digital certificate for each user? Once I have a .pfx file I believe I can store it in the database and use that.. Any guidance on this matter will be greatly appreciated!
thanks
I take to generate a digital certificate for each user? Once I have a .pfx file I believe I can store it in the database and use that..
This is what I call "naive approach" (read simplistic). You consider to store (maybe even generate) keypairs for the users in a web application. The biggest isssue with this approach is that someone with low-level access to the system (admins) or if database is leakt could gain access to the user's private key. To have a secure solution (considering signing), the private key may not leave its user
Doing everything in a web environment, you may consider using SubtleCrypto or other client site libraries, however at this point of time I see no reasonable way to manage the keys for pure web apps. Maybe you can store the user's keys and certificate in a localStorage, but it leaves some space for mallignant scripts to leak the keys.
Many real life secure solutions are working with secure modules (e. g. crypo cards), unfortunatelly the web libraries have no access to the modules (usually exposed as pkcs11 interface). As a solution usually the signing piece runs as custom code on user's computer. Before it was ActiveX, Applet,.. now it is often a "driver" exposed as a web server bound to "localhost" so the signig service can be used as web api from web applications.
I have authenticated using Siteminder & I have obtained accessToken.
Now there is another application that comes under the scope of same application.
I want to use Alfresco there without any need of further sign-up. Basically I want to implement single sign on.
I don't know Siteminder, but sso is possible in alfresco.
You'll have to look at how the authentication subsystem work. You'll find the configuration under alfresco.war\WEB-INF\classes\alfresco\subsystems\Authentication\ you can redefine them under /shared/classes/alfresco/extension/subsystems/Authentication/
Things exist for:
alfrescoNtlm (alfresco's own mechanism)
kerberos
ldap
ldap-ad
passtrhu
external <- this on is a good candidate for you
With external you can tell aflresco to trust what comes from an url. You'll find information here http://docs.alfresco.com/5.0/concepts/auth-external-intro.html or there http://smasue.github.io/alfresco-external-sso
I hope this helps
We are running a Saas ASP.NET 3.5 Web application using Forms authentication on a IIS 7.5 public server with protected content for thousands of users. We also have some subapplications running ASP.NET MVC 2.
Usernames and passwords are stored in our database and every user has roles and groups attached, with privileges and access rights defined.
Now we have been asked to also facilitate for simple SSO login via Active Directory so that users do not have to enter username and passwords twice to login. These users will originate from different networks and domains.
No user "sync" should take place from our servers to LDAP serves. We are not sure that any communication with LDAP is needed since all users will be created in our system and maintained there. Forms authentication will be used for most of our users.
From here on we are unsure which is the best path to choose. For our scenario what would be the "best practice" way to proceed?
The simple answer is SAML. It is considered the "best practice" and many large SAAS providers support it.
SAML protocol defines the single sign on flow between multiple systems. It establishes trust between systems using certificates. Your application accepts an assertion containing attributes (user id, name, email address, etc.) from other systems. Your app will map the user into your user store.
In .NET world there are several options. You can find a library that implements SAML (ComponentSpace has one) and hook it into ASP.NET authentication. You can create your own using Windows Identify Framework (WIF). Here's the boatload of WIF videos http://www.cloudidentity.com/blog/2010/06/23/ALL-WILL-BE-REVEALED-7-HOURS-RECORDINGS-FROM-THE-WIF-WORKSHOPS/. You can try IdentityServer http://thinktecture.github.io/
Depending on how secure your app must be, you can opt for a simple option of passing user id from trusted networks using a simplified method. I've seen apps that allow user id to be sent via URL parameter or form field. Of course, this is horribly insecure, and you are taking on more risk, because the trust between two networks is not cryptographically enforced. You can mitigate it somewhat by checking referrer string or IP address (if you can isolate IP range of a corporate network for example). But you are still open to spoofing because any user can impersonate others by simply replacing user id within HTTP request.
It probably doesn't answer your question fully, but hopefully points you in the right direction.
I recommend looking into ADFS 2.0 it is very powerful in terms of claims mapping and works with AD: http://msdn.microsoft.com/en-us/magazine/ee335705.aspx
What you would make is a token consuming portion of your app that would receive and parse the final claims returned to your web server after the authentication loop.
I'm looking at starting a new web app which needs to be secure (if for no other reason than that we'll need PCI (Payment Card Industry) accreditation at some point).
From previous experience working with PCI (on a domain), the preferred method is to use integrated windows authentication which is then passed all the way through the app to the database using kerberos (so the NT user has permissions in the DB). This allows for better auditing as well as object-level permissions (ie an end user can't read the credit card table).
There are advantages in that even if someone compromises the webserver, they won't be able to glean any/much additional information from the database. Also, the webserver isn't storing any database credentials (beyond perhaps a simple anonymous user with very few permissions for simple website config)
So, now I'm looking at the new web app which will be on the public internet. One suggestion is to have a Active Directory server and create windows accounts on the AD for each user of the site. These users will then be placed into the appropriate NT groups to decide which DB permissions they should have (and which pages they can access).
ASP.Net already provides the AD membership provider and role provider so this should be fairly simple to implement.
There are a number of questions around this - Scalability, reliability, etc... and I was wondering if there is anyone out there with experience of this approach or, even better, some good reasons why to do it / not to do it.
Any input appreciated
Having used ADAM in a project, I found it to be bear. Documentation for developers can be sparse, it has quirks that differentiate it from full AD and, most importantly, I could not get a straight answer from MS as to whether it will be fully supported in the future. The impression I got was that ADAM was the bastard child and that the new Federated services (ADFS) was where they wanted people to go. Just moving the ADAM store from one member server to another was a pain. Now that said, my issues with ADAM had to do with development against and maintenance of the store, It definitely has the ability to scale and it was reliable. That said there are times when you need to delve into 80th level spells of LDAP/Directory magic to figure what it is or is not doing.
For a public facing site, AD/ADAM might be overkill IMO. You could use alternate MembershipProviders like the SqlMembership provider to get the good level of security with respect to credentials. If you wanted to go further, you could use database encryption (SQL Server at least has this ability built-in) to encrypt information that falls into the PII (Personally Identifiable Information) arena and of course encrypt the backups. The advantage that a database backed authentication store has is that you have all the tools that your database product provides to scale out, do backups, control access and so on.
EDIT: Let me add, that with .NET you can setup your site so that it runs under a Windows user and connects to the database using Windows Authentication (assuming the db supports it). Thus, no credentials need to be stored in a config file. However, if you had to store credentials for whatever reason, you can then use DPAPI to encrypt the credentials in the config file.
ADDITION In response the question about securing encryption keys you have a couple of choices. The first is to simply hash the credit card numbers. That greatly simplifies any problems with access to the data however, it means that the customer would have to re-enter their card number for each purchase. If you want to remember the customer's card number, then you move into a new realm of maintenance of the decryption keys. In this scenario, you absolutely should use Windows Authentication to the database and look into SQL Server 2008's Extensible Key Management feature which lets you hook-in a third-party key management program into SQL's encryption functionality. In this way, only the website user would have access to the keys used for decryption. There are other solutions to ensure that the website cannot be compromised. The greater worry is that someone gets a copy of the database undetected. Here's a link on using SQL Server to be PCI compliant:
Deploying SQL Server 2008 Based on Payment Card Industry Data Security Standards (PCI DSS) Version 1.2.
couple ideas
Run AD/AM - Active Directory Application Mode.
It scales well. It's the same core code as AD. Similar management capabilities. Solid reliability. Works with the ASPNET AD Membership Provider.
And it's included in Windows.
Also consider exploring a federated identity system, via ADFS 2.
unlike AD/AM, this approach is fairly leading-edge. The final version of the ADFS v2 server is not yet available from Microsoft, but it is at "release candidate" stage. If you have the stomach to be an early adopter, ADFS2 holds the possibility to employ a federated identity approach. That means you could accept identity tokens from a variety of existing sources: a google sign-in, a yahoo sign-in, any OpenId source, and use that as the identity on your site. Users would not have to "register" and authenticate to you. Instead, your site would honor the identity and authentication provided by some trusted third party, and perform authorization based on that identity.
This is not a direct answer but having a AD user account means you need a windows CAL for that user. Another way would be to issue client certificates to user and map client certs to AD users in IIS.
You might also consider AzMan with SQL store available from Windows 2008 onwards or the open source netsqlazman.
Is there any way to obtain (not change) the password of the ASPNET account on a Windows Server 2003 server? I need to snyc my workstation's ASPNET account password with the one on the server I am trying to connect to.
I am trying to trouble shoot the following issue with my ASP.NET application.
There is a simple way to obtain this password. This account is auto created so its not as simple as "Asking your network administrator".
First dump the password hashes from your domain controller, most anti virus will see PWDUMP has as a virus so be sure to disable AV before you run.
Second after you dump these passwords feed them into John the Ripper (note: John the ripper is not the best program to use to do this, but it does happen to be free)
Here is a (somewhat out of date) tutorial for breaking passwords with John
The only way to obtain an NT service account password is to ask someone who knows. If the person who ought to know doesn't then that same person ought to be able to reset it for you. In other words you should probably talk to your network administrator.
Essentially No there is no way to retrieve a windows account password. You can change them with various tools but retrieval is highly unlikely.
You can always create a proxy account on a domain controller and setup an app pool to run under a proxy account so permissions can span across workstations.