This is the old implementation which is not valid as of 3.8-9. It’s retained here for reference. For current implementation, please see this post.
This is a wikified post documenting the internal implementation details of AD configuration in Rockstor. Please feel free to update/edit this post to make it better. This will serve as our reference document to help developers make Rockstor work flawlessly with AD.
##User story and implementation summary
User should be able to add their Rockstor system to Active Directory domain controller. We use Samba Winbind Daemon to implement this functionality.
##Implementation detail
In the UI’s System → Services page, user clicks on the wrench icon next to AD to configure it.
A form is then dsiplayed to input various parameters
Following are the input fields with descriptions (INSERT REAL’ISH INPUT PARAMETERS HERE FOR REFERENCE)
- Windbind Domain -- (AD or domain controller to connect to. Example: ???)
- Security Model (how clients should respond to Samba. dropdown with following options)
- ads — This mode instructs Samba to act as a domain member in an Active Directory Server (ADS) realm. To operate in this mode, the krb5-server package must be installed, and Kerberos must be configured properly.
- domain — In this mode, Samba will attempt to validate the username/password by authenticating it through a Windows NT Primary or Backup Domain Controller, similar to how a Windows NT Server would.
- server — In this mode, Samba will attempt to validate the username/password by authenticating it through another SMB server (for example, a Windows NT Server). If the attempt fails, the user mode will take effect instead.
- user — This is the default mode. With this level of security, a client must first log in with a valid username and password. Encrypted passwords can also be used in this security mode.
- /bin/false
- /bin/sh
- /bin/bash
- /bin/nologin
- /bin/tcsh
- /bin/csh
After user submits the form, /usr/sbin/authconfig --update <config_form_data>
is executed.
(INSERT EXAMPLE COMMAND EXECUTION AND OUTPUT FROM THE TERMINAL HERE.)
If this command succeeds, it’s assumed that winbind is successfully configured. If not, an error is thrown on the UI and the configuration will not be saved thereafter.
###Service ON/OFF toggle
If the service is switched on, the backend logic is same as described above. i.e., /usr/sbin/authconfig --update <config_form_data>
. After it succeeds, systemctl enable winbind
and systemctl start winbind
are executed.
If the service is switched off, this command is executed: /usr/sbin/authconfig --update --disablewinbind --disablewinbindauth
followed by systemctl stop winbind
and systemctl disable winbind
###Joining AD Domain
The Join Domain button can be used with ads and domain security models.
(INSERT SCREENSHOTS HERE)
Once administrator name and password are entered followed by the submit button, the following backend process is executed. First, winbind service is restarted, i.e., systemctl restart winbind
. Second, /usr/bin/net ads join -U username%password --request-timeout 30
is executed. If these commands fail, an error message is displayed in the UI.