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

Enable LDAP support on ejabberd #123

New Issue
Closed
opened 2020-01-28 17:09:56 +00:00 by greg · 19 comments
greg commented 2020-01-28 17:09:56 +00:00
Owner
Copy Link

Follow-up to #122
Refs #107

I think it's already time to add a feature to akkounts to change your LDAP password without having to use the command-line

Steps

  • Create LDAP users for 5apps
  • Switch xmpp.5apps.com vhost to LDAP
  • Research the SASL downgrade with LDAP (warning on Conversations)
  • Prepare the documents for the new users in LDAP
  • Document how to accept the SASL downgrade on Conversations in a new page on the wiki
  • Get all the users' email addresses to contact them
  • Prepare an email for users with info about the migration and changing their new passwords, including a link to the wiki page with instructions on how to accept the SASL downgrade on Conversations
  • Prepare the Mediawiki config change + create read-only credentials
  • Create LDAP users
  • Send the emails for user with info about the migration and changing their new passwords in advance, with the planned switch date/time
  • Switch kosmos.org to LDAP
Follow-up to #122 Refs #107 I think it's already time to add a feature to akkounts to change your LDAP password without having to use the command-line ## Steps * [x] Create LDAP users for 5apps * [x] Switch xmpp.5apps.com vhost to LDAP * [x] Research the SASL downgrade with LDAP ([warning on Conversations](https://github.com/siacs/Conversations/issues/2498)) * [x] Prepare the documents for the new users in LDAP * [x] Document how to accept the SASL downgrade on Conversations in a new page on the wiki * [x] Get all the users' email addresses to contact them * [x] Prepare an email for users with info about the migration and changing their new passwords, including a link to the wiki page with instructions on how to accept the SASL downgrade on Conversations * [x] Prepare the Mediawiki config change + create read-only credentials * [x] Create LDAP users * [x] Send the emails for user with info about the migration and changing their new passwords in advance, with the planned switch date/time * [x] Switch kosmos.org to LDAP
greg self-assigned this 2020-01-28 17:09:56 +00:00
raucao commented 2020-01-28 21:11:05 +00:00
Owner
Copy Link
* kosmos/akkounts-api#4 * kosmos/akkounts-web#5
greg commented 2020-01-29 14:19:44 +00:00
Author
Owner
Copy Link

Interesting, we should be able to let users change their LDAP password with their XMPP client if we want to: https://docs.ejabberd.im/admin/configuration/#ldap

Usually ejabberd treats LDAP as a read-only storage: it is possible to consult data, but not possible to create accounts or edit vCard that is stored in LDAP. However, it is possible to change passwords if mod_register module is enabled and LDAP server supports RFC 3062.

Interesting, we should be able to let users change their LDAP password with their XMPP client if we want to: https://docs.ejabberd.im/admin/configuration/#ldap > Usually ejabberd treats LDAP as a read-only storage: it is possible to consult data, but not possible to create accounts or edit vCard that is stored in LDAP. However, it is possible to change passwords if mod_register module is enabled and LDAP server supports RFC 3062.
raucao added a new dependency 2020-01-30 16:06:20 +00:00
#127 Change LDAP directory structure to accommodate multiple domains
greg commented 2020-02-06 12:24:18 +00:00
Author
Owner
Copy Link

I have prepared the 5apps XMPP migration to LDAP.

The data will look like this. A filtered role, cn=xmpp_role,ou=5apps.com,cn=users,dc=kosmos,dc=org is used to filter accounts that have the xmpp attribute enabled.

The ldap user has ACIs to search and filter on selected attributes and to change passwords, only on 5apps users

# 5apps.com, users, kosmos.org
dn: ou=5apps.com,cn=users,dc=kosmos,dc=org
objectClass: top
objectClass: organizationalUnit
description: 5apps
ou: 5apps.com
aci: (target="ldap:///cn=*,ou=5apps.com,cn=users,dc=kosmos,dc=org")(targetattr="cn || sn || uid || mail || userPassword || nsRole") (version 3.0; acl "xmpp-5apps-read-search"; allow (read,search) userdn="ldap:///cn=xmpp,ou=5apps.com,cn=users,dc=kosmos,dc=org";)
aci: (target="ldap:///cn=*,ou=5apps.com,cn=users,dc=kosmos,dc=org")(targetattr="userPassword") (version 3.0; acl "xmpp-5apps-change-password"; allow (write) userdn="ldap:///cn=xmpp,ou=5apps.com,cn=users,dc=kosmos,dc=org";)

# xmpp account, used by ejabberd to search for users and change passwords
dn: cn=xmpp,ou=5apps.com,cn=users,dc=kosmos,dc=org
objectClass: top
objectClass: account
objectClass: person
cn: xmpp
sn: xmpp
uid: xmpp
userPassword: [snip]

# xmpp role, used to filter users that have access to XMPP
dn: cn=xmpp_role,ou=5apps.com,cn=users,dc=kosmos,dc=org
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
cn: xmpp_role
nsRoleFilter: (&(objectclass=person)(xmpp=enabled))
Description: filtered role for xmpp on 5apps.com

# user
dn: cn=user,ou=5apps.com,cn=users,dc=kosmos,dc=org
objectClass: top
objectClass: account
objectClass: person
objectClass: extensibleObject
cn: user
sn: user
uid: user
mail: mail@example.com
xmpp: enabled
userPassword: [snip]

The ejabberd config file will look like this. Users can change their own password using their XMPP client

  "5apps.com":
    [snip]
    auth_method: ldap
    ldap_servers: ["ldap.kosmos.org"]
    ldap_rootdn: "cn=xmpp,ou=5apps.com,cn=users,dc=kosmos,dc=org"
    ldap_password: "secret"
    ldap_encrypt: tls
    ldap_base: "ou=5apps.com,cn=users,dc=kosmos,dc=org"
    ldap_filter: "(nsRole=cn=xmpp_role,ou=5apps.com,cn=users,dc=kosmos,dc=org)"

I have tested this in a VM, including changing my LDAP password using Adium. Let me know if you have questions or feedback

I have prepared the 5apps XMPP migration to LDAP. The data will look like this. A filtered role, `cn=xmpp_role,ou=5apps.com,cn=users,dc=kosmos,dc=org` is used to filter accounts that have the xmpp attribute enabled. The ldap user has ACIs to search and filter on selected attributes and to change passwords, only on 5apps users ```ldif # 5apps.com, users, kosmos.org dn: ou=5apps.com,cn=users,dc=kosmos,dc=org objectClass: top objectClass: organizationalUnit description: 5apps ou: 5apps.com aci: (target="ldap:///cn=*,ou=5apps.com,cn=users,dc=kosmos,dc=org")(targetattr="cn || sn || uid || mail || userPassword || nsRole") (version 3.0; acl "xmpp-5apps-read-search"; allow (read,search) userdn="ldap:///cn=xmpp,ou=5apps.com,cn=users,dc=kosmos,dc=org";) aci: (target="ldap:///cn=*,ou=5apps.com,cn=users,dc=kosmos,dc=org")(targetattr="userPassword") (version 3.0; acl "xmpp-5apps-change-password"; allow (write) userdn="ldap:///cn=xmpp,ou=5apps.com,cn=users,dc=kosmos,dc=org";) # xmpp account, used by ejabberd to search for users and change passwords dn: cn=xmpp,ou=5apps.com,cn=users,dc=kosmos,dc=org objectClass: top objectClass: account objectClass: person cn: xmpp sn: xmpp uid: xmpp userPassword: [snip] # xmpp role, used to filter users that have access to XMPP dn: cn=xmpp_role,ou=5apps.com,cn=users,dc=kosmos,dc=org objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: xmpp_role nsRoleFilter: (&(objectclass=person)(xmpp=enabled)) Description: filtered role for xmpp on 5apps.com # user dn: cn=user,ou=5apps.com,cn=users,dc=kosmos,dc=org objectClass: top objectClass: account objectClass: person objectClass: extensibleObject cn: user sn: user uid: user mail: mail@example.com xmpp: enabled userPassword: [snip] ``` The ejabberd config file will look like this. Users can change their own password using their XMPP client ```yml "5apps.com": [snip] auth_method: ldap ldap_servers: ["ldap.kosmos.org"] ldap_rootdn: "cn=xmpp,ou=5apps.com,cn=users,dc=kosmos,dc=org" ldap_password: "secret" ldap_encrypt: tls ldap_base: "ou=5apps.com,cn=users,dc=kosmos,dc=org" ldap_filter: "(nsRole=cn=xmpp_role,ou=5apps.com,cn=users,dc=kosmos,dc=org)" ``` I have tested this in a VM, including changing my LDAP password using Adium. Let me know if you have questions or feedback
👍 1
raucao commented 2020-02-07 17:58:49 +00:00
Owner
Copy Link

LGTM. Then again, I don't know enough about LDAP to have a good opinion on these things.

LGTM. Then again, I don't know enough about LDAP to have a good opinion on these things.
raucao commented 2020-02-13 23:43:54 +00:00
Owner
Copy Link

Just FYI: the tasks in the PR description are not up to date. Some have been done already, and they're missing the LDAP+SASL research for example.

Just FYI: the tasks in the PR description are not up to date. Some have been done already, and they're missing the LDAP+SASL research for example.
greg commented 2020-02-14 13:02:25 +00:00
Author
Owner
Copy Link

The LDAP implementation in ejabberd doesn't support SASL authentication. From the docs:

You can authenticate users against an LDAP directory. Note that current LDAP implementation does not support SASL authentication.

If I understand correctly, the implication is that the user does not send a salted & hashed password to ejabberd, so the ejabberd process has access to a user's password and sends it over to the LDAP server to authenticate. This is considered PLAIN auth, even when both the XMPP c2s connection and the LDAP connect using TLS

I found an RFC, "Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets" on the xmmp.org wiki.

Prosody uses Cyrus SASL to enable SASL against multiple sources, including LDAP. This page links to an old tutorial that's offline right now but I could find it on archive.org

The LDAP implementation in ejabberd doesn't support SASL authentication. From [the docs](https://docs.ejabberd.im/admin/configuration/#ldap-authentication): > You can authenticate users against an LDAP directory. **Note that current LDAP implementation does not support SASL authentication.** If I understand correctly, the implication is that the user does not send a salted & hashed password to ejabberd, so the ejabberd process has access to a user's password and sends it over to the LDAP server to authenticate. This is considered `PLAIN` auth, even when both the XMPP c2s connection and the LDAP connect using TLS I found [an RFC, "Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets"](https://tools.ietf.org/html/rfc5803) on the [xmmp.org wiki](https://wiki.xmpp.org/web/SASL_and_SCRAM-SHA-1#LDAP). Prosody uses [Cyrus SASL](https://prosody.im/doc/cyrus_sasl) to enable SASL against multiple sources, including LDAP. This page links to an old tutorial that's offline right now but I could find it [on archive.org](https://web.archive.org/web/20180204145351/blog.marc-seeger.de/2009/12/30/setting-up-prosody-to-authenticate-against-ldap/)
raucao commented 2020-02-14 16:10:36 +00:00
Owner
Copy Link

OK, so then we need to document exactly what you just commented on the wiki and have a section for Conversations users to explain how to accept the downgrade for now.

OK, so then we need to document exactly what you just commented on the wiki and have a section for Conversations users to explain how to accept the downgrade for now.
greg commented 2020-02-14 18:16:20 +00:00
Author
Owner
Copy Link

I have added a task to create a new page that documents the SASL downgrade on Conversations for existing users. I think it should include a screenshot for it to be clear. The best way I can think of to do that is to create a test kosmos.org user, and then enable both psql and ldap temporarily (with only that user created in LDAP)

I have added a task to create a new page that documents the SASL downgrade on Conversations for existing users. I think it should include a screenshot for it to be clear. The best way I can think of to do that is to create a test kosmos.org user, and then enable both psql and ldap temporarily (with only that user created in LDAP)
raucao commented 2020-02-14 18:19:43 +00:00
Owner
Copy Link

The Conversations issue contains a screenshot of it, no?

The Conversations issue contains a screenshot of it, no?
greg commented 2020-02-15 13:12:36 +00:00
Author
Owner
Copy Link

The Conversations issue contains a screenshot of it, no?

It doesn't

> The Conversations issue contains a screenshot of it, no? It doesn't
raucao commented 2020-02-15 14:44:08 +00:00
Owner
Copy Link

I was able to find it easily from just a user's description in that issue (maybe copy that to the page?), so uploading a screenshot after we've done the normal switch should be enough.

I was able to find it easily from just a user's description in that issue (maybe copy that to the page?), so uploading a screenshot after we've done the normal switch should be enough.
greg commented 2020-02-17 13:31:57 +00:00
Author
Owner
Copy Link

I have created a page to document the SASL downgrade: https://wiki.kosmos.org/Services:XMPP:SASL_downgrade

We can add a screenshot to it right after the switch

I have created a page to document the SASL downgrade: https://wiki.kosmos.org/Services:XMPP:SASL_downgrade We can add a screenshot to it right after the switch
greg commented 2020-02-17 16:49:01 +00:00
Author
Owner
Copy Link

I prepared this email, any feedback? I put it on a Pad so it's easy to edit https://cryptpad.fr/code/#/2/code/edit/uBJev+Y8s1El0zX-ElnleEfQ/

I prepared this email, any feedback? I put it on a Pad so it's easy to edit https://cryptpad.fr/code/#/2/code/edit/uBJev+Y8s1El0zX-ElnleEfQ/
👍 1
raucao commented 2020-02-17 16:57:23 +00:00
Owner
Copy Link

I made some small edits. Should be good to go.

I made some small edits. Should be good to go.
raucao commented 2020-02-17 21:23:02 +00:00
Owner
Copy Link

Regarding the steps/checklist: I think the emails should be sent out before the switch, and they should contain the date and time for when their password stops working, no?

Regarding the steps/checklist: I think the emails should be sent out before the switch, and they should contain the date and time for when their password stops working, no?
greg commented 2020-02-18 11:37:29 +00:00
Author
Owner
Copy Link

Regarding the steps/checklist: I think the emails should be sent out before the switch, and they should contain the date and time for when their password stops working, no?

Yes, I have updated the steps. I will change the email in the pad and will announce the switch date and time as soon as it's set

> Regarding the steps/checklist: I think the emails should be sent out before the switch, and they should contain the date and time for when their password stops working, no? Yes, I have updated the steps. I will change the email in the pad and will announce the switch date and time as soon as it's set
greg commented 2020-02-18 12:05:10 +00:00
Author
Owner
Copy Link

I have added the date and time of the switch to the email, as well as created a second email template for users that already had a Wiki account: https://cryptpad.fr/code/#/2/code/edit/uBJev+Y8s1El0zX-ElnleEfQ/

I will pair with @galfert on the switch, we have set the date to Thursday at 13:00 GMT

I have added the date and time of the switch to the email, as well as created a second email template for users that already had a Wiki account: https://cryptpad.fr/code/#/2/code/edit/uBJev+Y8s1El0zX-ElnleEfQ/ I will pair with @galfert on the switch, we have set the date to Thursday at 13:00 GMT
greg commented 2020-02-20 08:59:52 +00:00
Author
Owner
Copy Link

I have sent the emails with a unique generated temporary password and instructions for users without a wiki account, and with instructions for users with a a wiki account

I have sent the emails with a unique generated temporary password and instructions for users without a wiki account, and with instructions for users with a a wiki account
greg commented 2020-02-20 13:38:26 +00:00
Author
Owner
Copy Link

Paired with @galfert to perform the migration, closing this one

Paired with @galfert to perform the migration, closing this one
greg closed this issue 2020-02-20 13:38:27 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
bkero bumi fsmanuel galfert greg hueso raucao slvrbckt
No Assignees greg
2 Participants
Notifications
Due Date
No due date set.
Depends on
#127 Change LDAP directory structure to accommodate multiple domains
kosmos/chef
Reference: kosmos/chef#123
No description provided.
Delete Branch "%!s()"

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?