How Rockstor used to work with Active Directory

Wiki
1

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.

Services_screen_AD.png1011×405 56 KB

A form is then dsiplayed to input various parameters

AD_config_form.png852×579 50.2 KB

Following are the input fields with descriptions (INSERT REAL’ISH INPUT PARAMETERS HERE FOR REFERENCE)

  1. Windbind Domain -- (AD or domain controller to connect to. Example: ???)
  2. 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.
  • Winbind ADS Realm -- When the ads Security Model is selected, this allows you to specify the ADS Realm the Samba server should act as a domain member of.
  • Winbind Domain Controllers -- Use this option to specify which domain controller winbind should use. Example: ???
  • Template Shell -- When filling out the user information for a Windows NT user, the winbindd daemon uses the value chosen here to to specify the login shell for that user.
    • /bin/false
    • /bin/sh
    • /bin/bash
    • /bin/nologin
    • /bin/tcsh
    • /bin/csh
  • Allow offline login? -- Description ???

    • 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.