The CIFS/Samba implementation in FreeNAS is excellent, we have several FreeNAS boxes and VMs going in an active directory enviroment, using AD for permissions on the shares. It's also extremely easy to set up and configure.
Once we've set up the FreeNAS box and enabled the CIFS/Samba service, we add the following to the 'Auxiliary Parameters' box in the CIFS service settings:
client use spnego = yes
winbind enum groups = no
winbind enum users = no
winbind separator = +
winbind use default domain = yes
wide links = no
Some of this may be unnecessary, but make sure to keep the 'wide links = no' in there as it mitigates a potential samba directory traversal vulnerability.
You can the create your shares. To set permissions via AD, we would add the following line to the 'Auxiliary Parameters' box for each individual share with the groups and/or users we want to have access to the share:
Valid Users = @OURDOMAIN+Somegroup @OURDOMAIN+'Some Other Group' OURDOMAIN+someuser OURDOMAIN+someotheruser
Note the groups preceded by '@', everything is separated by spaces, and groups or users with a space in their name are single-quoted.
FreeNAS installs and runs on FreeBSD rather than Linux, which allows it to include things like ZFS, but if you're determined to use Linux, OpenFiler is the Linux-based version of the same project.
If you do want to roll your own rather than use one of these distros (though they will simplify things for you immensely), you also might want to look into Likewise as an alternative to Samba for getting your box on the AD domain.
EDIT: Wow, sounds like you've got a lot of shares to migrate -- you may be able to script the addition of new shares, but be careful -- the smb.conf file gets overwritten from the /conf/config.xml file in FreeNAS each time the system restarts. You might be able to create the xml share definitions from your sharenum output to then paste into copfig.xml, using an example share you make as the template, but these get their own uuid from FreeNAS so I'm not sure how that will work -- I suggest experimenting after install and before you migrate.
Best Answer
When you connect to the Samba box from a Windows client Windows will try and authenticate with the cached credentials used to login to Windows. If Samba isn't configured with a matching username and password in it's database (local tdbsam, Active Directory, LDAP etc) then it considers this a bad login, hence prompting you for good credentials.
You can map all bad login attempts to a guest account using:
map to guest = Bad UserAnd configuring a guest account (make sure this has unix permissions for the share) with:
guest account = nobody(nobody being the default)And you may need
guest ok = yesin the share definition too.All of this will have the effect of making connections to the box appear to automatically login.