Hi Bobbie,
You may be able to get more information out of the production.log
file. Here's some things to check:
On Mon, Mar 11, 2013 at 2:37 PM, Bobby <bo...@guardedhorizons.com> wrote:
> When trying to authenticate through the web interface, I have tried the
> following options below and keep getting the error message "Email and/or
> password did not match, please try again:
>
> 1) DOMAIN\username
> 2) username by iteself
> 3) username@domain.local
You'll only want to use #2, "username by itself". I'm pretty sure you
can't authenticate to LDAP with the older-style "DOMAIN\username", and
for #3, I'm not sure Gitorious supports "@" signs in usernames. During
an LDAP login, the username will be substituted for the "{}" bit of
the distinguished_name_template setting, and that should include the
"@" sign for you.
> Can someone please tell me what I might be doing wrong here? My
> authentication.yml file is below:
[snip]
> # IP/hostname to LDAP server
> host: dc.domain.local
Hopefully this is the fully-qualified name of your domain controller?
> # Override the default port (389)
> #port: 1999
>
> # The base DN to search
> base_dn: DC=domain,DC=local
Hopefully this is correct base DN for your LDAP setup?
> # The base DN when searching for groups (for authorization)
> # If unspecified, base_dn is used
> # group_search_dn: OU=groups,dc=gitorious,dc=org
>
> # What LDAP attribute to use for user authentication. Default is CN
> #login_attribute: uid
Do your users have "uid" attributes on their accounts? You probably
want to use "samaccountname" instead for Active Directory.
> # How to build a user's DN. Default: $LOGIN_ATTRIBUTE={},$BASE_DN,
> # e.g. CN=chris,DC=gitorious,DC=org
> distinguished_name_template: "{}@domain.local"
This needs to match the "userPrincipalName" attribute on any AD
account. So you should check in ADUC or ASDI Edit or whatever that
this domain matches the userPrincipalName attribute on your account.
> # Map LDAP fields to database fields.
> # Default: displayname => fullname, mail => email
> # attribute_mapping:
> # givenName: fullname
> # publicEmail: email
This probably needs to be adjusted, because "givenName" and
"publicEmail" attributes probably don't exist in your AD schema.
Here's what I use with my AD setup:
attribute_mapping:
cn: fullname
mail: email
> # See Net-LDAP for other options, or use "none" for no encryption.
> # Defaults to "simple_tls" if not set.
> encryption: none
Please note this is not secure, and once you get the other pieces
working, you should change it as soon as possible :)
> # A class/object that will be called after successful authentication
> # through LDAP. Will be "constantized", post_authenticate will be
> called
> # with an options hash. See LdapAuthenticationTest.
> #callback_class: SampleCallback
>
> # Specify a username/password to use for authenticated bind
> # NOTE: This is required when using LDAP for authorization
> bind_user:
> username: ldap_svc@domain.local
> password: ldap_svc_password
If you're at a dead end, you may want to comment out the bind_user
section while you're troubleshooting. It shouldn't affect simple
password authentication for users, and you can add it back in when
you've got the password auth working.
If you still have problems, I recommend doing a test with "ldapsearch
-x -W ..." just to confirm that you can properly authenticate to AD
from your system.
- Ken
--
--
To post to this group, send email to gitorious@googlegroups.com
To unsubscribe from this group, send email to
gitorious+unsubscr...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups
"Gitorious" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to gitorious+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
