# systemctl status - 389 Directory Server localhost.
This will also install some sample data and start the instance right after it’s created:ĭuring the installation a systemd unit file called is created and enabled so the instance is automatically started on boot. You should change the highlighted lines to set a more secure password and alter the domain. To see all available options including a short description one can run dscreate create-template which generates an example inf answer file.
Here’s an example that will serve as the basis for any further configuration: Install Directory Server (interactive mode)īut the most convenient way is probably to create an instance from what’s called an inf answer file. There’s an interactive mode that goes through all available options one by one Create an instanceĪ 389ds instance can be created through dscreate. A convenient tool to complement the cockpit UI plugin in this regard is Apache Directory Studio.Ĭockpit can be enabled and started right away:Īfter that it’s available at For 389ds we have to do some homework first and… 2. However, this does not have all the features of the original admin console implemented yet (e.g. If you still want to use a graphical user interface to interact with 389ds there is a UI plugin for cockpit that can be installed through The 389 admin console that’s still referred to in some places in the official documentation has been deprecated for a while. Installation on Fedora or RHEL/CentOS is farily straightforward:
, the importance and implications of this, of course, depend on the use case) this series of posts will look at the 389 Directory Server and how to set it up in a secure manner. Both do work really well but since ApacheDS lacks at least some features (e.g. Two notable free and open source implementations with a more modern codebase than OpenLDAP are Apache Directory and Redhat’s 389 Directory Server. There are quite a few LDAP server implemenations, the most prominent probably Microsoft’s Active Directory and OpenLDAP. For same-sign on purposes it is the de-facto industry standard as a reliable and secure technology and will probably stay relevant for a really long time to come. on the internet these days, LDAP is still widely used for various use cases. While more modern technologies like OpenID, OAuth or SAML are often used for authentication and authorisation purposes when it comes to applications, APIs etc. The Lightweight Directory Access Protocol or LDAP for short has been around for quite a while.