Thanks, Michael.
I don't think the syntax is the problem because it works when I replace
#FORM.UserLogin# with the admin account username and #FORM.UserPassword# with
the admin password. I assume it's an AD because the password name is
unicodePwd - their admin isn't sure (believe it or not). I gather client IS
departments aren't always fully cooperative with vendors.
You're right - I don't need to know the user's password, I just need to
authenticate with it. But even the simple CFLDAP query that retrieves the cn
won't execute if I use the user's credentials - it only works if I use the
administrative name and pw.
I tried a single query as you suggest, and it throws an error every time,
citing the line with password="#FORM.UserPassword#" as the error source in the
CFLDAP query.
This works:
<cfldap action="QUERY"
name="find_user"
start="DC=XXX,DC=XXXX,DC=XXX"
attributes="cn,givenName,sn,department"
scope="subtree"
filter="cn=#FORM.UserLogin#"
server="[server IP address]"
username="[admin account name]"
password="[admin password]">
This doesn't:
<cfldap action="QUERY"
name="authenticate"
start="DC=XXX,DC=XXXX,DC=XXX"
attributes="cn,givenName,sn,department"
scope="subtree"
filter="cn=#FORM.UserLogin#"
server="[server IP address]"
username="#FORM.UserLogin#"
password="#FORM.UserPassword#">
Any help would be greatly appreciated, as I'm stumped -
David
> What directory server are you using? Active Directory, Novell, etc?
>
> Why do you need the user's password? If you need the password,
> caputure it when the user logs in. Once they have successfully
> logged-in, then you will know that the password is correct. Knowing
> any incorrect passwords is useless.
>
> If you are using AD, don't use two CFLDAP queries. Just use one and
> pass the user's credentials such as:
>
> <cfldap username="[EMAIL PROTECTED]" password="#form.
> password#"...>
>
> Wrap that in CFTRY/CFCATCH and Bob's your uncle.
>
> However, with your current system, when the second query hangs, have
> the admins check the server logs for any possible cause. Make sure
> you are using the correct username syntax: "domain\user" or
> "[EMAIL PROTECTED]".
>
> If your server is AD, the attribute is unicodePwd, however, it's a
> write-only attribute. There should never be a reason to be able to
> retrieve any password, let alone an entire directory's listing of
> passwords.
>
> FInally, don't use a wildcard for attributes for the same reasons you
> should not with a SELECT statement on a database. You will retreive
> more attributes than you will probably need; multi-value attributes
> will not return all values; some attributes are binary and can be huge.
> For example, we have Cisco voicemail integrated with AD, It adds
> scores of attributes that you will probably never need to retrieve.
>
> We need to know your directory server and post some of your code here.
>
>
> m!ke
>
> _____
>
> From: david reiter [mailto:[EMAIL PROTECTED]
> Sent: Sun 3/9/2008 6:25 AM
> To: CF-Talk
> Subject: CFLDAP finds cn but can't find password or certain
> attributes
>
>
>
> I'm using a standard CFLDAP query pair for auth just as Adobe
> describes (http://kb.adobe.com/selfservice/viewContent.
> do?externalId=tn_18169), and it works great for all but the latest of
> my application users. The first query (confirming the user in the
> name server with admin credentials) works fine, but the second (using
> the user's cedentials) will not execute - it hangs on the line
> containing the user's password in the second query. If I change the
> user's credentials in the second query to the admin creds, it will
> execute (but, of course, it's only authenticating the username and not
> the password). This server also does not execute the CFLDAP queries
> when I use an asterisk instead of naming the attributes I want
> returned.
>
> I queried their name server with Softerra's LDAP browser, and I can't
> find the password attribute using the name for it given to me by my
> client's system administrator. I also can't find any other atribute
> that looks like it could be the password. So I have no idea where to
> go with this. The client is running CF8 and the above applies using
> default port 389. When I try to use port 636 and SSL_basic security,
> the application will not connect to the LDAP server at all. They
> don't seem to know what CA authority they use and they won't let me
> into the cacert folder to find out what's in there - but it doesn't
> matter until I can get this to work even via 389. It's a large
> medical center, so I suspect they're using a standard CA authority and
> certification should be in the default CF cacert file.
>
> I have to make it work (this is my first comercial application) and it
> works great for my 4 other users. Any help would be greatly
> appreciated. Thanks for your time -
>
> David
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to
date
Get the Free Trial
http://ad.doubleclick.net/clk;160198600;22374440;w
Archive:
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:300826
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
