IMHO this should be added on https://wiki.samba.org/index.php/Main_Page as first item below the headline "User Documentation".
If you have a Wiki account, you can edit this text on https://wiki.samba.org/index.php/Samba_Readme_First. Please fix errors, add more infos and links to other wiki pages, and add reasons for the recommendations given here. See the current discussion on the mailing list.
Samba 4 can be run either as plug-in replacement for Samba 3, or as Active Directory Domain Controller (AD-DC).
If you use Samba 4 like Samba 3, it can still run in one of the well known modes: It can behave like a windows client that is sharing directories and printers, or like an NT style domain controller (primary or secondary), or as Active Directory member server.
You can reuse most of your config file smb.conf, or create one following old docs. Run the two daemons smbd (for file sharing) and nmbd (for browsing) like you did with Samba 3. The rest of this page, and most contents of this wiki are not relevant for you.
If you run Samba 4 as Active Directory Domain Controller, you should let one server do only this single task, nothing else!
Let the provision process create the config file smb.conf for you from scratch, and run only the samba daemon. The samba daemon will spawn smbd. Do not use this as file server (except for SYSVOL). Do not run nmbd for directory browsing support. Do not run winbind on the AD server.
If you want an Active Directory Domain Controller and a File Server, run these services on different servers (can be virtual machines). Run only the samba daemon on the AD server. Run the daemons smbd and nmbd on the file server, and make the file server an AD member server.
Machines and Users are administrated in Active Directory, not entered into the passwd file.
Most Config (except editing smb.conf) is done by a DomainAdmin user logged on a Client with the RSAT tools, not by root on the AD-server.
AD is difficult to backup, you should run two or more AD-servers in different places replicating each other.
Samba 4 is work in progress, use only the very latest version.
Replicating AD works, replicating SYSVOL is not yet implemented.
Most Linux distributions do at the time of this writing not contain Samba 4 in AD-mode, or only a buggy old version. A notable exception are the packages from Sernet, and the Sernet Appliance. Compiling Samba yourself is very easy, and is often the best way to get a correctly working version of it.
Active Directory requires full support for Windows-ACLs, at least for SYSVOL. Thus your unix filesystem must support extended attributes, and ideally unix-acls. If you are using an ext3-filesystem, you must specify the mount-options user_xattr and acl. If you are using ext4-filesystem, this is not required, both are active by default.
Active Directory requires Kerberos and a DNS server. It is critical that these services work correctly, and that samba can control both of them. Samba can provide both functions internally, and unless your setup is very complex, you should usually let it do this. You should at least start in this mode, and maybe later switch to the bind DNS-server if required.
In case you do not yet have much experience with Active Directory Servers: The network configuration of the AD server(s) and all clients must be set up to query only DNS-server(s) of AD-server(s), never any DNS-server that does not know all details of the AD-domain. The DNS server of AD should forward all queries for non-AD hosts to a different DNS server, that can answer those queries.
In case you have not yet much experience with Kerberos: Kerberos requires precise clocks. You should run ntpd on all AD-servers, and let the AD-server set the clocks of the clients. Kerberos needs a 'realm'. You should name this based on your official internet domain name, like when creating a new subdomain. For example if you own the internet domain name 'greatcompany.com', you could use 'directory.greatcompany.com'. You can choose an arbitrary name for the subdomain, but do not use a fantasy domain name, because somebody might later register that as official internet domain name. Then your Active Directory will likely develop several serious strange symptoms, that are difficult to cure. Do not assume that you are safe because your choice contains a currently non-existent top-level-domain.