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 <[email protected]> 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) [email protected] 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: [email protected] > 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 [email protected] To unsubscribe from this group, send email to [email protected] --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
