Active Directory is a directory service developed by Microsoft to store all information and settings for a deployment in a central database. Active Directory allows administrators to assign security policies on shares, files and directories.
Syneto Storage integrates fully with Active Directory.
Joining an Active Directory Domain
If clients are part of a Windows Active Directory domain, the storage appliance must also be joined to the Active Directory before authentication will work on the active shares.
Supported Windows Servers:
- Windows 2003 Server SP2
- Windows 2008 Server SP2 (Due to a known bug in Windows 2008 Server SP1, please upgrade to SP2)
Joining an Active Directory domain is made from the Networking configuration page.
To successfully join an Active Directory domain you must ensure the following:
- The DNS must be configured to a DNS server part of the Windows domain. In most of the cases, the AD server also acts as a DNS server
- The Domain Name of the storage must identical with the AD domain name. For example: ‘domain.example.com’
After you verified the above requirements, you could check that the DNS system finds the correct domain controller(s), enter Storage CLI and execute the following command:
$ host -t srv _ldap._tcp.dc._msdcs.domainname
Note: If this request returns multiple servers, please check that all servers are still functioning as domain controllers (they have not been removed before). If one or more servers are no longer present, please verify the following:
- Server Manager -> Roles -> DNS Server -> DNS -> [SERVERNAME] -> Forward Lookup Zones -> _msdcs.domain.name -> dc -> _tcp -> Remove _kerberso and _ldap entries pointing to servers that no longer function as domain controller / ldap servers
- Server Manager -> Active Directory Domain Services -> Active Directory Sites and Services -> Sites -> Default-First-Site-Name -> Servers Remove all server entries that point to computers no longer working as domain controllers
Most of the time the Active Directory controller, Kerberos Admin Server and Kerberos Password server are all hosted on the same Windows server (in the example below admaster.dev.syneto.net).
The Username and Password are used only once, for joining the AD, and must belong to a user that has permission to join a computer to that particular domain. The Administrator user will work, but in some cases, another user with the proper permissions might be used. There might be times when you would like to limit the access of your storage to a certain organizational unit within your domain. You can do that by clicking “Limit access to this organizational units”.
The Lmauth level is a security setting that determines which challenge/response authentication protocol is used for network logons. If you are using Windows 2008 R2 you need to set this to level 4.
If your join fails and the following lines are present in your /var/log/messages file then you should definitely use level 4 instead on level 2 for your Lmauth Level:
ndr_rpc_bind: smbrdr_ctx_new(S=servername, D=DOMAIN.NAME, U=Administrator), err=48
Feb 16 16:25:43 storage2 smbd: [ID 700049 daemon.error] smbd: failed locating domain controller for DOMAIN.NAME
If the storage still doesn’t join reset the Domain Administrator password by re-entering the original password (this a known issue on Windows where DES encryption keys are not created for the administrator under certain circumstances: see http://support.microsoft.com/kb/248808)
User Mapping in an Active Directory Domain
When the Storage is joined with the AD, a new option will appear when clicking on a user: Map to user/group. This allows mapping a UNIX user or group to an Active Directory user or group.
By default, when you join AD, the user used to join to the active directory will be automatically mapped to the UNIX user root.
To un-map just map the user to “- none -“.
It is considered good practice to map the root local user to the Administrator AD user so the Administrator account can manage shares.
Use case for a SMB + Active Directory integration
You are in an IT company and want to share a directory containing product development information to all your staff. You want only your developers to be able to add document in that directory and everyone else to have only read access.
Refer to the SMB Workgroup Sharing for information on how to enable SMB sharing on the Storage.
Then configure AD using the information from the beginning of this document.
Now your users will be able to access the shared directory on their Windows computers after they log in with their AD credentials.
But you only want your developers to be able to write in that directory.
So you return to the directory and disable writing for it. Then you add an ACL rule that allows writing for AD group Developers.
Now that you’ve finished the setup upload some documents and test it.
If the storage still doesn’t join reset the Domain Administrator password by re-entering the original password (this a known issue on Windows where DES encryption keys are not created for the administrator under certain circumstances: see