First of all:
I haven't looked at this doc in a while, and I realized that there was a lot of unneccesary steps, so I revised and cleaned it up a bit.
A huge thank you to the Samba Team for providing a window into the weird world of windows! Many thanks and kudos and praise, etc. are due to these people, they are phenomenal! Also thanks to the Heimdal project, Project Cyrus, PADL, and the OpenLDAP team.

Introduction:
This document is meant as a guide to build a fileserver that runs on FreeBSD >= 5.1 which operates seamlessly in a Microsoft Active Directory environment, whether it be Windows 2000 or 2003. Windows domain members (clients) can browse shares on this server as if it were a windows server. Permissions can be granted on a domain user/group basis through Samba's winbind mapping AD sccounts to FreeBSD 5.x's built in POSIX ACLs (using UFS2). All of this is possible from Samba's abilty to use Kerberos/SASL and LDAP to authenticate as if it were a native Windows machine. We will upgrade the stock FreeBSD Heimdal, and install Cyrus-SASL and OpenLDAP to provide this functionality. Other services beside SMB/CIFS can be extended via PAM (ssh,ftp,printing,etc), and an example will be shown using ssh. (Also see http://www.bzerk.nl/documents/ntdomauth/ for an ftp example using pam_winbind). For more in-depth research into Samba and its functionality, please see http://us1.samba.org/samba/docs, an Official Samba Documentation link page. Much of the information in this document is in fact indebted to the links on this page.
For information on mapping principals from alternative kerberos realms to AD principals (i.e. with MIT or Heimdal KDC's) see http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp.

Caveat:
This document assumes an intermediate level of familiarity with basic networking principles, FreeBSD and unix-like systems in general. It also assumes you have a functional Windows 2000 or 2003 Active Directory Domain Controller in your network and you have an account with the administrative right to add machine accounts to the domain. You will need this account information to authenticate to Active Directory. We will not be using Samba's name-services daemon (nmbd) in this scenario, as we are striving to push all naming contexts through DNS.

Nota Bene!! With the new (as of 2/10/2004 - 6 month old according to eeye) Microsoft ASN.1 advisories I would recommend asking your Windows admin (I am assuming windows responsibility does not fall under your position) to patch their servers (see this page for more to come with heretofore unpatched windows vulns) and read and implement measures using this paper from Microsoft:
How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll
to restrict all SSL to v3 or TLS only.

I have added some comments to the config files, please read them. These comments are to explain some of the why/how of features within that particular file. I hope it may help in some way. You will replace the following information in the config files (as described in the howto) with that which is applicable to your realm/domain:

This was done with FreeBSD 5.3 release and works against Win2k 'Native Mode' and 2k3 'Windows Server 2003 Functional Level'.
This is also assuming standard FreeBSD 5.3 install (without samba as a package). FreeBSD 5.3 RELEASE comes with OpenSSL 0.9.7e(?) by default. (You may want to upgrade openssl to the current stable version, 0.9.7g, as of this writing.)

FreeBSD-POSIX ACLs now exist (since FreeBSD 5.1-RELEASE) for UFS2 enabling fine grained permission sets. To activate the ACLs you must edit /etc/fstab to mount the filesystems correctly. You must add the option 'acls' to the filesystems you wish to activate. Example:
cat /etc/fstab
# Device Mountpoint FStype   Options Dump Pass#
/dev/ad0s1b   none   swap   sw        0   0
/dev/ad0s1a   /      ufs    rw,acls   1   1
/dev/ad0s1h   /exp   ufs    rw,acls   2   2
/dev/ad0s1g   /home  ufs    rw,acls   2   2
/dev/ad0s1f   /tmp   ufs    rw,acls   2   2
/dev/ad0s1d   /usr   ufs    rw,acls   2   2
/dev/ad0s1e   /var   ufs    rw,acls   2   2
/dev/acd0     /cdrom cd9660 ro,noauto 0   0
*EOF*

Active Directory's (IMHO) most secure form eschews NetBIOS and places all name service requests within DNS. To begin, edit your /etc/resolv.conf file so that you use your AD domain controller as a nameserver, preferably the primary nameserver; also add the domain name as at least one of the search domains:
cat /etc/resolv.conf
search who.com
domain who.com
#add other search domains here
#This is the AD dc
nameserver: 192.168.129.50
#Add any other dns servers here

Gather necessary source tarballs (x or xx designates latest stable version):
db-4.3.xx.tar.gz with strong crypto (www.sleepycat.com)
heimdal-0.6.x (ftp://ftp.pdc.kth.se/pub/heimdal/src/)
openldap-2.2.x.tar.gz (www.openldap.org)
cyrus-sasl-2.1.xx.tar.gz (http://asg.web.cmu.edu/sasl/)
samba-3.0.x.tar.gz (www.samba.org)

FreeBSD 5.3 comes with Heimdal 0.6.1 (kerberos) installed under /usr. Whatever the version of heimdal, we will upgrade it, to insure past reported vulnerabiltes are properly patched. The stable version as of this writing is 0.6.4, which we will get from source:
Extract heimdal tarball and build:
tar xvfz heimdal-0.6.x.tar.gz
cd heimdal-0.6.x
./configure --prefix=/usr --enable-shared --sysconfdir=/etc
make
At this point back up your su and login files as root, as there will be problems when the heimdal install overwrites these files:
# cp /usr/bin/login /usr/bin/login.bak; cp /usr/bin/su /usr/bin/su.bak
Now install, and overwrite the new files with your backups:
make install
# mv /usr/bin/su.bak /usr/bin/su; mv /usr/bin/login.bak /usr/bin/login

Create /etc/krb5.conf:
cat /etc/krb5.conf
#/etc/krb5.conf
#where you want your logs
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

#Your AD domain FQDN
[libdefaults]
default_realm = WHO.COM

# AD domain, DC FQDNs
[realms]
WHO.COM = {
kdc
default_domain = who.com
admin_server = dc.who.com
}

#Translating all possibles to WHO.COM
[domain_realm]
.who.com = WHO.COM
who.com = WHO.COM
.WHO.COM = WHO.COM

#This is used if you have alternative KDC's in you realm (not windows)
#that you are mapping trust accounts to in the windows domain
#see http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp
#[kdc]
#profile = /home/krb5kdc/kdc.conf

#self-explanatory
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
*EOF*

Since we are using Kerberos auth, at this point you must insure that your box's system clock is within 300 seconds (5 minutes) of your domain controller's clock. FreeBSD's date command is different than Linux and Solaris 9's, I know I am missing something here to automate/convert it.

This example assumes you have the DC server certificate from MS Certificate Services (this is generated from the root cert that must be installed somewhere in the domain so DC's can be connected to via LDAP over SSL). For a guide on how to obtain this certificate click *here*.

Create smb.conf - this is an example that assumes you have the Root CA certificate from MS Cert Services (this needs to be installed somewhere in the domain so DC's can be connected to via LDAP over SSL). These parameters are commented out, you can enable them if you choose to use AD as a LDAP backend. We will use the idmap_rid modules we built to insure consistent rid -> uid/gid maps on any samba server (assuming the same mapping range configured on each). This only works, with one domain, however, as you must set "allow trusted domains = no" for it to work its magic.

The finish line is within reach, but first we must explore FreeBSD's ACL interface.
There are two main commands for our needs: setfacl and getfacl. For greater detail man getfacl or man setfacl. Now that we have the Samba daemons running, we can connect to the DC and extract account information that will be added to this box's current databases.

There is no getent command provided by default in FreeBSD, but you can download the getpwent and getgrent utilities here (md5: a90485ec254c2e9a0a6e4f69c6701716). Alternatively one can use the 'pw' command, which will, if winbind is working properly, populate the db. Remember we used 10001-30000 for our idmap uids and gids, so here is an example: