kosmos/chef
kosmos
/
chef
8
3
Fork 0
Code Issues 34 Pull Requests 2 Projects 1 Activity

LDAP users should only be able to change their own password #128

New Issue
Closed
opened 2020-02-04 15:33:55 +00:00 by greg · 10 comments
greg commented 2020-02-04 15:33:55 +00:00
Owner
Copy Link

I found out about this while researching groups and roles. Right now a user can search for users and get data including their email address. We do not want that

Example:

$ ldapsearch -x -D 'cn=greg,ou=kosmos.org,cn=users,dc=kosmos,dc=org' -b "ou=kosmos.org,cn=users,dc=kosmos,dc=org" "(&(objectclass=person))"

[snip]
# alfred, kosmos.org, users, kosmos.org
dn: cn=alfred,ou=kosmos.org,cn=users,dc=kosmos,dc=org
objectClass: top
objectClass: account
objectClass: person
objectClass: extensibleObject
cn: alfred
sn: alfred
uid: alfred
samaccountname: alfred
mail: alfred@example.com

Needs something similar to https://www.zytrax.com/books/ldap/ch5/step2.html#step2-access but for 389 Directory Server (the link is for OpenLDAP)

We want users to not be able to search, only change their own mail or password

I found out about this while researching groups and roles. Right now a user can search for users and get data including their email address. We do not want that Example: ``` $ ldapsearch -x -D 'cn=greg,ou=kosmos.org,cn=users,dc=kosmos,dc=org' -b "ou=kosmos.org,cn=users,dc=kosmos,dc=org" "(&(objectclass=person))" [snip] # alfred, kosmos.org, users, kosmos.org dn: cn=alfred,ou=kosmos.org,cn=users,dc=kosmos,dc=org objectClass: top objectClass: account objectClass: person objectClass: extensibleObject cn: alfred sn: alfred uid: alfred samaccountname: alfred mail: alfred@example.com ``` Needs something similar to https://www.zytrax.com/books/ldap/ch5/step2.html#step2-access but for 389 Directory Server (the link is for OpenLDAP) We want users to not be able to search, only change their own mail or password
raucao commented 2020-02-04 16:57:24 +00:00
Owner
Copy Link

They shouldn't see any data from other users really. Not just the email address.

They shouldn't see any data from other users really. Not just the email address.
greg changed title from LDAP users should not be able to list other users' email address to LDAP users should only be able to change their own password and email 2020-02-04 18:43:26 +00:00
greg commented 2020-02-05 13:31:11 +00:00
Author
Owner
Copy Link

Setting ACIs is what we need.

# kosmos.org
dn: dc=kosmos,dc=org
changetype: modify
replace: aci
aci: (target="ldap:///dc=kosmos,dc=org") (version 3.0; acl "user-deny-all"; deny (all) userdn="ldap:///dc=kosmos,dc=org";)
aci: (target="ldap:///dc=kosmos,dc=org")(targetattr="userPassword") (version 3.0; acl "user-write-own-password"; allow (write) userdn="ldap:///self";)

This example denies everything (reading, search, writing, etc) for all users (except for the admin account, since its dn is not under dc=kosmos,dc=org) but a user can change their password. We should also create read-only accounts that can perform the LDAP searches for the different services, probably using groups to set the ACIs

[Setting ACIs](https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/managing_access_control) is what we need. ```ldif # kosmos.org dn: dc=kosmos,dc=org changetype: modify replace: aci aci: (target="ldap:///dc=kosmos,dc=org") (version 3.0; acl "user-deny-all"; deny (all) userdn="ldap:///dc=kosmos,dc=org";) aci: (target="ldap:///dc=kosmos,dc=org")(targetattr="userPassword") (version 3.0; acl "user-write-own-password"; allow (write) userdn="ldap:///self";) ``` This example denies everything (reading, search, writing, etc) for all users (except for the admin account, since its dn is not under `dc=kosmos,dc=org`) but a user can change their password. We should also create read-only accounts that can perform the LDAP searches for the different services, probably using groups to set the ACIs
greg self-assigned this 2020-02-05 13:31:18 +00:00
raucao commented 2020-02-05 15:03:55 +00:00
Owner
Copy Link

I don't think akkounts-api should have credentials to a master admin account. But it does need to write to the directory.

If there are ACLs for reading, then there are probably also ACLs for writing, no?

I don't think `akkounts-api` should have credentials to a master admin account. But it does need to write to the directory. If there are ACLs for reading, then there are probably also ACLs for writing, no?
raucao commented 2020-02-05 15:05:31 +00:00
Owner
Copy Link

By the way, shouldn't we also restrict access to the entire LDAP server by IP address? Why does a user have to be able to connect to it directly?

By the way, shouldn't we also restrict access to the entire LDAP server by IP address? Why does a user have to be able to connect to it directly?
greg commented 2020-02-05 15:06:20 +00:00
Author
Owner
Copy Link

Yes, there are ACIs for everything. We can create an account for akkounts-api that can create users and nothing else

Yes, there are ACIs for everything. We can create an account for `akkounts-api` that can create users and nothing else
raucao commented 2020-02-05 15:19:47 +00:00
Owner
Copy Link

We can create an account for akkounts-api that can create users and nothing else

I think you mean create and query users.

> We can create an account for akkounts-api that can create users and nothing else I think you mean create *and query* users.
raucao commented 2020-02-06 21:42:12 +00:00
Owner
Copy Link

The title of this issue is still misleading. LDAP users shouldn't be able to directly change anything in the directory. They should always go through akkounts, and I think we should enforce 2FA there for everyone as well.

The title of this issue is still misleading. LDAP users shouldn't be able to directly change anything in the directory. They should always go through akkounts, and I think we should enforce 2FA there for everyone as well.
greg commented 2020-02-07 10:28:42 +00:00
Author
Owner
Copy Link

I agree that everything should be locked down (and the LDAP server should only be accessible by servers that need access) once we have added these features to akkounts. However I think the changes for akkounts should go in another issue. For now we need users to be able to change their passwords.

I agree that everything should be locked down (and the LDAP server should only be accessible by servers that need access) once we have added these features to akkounts. However I think the changes for akkounts should go in another issue. For now we need users to be able to change their passwords.
raucao commented 2020-02-07 15:25:09 +00:00
Owner
Copy Link

OK, but then they still don't need to be able to change their email address.

OK, but then they still don't need to be able to change their email address.
greg commented 2020-02-07 15:42:19 +00:00
Author
Owner
Copy Link

Makes sense, I'm fixing the title

Makes sense, I'm fixing the title
greg changed title from LDAP users should only be able to change their own password and email to LDAP users should only be able to change their own password 2020-02-07 15:42:27 +00:00
greg closed this issue 2020-02-14 15:47:18 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
feature/letsencrypt_proxy_validation
jammy_jellyfish
chore/replace_postgres_primary
chore/akkounts_configs
feature/libretranslate
feature/deploy_new_kredits_software
feature/jitsi-meet
chore/395-gitea_cron
chore/move_zerotier_controller
chore/upgrade_sockethub
chore/move_gitea_and_drone
feature/turn_ip_config
feature/103-chef_15
feature/chef_15
dev
Labels
Clear labels   
service
accounts
Kosmos Accounts

  
service
discourse
Kosmos Community Forums

  
service
drone-ci
Kosmos Drone CI

  
service
email
mail.kosmos.org

  
service
garage
S3-compatible object storage

  
service
gitea
Kosmos Gitea

  
service
ipfs
Kosmos IPFS

  
service
mastodon
kosmos.social

  
service
postgres
Database cluster

  
service
remotestorage
Portable data storage for the Web

  
service
wiki
Kosmos Wiki

  
service
xmpp
Kosmos Chat

  
bug

Something is not working

  
design

Graphic/visual design

  
dev environment

Config, builds, CI, deployment, etc.

  
docs

Documentation

  
duplicate

This issue or pull request already exists

  
enhancement

Improving existing functionality

  
feature

New functionality

  
good first issue

Dive in, and start contributing

  
idea

Something to consider

  
invalid

Not a bug

  
kredits-1

Small contribution

  
kredits-2

Medium contribution

  
kredits-3

Large contribution

  
on hold

Currently not actionable

  
ops

Manual IT ops activities

  
question

Looking for an answer

  
release
major

  
release
minor

  
release
patch

  
security

All your base are belong to us

  
ui/ux

User interface, process design, etc.

  
wontfix

This won't be fixed

No Label
service
accounts
service
discourse
service
drone-ci
service
email
service
garage
service
gitea
service
ipfs
service
mastodon
service
postgres
service
remotestorage
service
wiki
service
xmpp
bug
design
dev environment
docs
duplicate
enhancement
feature
good first issue
idea
invalid
kredits-1
kredits-2
kredits-3
on hold
ops
question
release
major
release
minor
release
patch
security
ui/ux
wontfix
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
greg
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: kosmos/chef#128
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?