wondering if you got any further with the ad hook up
i have similar connection
but didnt use the corp. before domain
a question if you dont mind ,,,,
why did you use corp.
the realm field should have FQDN...
i have tried many variations ,,,but works best with just the domain part
eg .....
but refuses to allow me to change any permissions on folders..
Posted here in case others wish to correct, elaborate, respond, and/or comment.The ADS 1.0 package functionality is broken in several ways as you have discovered. And don't bother with the W2K8, it simply isn't supported - period.
AuthenticationFor authentication in my W2K3 A/D domain, I should have been able to authenticate in either fashion:
username: <pre-W2K>\username (ex: terraflora\testuser)
and/or
username: <fqdn>\username (ex: corp.terraflora.com\testuser)
username: username@<fqdn> (ex: testuser@corp.terraflora.com)
Instead, I had to use:
username: <first_dotted_part_fqdn>\username (ex: corp\testuser)
The users and computer objects in my domain reside in an OU container such as:
.\MyBusiness\Users and
.\MyBusiness\Computers leaving the standard OU containers as "default" as possible. This is similar in design to MS SBS 2K3 where the objects do not reside in the default A/D Users & Computers OU container.
Folder PermissionsNot possible as the file system on the DNS-343 is EXT2/3 ... at least not without some form of 'fun_plugging' or other hack - which shouldn't be required IMHO.
From what I gather, joining the DNS-343 to an A/D domain should allow an Administrator to control access to shared folders by assigning user/group to a shared folder. An Administrator would assign 'Administrative' access to the 'Volume_##' folders to prevent direct access by others, share folders, and assign user/group as required to the shared folder.
HTH,