Apple Mac OS X 10.8.2.4 волшебных расчета треугольников

What you describe sounds consistent with the AD users not being in the Mac server's SACLs (Service Access Control Lists). You can check this by going into Server.app -> Users in the sidebar -> from the popup menu above the users list choose "Users from ADDOMAIN" -> select chalstead (or some other AD user you can test with) -> from the action (gear icon) menu under the user list choose "Edit Access to Services" -> check whether the "File Sharing" service is enabled.

If File Sharing is not enabled for the user(s) in question, you can enable it per-user (either individually or by selecting a bunch of them and setting them all at once), but it's usually easier to manage if you set it by group. The interface is essentially the same, just in the Groups rather than Users section (and then verify it in the Users section).

I've seen it fail to update properly after a change (essentially, it seems to cache the SACL failure); this seems to go away if you leave it long enough, but if nobody's using the Mac server yet, you can use the brute force solution: reboot the server.

EDIT: once that's fixed, you may also have to enable AD's Kerberos single-sign-on on the Mac server. If you're prompted for credentials when connecting to the Mac server, but allowed in when you supply them, you probably need to set this up:

• Check whether the Mac is Kerberized properly with the command sudo ktutil -k /etc/krb5.keytab list -- if the result includes entries ending "@ADDOMAIN.EDU", you're good. (Note: it will also contain a bunch of "@LKDC:SHA1.hexgibberish" and maybe also "@MAC-SERVER.whatever" entries; ignore these.)
• If it needs to be set up, use the command sudo dsconfigad -enableSSO, then recheck with ktutil.