Gitlab Authentication returns invalid username or password (LDAP pane missing) - active-directory

I have users in active directory LDAP (each have a username and email set).
I configured LDAP authentication in gitlab.rb and ran "gitlab-ctl reconfigure".
I user Gitlab Community Edition.
The following command returns the users so configuration seems ok "sudo gitlab-rake gitlab:ldap:check".
Returns :
LDAP: ... Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
DN: cn=Mike Gordon,cn=users,dc=ad,dc=mydomain,dc=com sAMAccountName: mike.gordon
... here other users
I'm trying to login with LDAP username mike.gordon and corresponding password on "Sign in" gitlab pane but i get "invalid username or password".
Some screenshots show that there is an LDAP pane but it's not displayed even with :
gitlab_rails['prevent_ldap_sign_in'] = false
this is my configuration :
main: # 'main' is the GitLab 'provider ID' of this LDAP server
label: 'LDAP'
host: 'myAdUrl'
port: 3268
uid: 'sAMAccountName'
bind_dn: 'CN=serveur-ovh,CN=Users,dc=ad,dc=mydomain,dc=com'
password: 'adpassword'
encryption: 'plain' # "start_tls" or "simple_tls" or "plain"
active_directory: true
allow_username_or_email_login: false
base: 'dc=ad,dc=mydomain,dc=com'
user_filter: ''
#lowercase_usernames: false
#block_auto_created_users: false
#verify_certificates: true
#smartcard_auth: false
### EE only
Thank you very much in advance for you help.

Comparing your configuration to mine, I have a user_filter value
###! **remember to close this block with 'EOS' below**
gitlab_rails['ldap_servers'] = YAML.load <<-'EOS'
main: # 'main' is the GitLab 'provider ID' of this LDAP server
label: 'LDAP'
host: 'ADHostname.example.com'
port: 636
uid: 'sAMAccountName'
method: 'ssl' # "tls" or "ssl" or "plain"
bind_dn: 'cn=UserID,ou=SystemAccounts,dc=example,dc=com'
password: 'AccountPasswordGoesHere'
active_directory: true
allow_username_or_email_login: false
block_auto_created_users: false
base: 'ou=ResourceUsers,dc=example,dc=com'
user_filter: '(&(sAMAccountName=*))' # Can add attribute value to restrict authorized users to GitLab access, we leave open to all valid user accounts in the OU. Should be able to authorize based on group membership using linked attribute value like (&(memberOf=cn=group,ou=groupOU,dc=example,dc=com))
attributes:
username: ['uid', 'userid', 'sAMAccountName']
email: ['mail', 'email', 'userPrincipalName']
name: 'cn'
first_name: 'givenName'
last_name: 'sn'
EOS

Related

Get email from LDAP using Ansible

I have a list of first and last name and I need to check them against my LDAP and get the emails.
I have been working with the ldap_entry and ldap_attr, but those modules don't provide information.
This will ensure that the user exist and it will try to create it, but it doesn't provide information:
- name: Make sure we have an user
ldap_entry:
dn: CN=xxx,CN=Users,DC=example,DC=com
objectClass: person
server_uri: ldap://ldap.test.com
bind_dn: CN=admin,OU=Functional Accounts,DC=example,DC=com
bind_pw: xxxxxxxxx
Is there any way to get the email from a user using ansible?
Thanks
Its not an answer, but a workaround.
I end up installing ldapsearch and I use the command option on ansible.
- name: Test ldap
command: ldapsearch -x -h ldap.test.com -D "admin" -w "xxxxxxx" -b "CN=Users,DC=example,DC=com" "cn={{item}}" -s sub "(cn=*)" mail
register: ldap_output
with_items: "{{owner_list}}"
You should be able to retrieve that information using the community.general.ldap_search Ansible module using the attrs parameter. You might need to change the name of the attribute from mail to match your LDAP server's email attribute name.
- name: Retrieve a user's mail attribute.
community.general.ldap_search:
dn: CN=xxx,CN=Users,DC=example,DC=com
attrs:
- mail
server_uri: ldap://ldap.test.com
bind_dn: CN=admin,OU=Functional Accounts,DC=example,DC=com
bind_pw: xxxxxxxxx
register: ldap_search_result
- name: Print a user's mail attribute.
ansible.builtin.debug:
msg: |
DN: {{ ldap_search_result.results[0].dn }}
mail: {{ ldap_search_result.results[0].mail }}
The community.general.ldap_search module requires the python_ldap package to be installed which in turn requires some LDAP related packaged.

Allowing "regular" users access to Sonata Admin CRUD actions

hope someone can steer me in the right direction!
I'm setting up a SonataAdmin based system for a project I'm working on that utilizes the SonataUserBundle.
I have a model setup extending AbstractMain for CRUD actions which is accessible using the navigation menu. From here, as a super admin, I can list, create, edit and delete items. Perfect!
My aim is to use the same SonataAdmin portal for 'subscribed' users, but with limited access. They should only be able to list items. However, I'm at something of a loss when it comes to just how to configure the symfony / sonata / fosuser security & firewall rules going on under the hood to make this happen.
My app/config/security.yml is as such.
security:
role_hierarchy:
ROLE_ADMIN: [ROLE_USER, ROLE_SONATA_ADMIN]
ROLE_SUPER_ADMIN: [ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH]
SONATA:
# - ROLE_SONATA_PAGE_ADMIN_PAGE_EDIT # if you are using acl then this line must be commented
encoders:
FOS\UserBundle\Model\UserInterface: sha512
acl:
provider: mongodb_acl_provider
# https://symfony.com/doc/current/security.html#b-configuring-how-users-are-loaded
providers:
fos_userbundle:
id: fos_user.user_provider.username
hwi:
id: sonata_oauth2_login.user.provider
firewalls:
# disables authentication for assets and the profiler, adapt it according to your needs
dev:
pattern: ^/(_(profiler|wdt)|css|images|js)/
security: false
admin:
# #pattern: /admin(.*) #REMOVE THIS LINE IF YOU ARE USING SONATA ADMIN
context: user
form_login:
provider: fos_userbundle
login_path: /portal/login
use_forward: false
check_path: /portal/login_check
failure_path: null
always_use_default_target_path: false
default_target_path: /portal/dashboard
logout:
path: /portal/logout
target: /portal/login
anonymous: true
oauth:
resource_owners:
google: "/login/check-google"
facebook: "/login/check-facebook"
login_path: /portal/login # For Sonata Admin
use_forward: false
default_target_path: /portal/dashboard # For Sonata Admin
failure_path: /portal/login # For Sonata Admin
oauth_user_provider:
service: sonata_oauth2_login.user.provider
access_control:
# Admin login page needs to be accessed without credential
- { path: ^/portal/login$, role: IS_AUTHENTICATED_ANONYMOUSLY }
- { path: ^/portal/logout$, role: IS_AUTHENTICATED_ANONYMOUSLY }
- { path: ^/portal/login_check$, role: IS_AUTHENTICATED_ANONYMOUSLY }
- { path: ^/portal/resetting, role: IS_AUTHENTICATED_ANONYMOUSLY }
# Secured part of the site
# This config requires being logged for the whole site and having the admin role for the admin part.
# Change these rules to adapt them to your needs
- { path: ^/portal/, role: [ROLE_ADMIN, ROLE_SONATA_ADMIN, ROLE_SONATA_USER] }
- { path: ^/.*, role: IS_AUTHENTICATED_ANONYMOUSLY }
services:
mongodb_acl_provider:
parent: doctrine_mongodb.odm.security.acl.provider
This is my sonata_admin config under config.yml:
sonata_admin:
title: BLAHBLAH
options:
title_mode: single_text
templates:
list: AppBundle:CRUD:list.html.twig
base_list_field: AppBundle:CRUD:base_list_field.html.twig
layout: AppBundle::standard_layout.html.twig
security:
handler: sonata.admin.security.handler.acl
# handler: sonata.admin.security.handler.role
role_admin: ROLE_ADMIN
role_super_admin: ROLE_SUPER_ADMIN
# acl security information
information:
GUEST: [VIEW, LIST]
STAFF: [EDIT, LIST, CREATE]
EDITOR: [OPERATOR, EXPORT]
ADMIN: [MASTER]
# permissions not related to an object instance and also to be available when objects do not exist
# the DELETE admin permission means the user is allowed to batch delete objects
admin_permissions: [CREATE, LIST, DELETE, UNDELETE, EXPORT, OPERATOR, MASTER]
# permission related to the objects
object_permissions: [VIEW, EDIT, DELETE, UNDELETE, OPERATOR, MASTER, OWNER]
Now, with this configuration, I can (as a superadmin) edit a user and grant the individual user through the ACL settings access to edit their own profile, as seen here:
ACL Settings for user
Nothing exists in the user settings for roles...
Roles for user
I've done what I can to follow along with the SonataUserBundle instructions for setting up security, but I'm falling short in understanding somewhere along the way.
In short, all users will be utilizing the same admin portal. Admins can create new users, products, etc. "Regular" users can edit their own profile and 'view' products from the admin class extended from AbstractAdmin by clicking the link in the menu on the left.
I feel like I'm wandering around Symfony security blindfolded right now with fosuserbundle & sonatauserbundle added to the mix. :(
This is my first post, so please forgive me if I'm missing anything important to include. I'll do my best to fill in any details and I appreciate your time observing my plight!

Symfony FOS user bundle - Switch User failed: "Username "*" does not exist."

It really is what the headline states - I can't figure out why user switching isn't working.
In my security.yml I have:
firewalls:
# disables authentication for assets and the profiler, adapt it according to your needs
dev:
pattern: ^/(_(profiler|wdt)|css|images|js)/
security: false
main:
pattern: ^/
form_login:
provider: fos_userbundle # using FOSUserBundle for user authentication
check_path: fos_user_security_check
login_path: fos_user_security_login
csrf_token_generator: security.csrf.token_manager # CSRF token - can be changed?
default_target_path: default_logged_in_target # default route to go to after login
# default_target_path: fos_user_profile_show
always_use_default_target_path: true # ignore the requested url and allways go to default route after login
logout:
path: fos_user_security_logout
target: default_loged_out_target
logout: true
anonymous: true
switch_user: true
Calling the URL
[ProjectPath]/account?_switch_user=testuser
results in the error
Switch User failed: "Username "testuser" does not exist."
"testuser" however is a perfectly valid user and I can log in normaly with that user when logging in the standard way.
The user I am logged in with when calling the URL with "_switch_user" does have the role "ROLE_ALLOWED_TO_SWITCH" - however this doesn't seem to be the problem.
I am stuck here.
Any hints are highly appreciated.
EDIT:
The stacktrace shows that in "SwitchUserListener.php" the call to
$this->tokenStorage->setToken($this->attemptSwitchUser($request));
fails and is catched resulting in the given error.
I could get it to work adding the fos_userbundle user provider to security.yml like this:
firewalls:
..
main:
...
switch_user:
provider: fos_userbundle
Ok, I made a stupid mistake, but perhaps someone else did as well. I use email for authenticating, but used the username for switching the user. Make sure you use the same property. So in my case I needed to use the email:
?_switch_user=example#email.com

RabbitMQ logins via LDAP failing

We are currently running RabbitMQ 3.5.6, and though it is able to successfully bind to the LDAP server, logins to the management UI via LDAP credentials are failing. I've been unable to track down the cause of this.
Our end goal is to have users be able to log into the RabbitMQ management UI with their LDAP credentials, and have RabbitMQ assign them permissions based on the groups that they are a member of in LDAP.
Upon login, both with a local account that I created for testing purposes and with my LDAP credentials I am presented with an internal server error:
Got response code 500 with body {"error":"Internal Server Error","reason":"{error,\n {try_clause,\n [{\"CN=rabbit,OU=System,OU=People,DC=domain,DC=tld\",\n \"LDAP_PASSWORD\"}]},\n [{rabbit_auth_backend_ldap,with_ldap,3,\n [{file,\"rabbitmq-auth-backend-ldap/src/rabbit_auth_backend_ldap.erl\"},\n {line,271}]},\n {rabbit_auth_backend_ldap,user_login_authentication,2,\n [{file,\"rabbitmq-auth-backend-ldap/src/rabbit_auth_backend_ldap.erl\"},\n {line,59}]},\n {rabbit_access_control,try_authenticate,3,\n [{file,\"src/rabbit_access_control.erl\"},{line,91}]},\n {rabbit_access_control,'-check_user_login/2-fun-0-',4,\n [{file,\"src/rabbit_access_control.erl\"},{line,77}]},\n {lists,foldl,3,[{file,\"lists.erl\"},{line,1262}]},\n {rabbit_mgmt_util,is_authorized,6,\n [{file,\"rabbitmq-management/src/rabbit_mgmt_util.erl\"},{line,121}]},\n {webmachine_resource,resource_call,3,\n [{file,\n \"webmachine-wrapper/webmachine-git/src/webmachine_resource.erl\"},\n {line,186}]},\n {webmachine_resource,do,3,\n [{file,\n \"webmachine-wrapper/webmachine-git/src/webmachine_resource.erl\"},\n {line,142}]}]}\n"}
The rabbitmq.config that I am currently using is below, followed by the log entries generated by RabbitMQ.
%% -*- mode: erlang -*-
[
{rabbit,
[{tcp_listeners, []},
{ssl_listeners, [{"10.7.232.1", 5672}]},
{log_levels, [{connection, info}, {channel, info}]},
{reverse_dns_lookups, true},
{ssl_options, [{certfile, "/usr/local/etc/rabbitmq/rmqs01.cer"},
{keyfile, "/usr/local/etc/rabbitmq/rmqs01.key"}]},
{auth_backends, [rabbit_auth_backend_ldap, rabbit_auth_backend_internal]},
{auth_mechanisms, ['PLAIN']}
]},
{rabbitmq_auth_backend_ldap,
[{servers, ["dc01.domain.tld", "dc02.domain.tld", "dc03.domain.tld"]},
%%{user_dn_pattern, "cn=${username},ou=People,dc=domain,dc=tld"},
{user_dn_pattern, []},
{use_starttls, true},
%% necessary for our ldap setup
{dn_lookup_attribute, "sAMAccountName"},
{dn_lookup_base, "OU=People,DC=domain,DC=tld"},
{dn_lookup_bind, [{"CN=rabbit,OU=System,OU=People,DC=domain,DC=tld", "rmqpassword"}]},
{port, 389},
{timeout, 30000},
{other_bind, [{"CN=rabbit,OU=System,OU=People,DC=domain,DC=tld", "rmqpassword"}]},
{log, network},
%% ACL testing
{resource_access_query,
{for, [{resource, exchange,
{for, [{permission, configure,
{ in_group, "OU=Systems,OU=People,DC=domain,DC=tld" } },
{permission, write, {constant, true}},
{permission, read, {constant, true}}
]}},
{resource, queue, {constant, true}} ]}}
]},
{rabbitmq_management,
%%{http_log_dir, "/var/log/rabbitmq/access.log"},
[{listener,
[{port, 15672},
{ip, "10.7.232.1"},
{ssl, true},
{ssl_opts,
[{certfile, "/usr/local/etc/rabbitmq/rmqs01.cer"},
{keyfile, "/usr/local/etc/rabbitmq/rmqs01.key"}
]}
]}
]}
].
=INFO REPORT==== 10-May-2016::10:17:47 ===
LDAP CHECK: login for username
=INFO REPORT==== 10-May-2016::10:17:47 ===
LDAP connecting to servers: ["dc01.domain.tld",
"dc02.domain.tld",
"dc03.domain.tld"]
=ERROR REPORT==== 10-May-2016::10:17:47 ===
webmachine error: path="/api/whoami"
{error,
{try_clause,
[{"CN=rabbit,OU=System,OU=People,DC=domain,DC=tld",
"rmqpassword"}]},
[{rabbit_auth_backend_ldap,with_ldap,3,
[{file,"rabbitmq-auth-backend-ldap/src/rabbit_auth_backend_ldap.erl"},
{line,271}]},
{rabbit_auth_backend_ldap,user_login_authentication,2,
[{file,"rabbitmq-auth-backend-ldap/src/rabbit_auth_backend_ldap.erl"},
{line,59}]},
{rabbit_access_control,try_authenticate,3,
[{file,"src/rabbit_access_control.erl"},{line,91}]},
{rabbit_access_control,'-check_user_login/2-fun-0-',4,
[{file,"src/rabbit_access_control.erl"},{line,77}]},
{lists,foldl,3,[{file,"lists.erl"},{line,1262}]},
{rabbit_mgmt_util,is_authorized,6,
[{file,"rabbitmq-management/src/rabbit_mgmt_util.erl"},{line,121}]},
{webmachine_resource,resource_call,3,
[{file,
"webmachine-wrapper/webmachine-git/src/webmachine_resource.erl"},
{line,186}]},
{webmachine_resource,do,3,
[{file,
"webmachine-wrapper/webmachine-git/src/webmachine_resource.erl"},
{line,142}]}]}

Gitlab Active Directory issues - gitlab-7.7.1_omnibus

I am having issues with Active Directory authentication via LDAP on Gitlab omnibus. I have tested the credentials and bind dn using ldapsearch and received a response with no issues, but for some reason I am not seeing any attempts at connecting when I login as an AD user on the gitlab frontend. I receive the error "Could not authorize you from Ldapmain because "Invalid credentials"." no matter if I'm using valid credentials or not.
I also receive the following from sudo gitlab-rake gitlab:check:
** Invoke gitlab:ldap:check (first_time)
** Invoke environment
** Execute gitlab:ldap:check
Checking LDAP ...
LDAP users with access to your GitLab server (only showing the first 100 results)
Server: ldapmain
Checking LDAP ... Finished
Please let me know if my explanation is not clear, or if you think that additional information would be helpful. I tried searching around and am not finding my exact issue.
My configuration is as follows:
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-EOS # remember to close this block with 'EOS' below
main: # 'main' is the GitLab 'provider ID' of this LDAP server
## label
#
# A human-friendly name for your LDAP server. It is OK to change the label later,
# for instance if you find out it is too large to fit on the web page.
#
# Example: 'Paris' or 'Acme, Ltd.'
label: 'LDAP'
host: 'myadserver.my.domain.net'
port: 389
uid: 'sAMAccountName'
method: 'plain' # "tls" or "ssl" or "plain"
bind_dn: 'CN=Gitlab,OU=Service Accounts,OU=Washington\, D.C.,OU=United States,OU=NA,DC=my,DC=domain,DC=net'
password: 'mypasswrd'
# This setting specifies if LDAP server is Active Directory LDAP server.
# For non AD servers it skips the AD specific queries.
# If your LDAP server is not AD, set this to false.
active_directory: true
# If allow_username_or_email_login is enabled, GitLab will ignore everything
# after the first '#' in the LDAP username submitted by the user on login.
#
# Example:
# - the user enters 'jane.doe#example.com' and 'p#ssw0rd' as LDAP credentials;
# - GitLab queries the LDAP server with 'jane.doe' and 'p#ssw0rd'.
#
# If you are using "uid: 'userPrincipalName'" on ActiveDirectory you need to
# disable this setting, because the userPrincipalName contains an '#'.
allow_username_or_email_login: true
# Base where we can search for users
#
# Ex. ou=People,dc=gitlab,dc=example
#
base: 'OU=Washington\, D.C.,OU=United States,OU=NA,DC=my,DC=domain,DC=net'
# Filter LDAP users
#
# Format: RFC 4515 http://tools.ietf.org/search/rfc4515
# Ex. (employeeType=developer)
#
# Note: GitLab does not support omniauth-ldap's custom filter syntax.
#
#user_filter: ''
EOS
This was, of course, a whitespace issue. See lines below:
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-EOS # remember to close this block with 'EOS' below
main: # 'main' is the GitLab 'provider ID' of this LDAP server
## label
#
# A human-friendly name for your LDAP server. It is OK to change the label later,
# for instance if you find out it is too large to fit on the web page.
#
# Example: 'Paris' or 'Acme, Ltd.'
label: 'LDAP'

Resources