Building a Security System With Active Directory and Coldfusion
We have 2 secure admin systems and an active directory that we currently store user-data in (and is the one that is maintained). What we would like to do is to consolidate all this user information to the active directory due to the sheer overhead of maintaining three user tables.
So I have typed out a login script and thought i would share..
Our issue is that our admin system still relies on the information in these tables in the two separate systems so this is what we would like to happen
<try>
//if form submited call this function checkuserexists(username, password)
//function <cfldap action="query"
server="ourdomain.net"
name="quser"
start="DC=ourdomain,DC=net"
filter="(&(objectclass=user)(mail=#form.arguments#@ourdomain.net))"
username="ourdomain\#arguments.username#"
password="#arguments.password#"
attributes = "give me all of them">
checkdb(quser)
if checkdb returns no user
//new user add them adduser(quser)
load session struct from db
success!
<cfcatch type="any">
bad login
</cfcatch>
</try>
//if form submited call this function checkuserexists(username, password)
//function <cfldap action="query"
server="ourdomain.net"
name="quser"
start="DC=ourdomain,DC=net"
filter="(&(objectclass=user)(mail=#form.arguments#@ourdomain.net))"
username="ourdomain\#arguments.username#"
password="#arguments.password#"
attributes = "give me all of them">
checkdb(quser)
if checkdb returns no user
//new user add them adduser(quser)
load session struct from db
success!
<cfcatch type="any">
bad login
</cfcatch>
</try>
Sorry for the mish-mash of pseudo and cf code but I guess the thought i am trying to get out is I wonder if there is a better way than try/catch. I have tried but it just gives me a big fat "inappropriate authentication".
Reference
Are your users all logged into the domain? Are they primarly using IE? If you turn off anonymous browsing in IIS and the users are using IE, then the CGI.AUTH_USER is passed to coldfusion with the user's login identiy.
Mind you, this only works in closed enviroments, but it is rock-solid if all the requirements are met.
Option 1: Use try/catch just as you are. Then pass in the user's username/password just as you are doing. If it fails, then there was a bad username or password. The try/catch code should then send the user back to the login form. This is my preferred choice.
Option 2: Use two LDAP queries. The first query connects to the AD using a known domain account and password for the credentials. The filter then determines if the user's accounts exists in the AD. If the account does exist, then a second LDAP query is performed using the user's username/password. This keeps the LDAP queries from failing when there is an unknown, or incorrect, username/password. However, since CFLDAP relies on an external system, you should still use try/catch in case the domain controller is unavailable.
So, my final word is to make it easy on yourself and just stick with try/catch.
There is already a user created in your AD for the purpose of searching the ldap tree - I'll IM it to you later today.
The Default AD setup only allows authenticated users to search (they don't need to be Domain Admins).
Once the user is logged in you can query any parts of the tree they have access to.
Cheers,
Mark
When i get this project up i will blog my final code as well as a flow diagam explaining it.
<cfldap action="QUERY"
name="GetUserInfo"
attributes="cn,sn"
start="cn=users,dc=xxx,dc=org"
server="server"
username="username@xxx.org"
password="password"
scope="base">
In your code, "base" refers to the object "cn=users,dc=xxx,dc=org" which is a container.
The query is returning the cn and sn for that particular container.
Here's an advance warning. You can use a wildcard "*" in your attributes attribute, but it won't return the correct results in all cases. Just as with a SQL database query, it's better to always specify the exact attributes that are required.
Other than returning values you may not use, any multi-value attributes will not return all values. An example would be the "memberOf" attribute.
Without testing, i believe the main problem is the lack of a filter, + as mike stated you want to change your scope too.
Put filter="(objectclass=user)" which should work to get all users(presuming they are all below your start container).
you might want to also filter on an email not being null to filter out any dummy service user accounts you may have, which off the top of my head would be something like:
filter="(&(objectclass=user)(!(mail=\00)))" but you'll probably have to check that...
I would use "objectCategory=person". User types also include computer accounts, for some reason. Person types only include what should be user-type accounts.
You can also specify an email by using the wild card.
So, the filter, I suggest, is:
FILTER="*(&(objectCategory=Person)(mail=*))"