Using an existing directory<<


:uk:/:us: Message template (english)

Salut !

Ça fait longtemps depuis la dernière fois dont j’ai parlé français. J’ :heart: le français et je peux l’en comprend tout de suite mais je ne crois pas qui je puisse jamais m’exprimer sans faire-le trop compliqué. Un peu comme cette phrase-ci.

Alors, si c’est bien avec vous, j’vais changer à anglais. For what it’s worth, I’m better relating things across in English than in my own native Spanish anyway. :smiley:

My YunoHost server

Hardware: vSphere 7 VM, deployed from Yunohost ISO image
YunoHost version: (stable)
I have access to my server : SSH, console, web admin portal, web user portal (and added Cockpit on my own)
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : yes…then no.
If yes, please explain:
I had modified the NGINX config files but it’s back to stock

  • [1.A OWN CERTS]
    To keep Let’s Encrypt API calls low, and avoid adding HAProxy settings for each domainto be validated Instead I request wildcard multi-domain certificates, or rather certificate (single) on a Linux host then push/pull/transform from Linux right into macOS’ keychains, still in macOS (since it has AD-integrated Kerberized SMB shares) drop a PFX version of the cert, hard-linked into many for IIS centralized certs. Other Linux hosts it just clones /etc/letsencrypt and sync daily. I had done this in Yunohost already but then I learned that each would be requested cert has its own subdomains. I deleted the domains and added them back and finally ran the diagnostics all through the admin GUI.

  • [1.B OWN ROOT]
    The local root CA was imported (dpkg-reconfigure ca-certificates) into Yunohost’s Debian’s trusted roots.

  • [2 NFS MOUNTS]
    I should probably mention I added systemd-managed NFS mounts–the disk for the system is tiny.

  • [3 JOURNALD]
    Oh, and I switched journald to volatile.

  • [4 COCKPIT]
    Added Cockpit, modified network so it’s manageable in Cockpit:

Description of my issue

I’d love if you could offer pointers on how to setup Yunohost with my existing directory service’s userbase. ← that’s it. Before I go into tangents.

( this is pretty much filling at this point )

Normally I’d set it up using realmd --it does everything in one step :heart: – but I’m not sure how system-deep LDAP goes in Yunohost. Then I found this and this that made me stop and ask.

For the directory service I use Active Directory, forest domain level WS2016, DCs are WS2022. LDAP, LDAP wTLS and LDAPS should all be possible, unless a custom store au Mozilla Firefox is used.

From the little I can gather seeing other posts, is the base DN, I assume. Is it possible to modify at all? Or, maybe do the work in Active Directory so from Yunohost’s POV it’s acceptable? There this proprietary-named LDAP in AD, “ADAM”, which might be useful for this. I’ve never used it before but it’s supposed to save a server (bc it’s light–or what Microsoft thinks it’s light) and hopefully it can be used for natting LDAP too, so to speak.

Any advice is immensely appreciated. I’ll start digging around in the meantime. :nerd_face:


For us, merging or use an external LDAP (or Active Directory), is clearly an advanced used case. We don’t know how to do that properly. In the regular contributors i think only one knows Active Directory…
So for now we don’t even know how to use properly an external openldap (for example from an other yunohost instance) so i think your hope about using a directory from AD seems really difficult. But feel free to make research on this topic and document it for others users if you find something.
We are also open for suggestion about LDAP design. As i said we are not expert in LDAP things…

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.