Permission problem with cfldap and active directory?

[silverspecv]

I'm trying to use cfldap to read from Active Directory on a windows 2000 server. To preface, the domain name is "specsol" and the DC's name is "main". These are on the LAN together behind the firewall, so there is no internet traffic involved. I have been using only the wins-style names, since they're on the LAN together. I'm using CFMX and <cfldap> to implement my shennanigans.

I can use the following statement to autenticate a user with the AD:

<cfldap action="QUERY"
name="auth"
server="main"
attributes="cn"
start="cn=users,dc=main"
username="specsol\jmtest"
password="jmtest">

I made a fake user named jmtest, password jmtest. It returns an empty query, but if I change the password and run it again, it says "inappropriate authentication" so I know the empty query is actually successful, it just doesn't return anything.

Despite my best trial-and-error efforts, I can't get it to read anything at all under any circumstances. I can either get an empty query, or one of a handful of various error messages. Can anyone give me the right command to actually get some data out of this thing, such as a list of users or login names or anything?

Oh yeah, regarding the subject of this post, is it possible that I have active directory set up with some funky permissions that won't allow reading of data? What should I check on the DC?

 

[silverspecv]

How horribly typical of me. I futz and fiddle for mutliple hours. Then I post a help request out of frustration. No more than two minutes later, I solve my own problem. I switched the start= attribute to start="dc=specsol, dc=com" and now it pulls data.

If anyone could point me to some documentation specificly regarding the START attribute, I'd really appreciate it. I'm getting back all kinds of crazy records with data I don't understand. All I want is a list of users.

 

[ecobb]

By default Active Directory allows all users to query it, so you should be OK (unless you've already made some changes in AD).

I just spent the last week trying to do this exact same thing, and I finally got it working a couple of days ago. Here's my cfldap tag that I use for logging in:

<cfldap action="QUERY"
			        name="auth"
			        attributes="userPrincipalName,cn,dn,displayName,ou,sAMAccountName"
			        start="DC=OurDomainName, DC=com"
			        scope="SUBTREE"
			        filter="sAMAccountName=#Form.Username#"
			        sort="userPrincipalName"
			        server="dc1.OurDomainName.com"
			        username="domain\#Form.Username#"
			        password="#Form.Password#">

If you notice, I've had to bounce back and forth between "OurDomainName.com" and just our local "Domain". I'm not exactly sure why this is, it may just be the way our Active Directory is set up, but for whatever reason the above cfldap tag works...and it's the ONLY thing I've been able to get to work.

Our Domain Controller is called DC1, so I had to put the full domain name in (dc1.OurDomainName.com), even though we're on the LAN as you said. I also used the root directory of our AD as my "start" point, and I had to split the domain name up. Instead of saying "DC=OurDomainName.com", I had to use "DC=OurDomainName DC=com".

If you haven't already found them, here are a couple of posts I made while trying to figure all of this out. Hopefully this will be able to help you out.

thread232-874798

thread232-853355



Hope This Helps!

Ecobb

&quot;My work is a game, a very serious game.&quot; - M.C. Escher

 

[ecobb]

Oops, posted at the same time, congrats on getting it fixed!

In order to narrow down what's returned from the "Start" attribute, you'll need to know how things are set up in your Active Directory. For instance, if all of your users are in an Orgizational Unit (OU) called "users" under your root directory, then you could use start="OU=Users, DC=OurDomainName, DC=com".

Like I said, it's going to depend on how AD is structured, though...



Hope This Helps!

Ecobb

&quot;My work is a game, a very serious game.&quot; - M.C. Escher

 

[silverspecv]

Ecobb, thanks much. You sure are.. hmm.. prolific on here.

The start attribute is really killing me, though. I tried your example of OU=Users, but I get an error:

An error has occured while trying to execute query :[LDAP: error code 32 - 0000208D: NameErr: DSID-031001B8, problem 2001 (NO_OBJECT), data 0, best match of: &apos;DC=specsol,DC=com&apos; ].

I do have to thank you for providing two keywords that I'm now including in my attributes parameter, "sAMAccountName" and "userPrincipalName". This is the current incarnation that I'm tweaking:

<cfldap action="QUERY"
name="auth"
server="main"
attributes="objectClass,cn,dn,sn,sAMAccountName,userPrincipalName"
start="dc=specsol, dc=com"
username="specsol\administrator"
filter="(SN=*)"
password="ssnet02">

If you note the filter statement, this does limit the query results to users, which is helpful. I can't seem to put anything else in the start= without getting the above error. In my searching, I have seen questions asking about potential compatibility issues from upgrading to CFMX. Do you know if there is any concrete information on that?

 

[ecobb]

Hey, what can I say...I get around! (-:

I'm not sure about the upgrading problem, as I've only tried this with MX. But, like you, I've seen several posts floating around on the web talking about it. It wouldn't surprise me, there have been several things about CF that don't like upgrading to MX.

As far as the start attribute goes, it's going to be hit/miss trial/error until you find the "config" that your active directory likes. One thing that helped me was outputting everything listed in the "dn" (I see that you're pulling that in your Attributes, too). When I displayed it, I got results like "CN=Ecobb, OU=Users, OU=IT, DC=OurDomainName, DC=com". This actually tells you the structure that AD has this user listed in:

OurDomainName.com
    |
    |__IT
        |
        |__Users
              |_Ecobb

So, basically by using Start="OU=Users, OU=IT, DC=OurDomainName, DC=com" I would be saying search in the "users" OU, which is in the "IT" OU, which is in the "OurDomainName" DC...etc...

I hope I'm making sense...anyway, if you have access to your Domain Controller you can log on and look at "Active Directory Users and Computers" under "Administrative Tools". This will show you the structure of your OU's in the Active Directory and that will tell you what to put in the "Start" attribute.



Hope This Helps!

Ecobb

&quot;My work is a game, a very serious game.&quot; - M.C. Escher

 

[TruthInSatire]

while we're on the subject i've got a sinking feeling we're going to be headed to using an ldap server soon.

anyone recomend some good reads?

Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.
-Douglas Adams (1952-2001)

 

[ecobb]

Hey Bombboy, here's a few that I was able to find. Articles on this seem to be pretty scarce...

Creating a login:

http://livedocs.macromedia.com/coldfusion/6.1/htmldocs/appsec30.htm

http://www.macromedia.com/devnet/mx/coldfusion/articles/ntdomain.html

Integrating ColdFusion with Active Directory

http://www.macromedia.com/devnet/se...ntegrating_cf_apps_w_ms_active_directory.html

Advanced CFLDAP topics

http://livedocs.macromedia.com/cold...oldFusion_MX_Applications_with_CFML/LDAP7.htm

Hope This Helps!

Ecobb

&quot;My work is a game, a very serious game.&quot; - M.C. Escher

 

[silverspecv]

Ecobb, that tree structure example did it. It looks like going by the DN and working backward allows me to filter using the start attribute. The only problem with that is that it won't return OU's that are siblings, so I am sticking with the filter attribute, which returns every human user in the system even in different OU's. But I now have the technique down for processing specific OU's. I think I'm done here. Now to go batch process the whole tree and send nasty email to everyone who's password is still "password"

Yes, all this for that. What a way to spend the day.

 

[silverspecv]

Ok, sorry, one more question. Any idea what attribute will return the checkboxes for "user must change password at next logon" and "password never expires" and "user cannot change password"?

 

[ecobb]

I was able to find these:

accountExpires

pwdLastSet

whenChanged

But it looks like the info is encrypted, so there's probably not going to be a way to modify it, although I would be very interested in knowing if you could or not.



Hope This Helps!

Ecobb

&quot;My work is a game, a very serious game.&quot; - M.C. Escher

 

[silverspecv]

I think there are some bitmapped fields in there. IE, an integer like 512 which turns into binary 100000000 and then each digit represents a checkbox checked or unchecked. I have been testing the field useraccountcontrol but then I go in and check the boxes by hand and then check the number via ldap again, but it doesn't change.. so I don't know if I have the wrong field or if there is some delay (don't think so) or what.. arg! Where is there a good and proper list of the fields and their meaning?

 

[silverspecv]

Oh, a word of warning.. learn from my mistake. I pulled a list of all login names and then ran an authentication on them to test if their password was password. Well I had to run the thing several times of course to get the kinks out, and when it was done, everbody whose password was not password had their account locked out

 

[ecobb]

and when it was done, everbody whose password was not password had their account locked out

Doh! Don't feel bad, I did the same thing...although it was just my account. Everything was working when I went to lunch one day, but when I came back nothing would work! I took me a while to figure out what was going on...





Hope This Helps!

Ecobb

&quot;My work is a game, a very serious game.&quot; - M.C. Escher