Installed OpenLDAP by helm
helm install openldap stable/openldap
Check data in the initialized server
kubectl port-forward $OPENLDAP_POD_NAME 3890:389
ldapsearch -x -H ldap://localhost:3890 -b dc=example,dc=org -D "cn=admin,dc=example,dc=org" -w $LDAP_ADMIN_PASSWORD
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=org> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# example.org
dn: dc=example,dc=org
objectClass: top
objectClass: dcObject
objectClass: organization
o: Example Inc.
dc: example
# admin, example.org
dn: cn=admin,dc=example,dc=org
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: [HIDDEN]
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2
Install keycloak
helm install keycloak codecentric/keycloak
kubectl port-forward $KEYCLOAK_POD_NAME 8080
Bind it to Keycloak in the User Federation -> Add user storage provider -> ldap as below.
Why can't connect to ldap server? I login to the ldap pod to see the log but didn't find where is it.
The "Connection URL" should most probably be ldap://openldap.default:389 (and if openldap was deployed in a different namespace, replace default with that).
Related
I am using Dex as our Identity provider and connecting it to LDAP. Below is my ldap config in Dex:
connectors:
- type: ldap
id: ldap
name: LDAP
config:
host: myhost.staging.com:636
insecureNoSSL: false
insecureSkipVerify: false
bindDN: cn=prometheus-proxy,ou=serviceaccounts,dc=staging,dc=comp,dc=com
bindPW: 'prometheus'
rootCA: /etc/dex/ldap/ca-bundle.pem
userSearch:
baseDN: ou=people,dc=staging,dc=comp,dc=com
filter: "(objectClass=person)"
username: uid
idAttr: uid
emailAttr: mail
nameAttr: uid
groupSearch:
baseDN: ou=appgroups,dc=staging,dc=comp,dc=com
filter: "(objectClass=groupOfMembers)"
userAttr: DN
groupAttr: member
nameAttr: cn
And below is a sample userSearch & groupSearch Result:
dn: uid=swedas01,ou=people,dc=staging,dc=comp,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
cn: Sweta Das
gecos: Sweta Das
gidNumber: 50000
givenName: Sweta
mail: Sweta.Das#comp.com
sn: Das
uid: swedas01
memberOf: cn=jenkins,ou=appgroups,dc=staging,dc=comp,dc=com
homeDirectory: /home/swedas01
dn: cn=prometheus,ou=appgroups,dc=staging,dc=comp,dc=com
objectClass: top
objectClass: groupOfMembers
cn: prometheus
member: uid=testl01,ou=people,dc=staging,dc=comp,dc=com
When I login to my Prometheus instance which uses the above config, even though my userID is not part of the Group that is being used ie Prometheus, I am still able to login.
Dex logs shows there is no groups associated with my id.
time="2019-10-07T19:05:48Z" level=info msg="performing ldap search ou=people,dc=staging,dc=comp,dc=com sub (&(objectClass=person)(uid=swedas01))"
time="2019-10-07T19:05:48Z" level=info msg="username \"swedas01\" mapped to entry uid=swedas01,ou=people,dc=staging,dc=comp,dc=com"
time="2019-10-07T19:05:48Z" level=info msg="performing ldap search cn=prometheus,ou=appgroups,dc=staging,dc=comp,dc=com sub (&(objectClass=groupOfMembers)(member=uid=swedas01,ou=people,dc=staging,dc=comp,dc=com))"
time="2019-10-07T19:05:48Z" level=error msg="ldap: groups search with filter \"(&(objectClass=groupOfMembers)(member=uid=swedas01,ou=people,dc=staging,dc=comp,dc=com))\" returned no groups"
time="2019-10-07T19:05:48Z" level=info msg="login successful: connector \"ldap\", username=\"swedas01\", email=\"Sweta.Das#comp.com\", groups=[]"
But why is it still allowing me to login? Is there any way I can mandate this setting if group serach returns empty, login should fail?
Since your directory supports memberOf attribute, you can try adding a membership condition in the userSearch filter.
Now look :
username: uid
filter: "(objectClass=person)"
yields the following ldap filter :
"(&(objectClass=person)(uid=<uid>))"
So it might be possible to add the membership condition without operator in the filter setting, as dex is actually adding the operator itself (tested and confirmed by #MohammadYusefpur).
Like :
filter: "(objectClass=person)(memberOf=cn=prometheus,ou=appgroups,dc=staging,dc=comp,dc=com)"
so that the actual ldap filter results in
(&(objectClass=person)(memberOf=cn=prometheus,ou=appgroups,dc=staging,dc=comp,dc=com)(uid=<uid>))
I am still not sure if this is the right answer. But as far as I could understood, Dex's group search is just for ldap search. It returns the groups a user is memberof. Once you get the groups back, you can put RBAC policies on those group to control what kind of access you want to give to the user.
However, for tools which do not have any auth methods of its ownn(eg Prometheus), I am still not sure how to implement ldap group auth!
I put an acl policy in /etc/rundeck for my group.
rd-acl test -c application -g "Cloud Team" -a create -G project
Using configured Rundeck etc dir: /etc/rundeck
The decision was: allowed
The test passed
Then I log into Rundeck via the website and I see this:
You have no authorized access to projects.
Contact your administrator. (User roles: ..., Cloud Team, ...)
For good measure, I temporarily made another acl policy for my user.
I pass the test with my user name.
rd-acl test -c application -u myuser -a create -G project
I also tried a group that does not have a space in the name and got the same results.
If it makes a difference, I am logging in using my AD credentials and the groups are being pulled in from AD.
This is in Rundeck 3.0.20-20190408
My acl policy
description: Admin, all access.
context:
project: '.*' # all projects
for:
resource:
- allow: '*' # allow read/create all kinds
adhoc:
- allow: '*' # allow read/running/killing adhoc jobs
job:
- allow: '*' # allow read/write/delete/run/kill of all jobs
node:
- allow: '*' # allow read/run for all nodes
by:
group: Cloud Team
---
description: Admin, all access.
context:
application: 'rundeck'
for:
resource:
- allow: '*' # allow create of projects
project:
- allow: '*' # allow view/admin of all projects
project_acl:
- allow: '*' # allow admin of all project-level ACL policies
storage:
- allow: '*' # allow read/create/update/delete for all /keys/* storage content
by:
group: Cloud Team
I see errors like this in rundeck.access.log
Evaluating Decision for: res<type:resource, kind:project> subject<Username:MyNameHere Group:OneOfMyGroups Group:AnotherGroup Group:Cloud Team> action<create> env<rundeck:auth:env:application:run
deck>: authorized: false: No context matches subject or environment => REJECTED_NO_SUBJECT_OR_ENV_FOUND (0ms)
I have been trying to authenticate OIDC using DEX for LDAP. I have succeeded in authenticating but the problem is, LDAP search is not returning the groups. Following are my DEX configs and LDAP Data. Please help me out
Screenshot: Login successful, groups are empty
My Dex Config
# User search maps a username and password entered by a user to a LDAP entry.
userSearch:
# BaseDN to start the search from. It will translate to the query
# "(&(objectClass=person)(uid=<username>))".
baseDN: ou=People,dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
# Optional filter to apply when searching the directory.
#filter: "(objectClass=posixAccount)"
# username attribute used for comparing user entries. This will be translated
# and combine with the other filter as "(<attr>=<username>)".
username: mail
# The following three fields are direct mappings of attributes on the user entry.
# String representation of the user.
idAttr: uid
# Required. Attribute to map to Email.
emailAttr: mail
# Maps to display name of users. No default value.
nameAttr: uid
# Group search queries for groups given a user entry.
groupSearch:
# BaseDN to start the search from. It will translate to the query
# "(&(objectClass=group)(member=<user uid>))".
baseDN: dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
# Optional filter to apply when searching the directory.
#filter: "(objectClass=posixGroup)"
# Following two fields are used to match a user to a group. It adds an additional
# requirement to the filter that an attribute in the group must match the user's
# attribute value.
userAttr: uid
groupAttr: memberUid
# Represents group name.
nameAttr: cn
My LDAP Data
dn:
ou=People,dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
ou: People objectClass: organizationalUnit
dn:
uid=johndoe,ou=People,dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
gecos: John Doe uid: johndoe loginShell: / bin / bash mail:
john.doe#example.org homeDirectory: / home / jdoe cn: John Doe sn: Doe
uidNumber: 10002 objectClass: posixAccount objectClass: inetOrgPerson
objectClass: top userPassword: bar gidNumber: 10002
dn:
uid=janedoe,ou=People,dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
gecos: Jane Doe uid: janedoe loginShell: / bin / bash mail:
jane.doe#example.org homeDirectory: / home / jdoe cn: Jane Doe sn: Doe
uidNumber: 10001 objectClass: posixAccount objectClass: inetOrgPerson
objectClass: top userPassword: foo gidNumber: 10001
dn:
ou=Groups,dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
ou: Groups objectClass: organizationalUnit
dn:
cn=admins,ou=Groups,dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
cn: admins objectClass: posixGroup objectClass: top gidNumber: 20001
memberUid: janedoe memberUid: johndoe
dn:
cn=developers,ou=Groups,dc=ec2-54-185-211-121,dc=us-west-2,dc=compute,dc=amazonaws,dc=com
cn: developers objectClass: posixGroup objectClass: top gidNumber:
20002 memberUid: janedoe
Sorry for a late replay but I didnt know the answer until now :)
I had the same problem, in my setup I used dex (quay.io/dexidp/dex:v2.16.0) to use MS AD. I used kubernetes 1.13 in my tests.
To generate kubeconfig i used heptiolabs/gangway (gcr.io/heptio-images/gangway:v3.0.0) and for handle dashboard login i used pusher/oauth2_proxy (quay.io/pusher/oauth2_proxy).
I spent a lot of time trying different ldap setups in dex but didnt get the AD groups to show up in dex log or get them to work in kubernetes, and every example I read was using only users.
The problem and solution for me was not in the dex config, dex will request groups from ldap if you tell dex to do so.
Its all in the clients. OIDC have a "concept" of scopes and I guess that most (all?) oidc clients implement it, at least both gangway and oauth2-proxy does.
So the solution for me was to configure the client (gangway and oauth2-proxy in my case) so that they also ask dex for groups.
In gangway I used the following config (including the comments)
# Used to specify the scope of the requested Oauth authorization.
# scopes: ["openid", "profile", "email", "offline_access"]
scopes: ["openid", "profile", "email", "offline_access", "groups"]
For oauth2-proxy I added this to the args deployment
- args:
- --scope=openid profile email groups
And then I could use groups instead of users in my rolebindings, dont forget to also configure the api-server to use dex for its oidc.
Hope that helps
-Robert
I want to set up OpenLDAP in a Kubernetes cluster running on AWS.
I’ve applied YAML files “https://github.com/osixia/docker-openldap/tree/stable/example/kubernetes/simple” except for service type I choose load balancer.
I’ve added below two ldif files:
base.ldif
dn: ou=People,dc=example,dc=com
objectClass: organizationalUnit
ou: People
dn: ou=Group,dc=example,dc=com
objectClass: organizationalUnit
ou: Group
test.ldif
dn: uid=test,ou=People,dc=example,dc=com
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
cn: test
uid: test
uidNumber: 9999
gidNumber: 100
homeDirectory: /home/test
loginShell: /bin/bash
gecos: test admin user
userPassword: password
shadowLastChange: 17058
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
I’ve setup LDAP client on centos 7 system but no result is showing if I execute “getent passwd test”
Please help me with this?
I use the following configuration to access internet from local 127.0.0.1:2000 proxy to the internet.:
global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
#log loghost local0 info
maxconn 4096
#chroot /usr/share/haproxy
user haproxy
group haproxy
daemon
#debug
#quiet
defaults
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
maxconn 2000
contimeout 5000
clitimeout 50000
srvtimeout 50000
listen appname 0.0.0.0:2000
mode http
stats enable
acl white_list src 127.0.0.1
tcp-request content accept if white_list
tcp-request content reject
stats uri /haproxy?stats
stats realm Strictly\ Private
stats auth special_admin:special_username
balance roundrobin
option httpclose
option forwardfor
server lamp1 23.123.1.110:3128 check
Unfortunately I need to authenticate to my external proxy 23.123.1.110 via http basic authentication "special_admin:special_username".
My question is, is there any way to use basic authentication like :
server lamp1 http://special_admin:special_username#23.123.1.110:3128 check
Thanks
In your example you only need to add the necessary Authorization header with the authorization method and the username:password encoded as base64 like this:
reqadd Authorization:\ Basic\ c3BlY2lhbF9hZG1pbjpzcGVjaWFsX3VzZXJuYW1l
I created the base64 encoded string like this:
echo -n "special_admin:special_username" | base64
For more details about HTTP Basic authorization see https://en.wikipedia.org/wiki/Basic_access_authentication#Client_side
Below listed steps have worked for me.
# haproxy conf
global
log 127.0.0.1 local1
maxconn 4096
defaults
mode http
maxconn 2048
userlist AuthUsers
user admin password $6$SydPP/et7BGN$C5VIhcn6OxuIaLPhCDCmzJyqDYQF8skik3J6sApkXPa6YPSVGutcgQPpdX/VEycGNi3sw7NxLSflEb53gzJtA1
frontend nginx-frontend
bind *:5000
mode http
timeout connect 5s
timeout client 5s
timeout server 5s
default_backend nginx-backend
# For Path based basic authentication use this commented example
#acl PATH_cart path_beg -i /testing
#acl authusers_acl http_auth(AuthUsers)
#http-request auth realm nginx-backend if PATH_cart !authusers_acl
acl authusers_acl http_auth(AuthUsers)
http-request auth realm nginx-backend if !authusers_acl
backend nginx-backend
server nginx nginx:80 check inter 5s rise 2 fall 3
Install below package to generate hash password
sudo apt-get install whois
mkpasswd -m sha-512 'your_password'
mkpasswd -m sha-512 admin#456
expected output
$6$gnGNapo/XeXYg39A$T/7TDfMrZXUDPbv5UPYemrdxdh5xEwqBrzSbpJYs9rfxLbQtgQzxyzkSGWIVOEGze8KrsA0urh3/dG.1xOx3M0
Copy the generated password and paste in haproxy.cfg file
#Deploy the containers to test configuration
sudo docker run -d --name nginx nginx
sudo docker run -d -p 5000:5000 --name haproxy --link nginx:nginx -v /home/users/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg haproxy
Check in the browser, username and password will be prompted.