Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[access]

DNS343
Firmware 1.03 ADS 1.0


recently purchased dns343...

was attracted by the ADS support

Well that was a mistake...

after hours of messing around i finally log on here and after a few hours trolling and reading i find that the whole thing is fairly well broken......

I like other members have managed to get it partially working in AD....

That is i can see my users and user groups and can get the device to show in network list


Double clicking results in a password box that wont work
addressing the device via IP address allows full access no password...
creating a folder from any machine assigns that machines credentials only
any attempt at changing security on created folder fails....


can the Admins here please let me know when ver 1.04 fw will be released to fix these problems
and allow Ad to work properly??

[access]

 
pasted from another thread 2 months ago......

Dlink people your flyer on this product says AD support?


Please reply to me --- not flaming just want an answer


Re: ADS 1.0: Active Directory & Authentication Partially Broken
« Reply #12 on: December 17, 2009, 03:01:29 PM » Quote 

--------------------------------------------------------------------------------

There hasn't been much response from D-Link Engineering on this one.  I'm not certain if the silence should be taken as "will not fix", "we're so busy on projects it isn't funny any more", or "we're working on it ... but we're so busy on projects it isn't funny any more"

 


In any case, a quick response from their side would be most appreciated.

Cheers,

[access]

below was the most helpful post on the forums
however i got mine partially working without the corp. part

Please dlink engineers look into this before you add extra features

fix the ADS  feature that doesnt work

this post below was  6 months ago

 ADS 1.0: Active Directory & Authentication Partially Broken
« on: September 23, 2009, 03:20:39 PM » Quote 

--------------------------------------------------------------------------------

Hi All,

After some research, I've succeeded in getting 'Active Directory' functionality to work with F/W 1.03 & ADS Package 1.0.   I've managed to accomplish some connectivity (authentication) by configuring the Device Settings with:


Username  : DNSAdmin              <A/D Account /w Domain priviledges>
Password  : DNS343b4605a!
DNS1      : Provided via DHCP     <A/D Integrated>
DNS2      : Provided via DHCP     <A/D Integrated>
Host Name : DNSTORNAS01
Workgroup : TERRAFLORA
Realm Name: CORP.TERRAFLORA.COM   <internal A/D domain, NetBIOS is terraflora>
AD Server : DC1terraflora01



Note that the DNS-343 and test workstation were restarted between tests.


TESTS:

1) Behavior when selecting Active Directory as the Network Type so as to allow the DNS-343 to join the domain:

   RESULT:

•The computer object appears in A/D as expected - displays a 'success' message.
•Moving the object to an OU still allows access to the object from 'Microsoft Windows Network'


  'Microsoft Windows Network'

•The DNS-343 object (DNSTORNAS01) appears as expected in TERRAFLORA.



2) Behavior when attempting to connect using DC1TERRAFLORA (Domain Controller, LMCompatibilityLevel=2):

   RESULT:

•Double-clicking the DNSTORNAS01 object from 'Microsoft Windows Network' displays the username/password prompt.
•Using the IP Address (\\###.###.###.###) displays the shared object contents.


   EXPECTED BEHAVIOR:

•Shared object contents should have been displayed when double-clicking the DNSTORNAS01 object from 'Microsoft Windows Network'
•Selecting an object displayed inside DNSTORNAS01 should prompt for credentials if required.



3) Behavior when attempting to connect using a domain workstation (LMCompatibilityLevel=0, LMCompatibilityLevel=2, and/or LMCompatibilityLevel=3):

   RESULT:

•Double-clicking the DNSTORNAS01 object from 'Microsoft Windows Network' displays the username/password prompt.
•Using the IP Address (\\###.###.###.###) displays the shared object contents.


   EXPECTED BEHAVIOR:

•Shared object contents should have been displayed when double-clicking the DNSTORNAS01 object from 'Microsoft Windows Network'
•Selecting an object displayed inside DNSTORNAS01 should prompt for credentials if required.



4) Behavior when attempting to connect by mapping the resource using a command prompt:

   NET USE X: \\DNSTORNAS01\Volume_1 /USER:<username> *
   NET USE X: \\###.###.###.###\Volume_1 /USER:<username> *


   RESULT:

•The drive letter is successfully mapped.



5) Account Name/Password supplied at prompts throughout the tests:

   RESULT:

•Account name and password supplied had to be:

     Username: <REALM>\<username>    (ex: CORP\Administrator)
     Password: <password>            (ex: DNS343b4605a!)


   EXPECTED BEHAVIOR:

•Should have had to supply the following:

     Username: <WORKGROUP>\<username>   (ex: TERRAFLORA\Administrator)
     Password: <password>               (ex: DNS343b4605a!)



In summary, there continues to be an issue with prompting for username/password when initially double-clicking the DNS-343 object from 'Microsoft Windows Network'.  Additionally, there appears to be and issue with the credentials that need to be passed for authentication; in my tests, I should have had to supply TERRAFLORA\<username> and not CORP\<username>.


Cheers,

[hilaireg]

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.


Authentication

For 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: [email protected])


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 Permissions

Not 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,

[access]

Thanks for posting so quickly hilaireg

What's annoying is there seems to be no response from Dlink on this....

They have released and adverstised this functionality and it doesnt work...

The problem is there and easily found (replicated)
they seem to be working on other features rather
than fixing the ones that are busted...


Unfortunately I dont have the luxury to wait if a fix isnt coming SOON...
Need to move shared folders and "ad" user/group security from server drives
to a  quality NAS

Will be returning the DNS343 and getting something that really supports "AD"
not just advertised to support it

should not be advertising it  in there flyers

Correct me if im wrong isnt this false advertising??.

Their lack of replies on here also shows little respect for their customers.

I am in charge of a fairly sizable IT budget
and its experiences like this that don't go down well.
 
 Peter - Dissappointed
 

 
 
 
 

[dsiegel]

You are right, AD does not work as it should on this unit.   Anyone who wants an AD supported box should try something else.    Worse than the fact that AD just doesn't work as it should, if you try to go backwards from AD the box crashes.  Right now mine will not boot and of course I have data on it I need to get to. 

[access]

Thanks to my reseller (MediaByt)
I have gotten a response from Tech support Australia _sydney

Speaking with Danny and Dean & Dlink See belowreply to my reseller


Graeme,
We are working on the issue with our development team in Taiwan, I cannot give you a eta at this stage, if the customer does not want to wait I can offer you a credit back via your distributor


Dean Williams
Consumer Product  Manager
D-Link Australia Pty. Ltd.      Head Office (Sydney)
Building A, Level 3, 11 Talavera Rd
North Ryde, NSW, 2113   
 
      
Direct:
Fax:
Mobile:
Email:
Web:    +61 (0)2 8899 1800
 +61 (0)2 8899 1883
 +61 (0)2 8899 1868
 +61 (0)409 173 615
 [email protected]
 http://www.dlink.com.au


I have contacted Danny@Dlink  directly and asked for a tighter time frame on the fix as it   
will influence my decision on keeping the box.

I suggest other people do the same abs this migh speed up the process
will keep the forum advised on the reply from Danny/Dean

[Wilson]

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.


Authentication

For 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: [email protected])


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 Permissions

Not 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.

Hi as I know, the account of 343 is managed by Samba, so if you want to change the permission, you need to logon to the UI and make such changes.

HTH,

[Wilson]

below was the most helpful post on the forums
however i got mine partially working without the corp. part

Please dlink engineers look into this before you add extra features


fix the ADS  feature that doesnt work

this post below was  6 months ago

 ADS 1.0: Active Directory & Authentication Partially Broken
« on: September 23, 2009, 03:20:39 PM » Quote 

--------------------------------------------------------------------------------

Hi All,

After some research, I've succeeded in getting 'Active Directory' functionality to work with F/W 1.03 & ADS Package 1.0.   I've managed to accomplish some connectivity (authentication) by configuring the Device Settings with:


Username  : DNSAdmin              <A/D Account /w Domain priviledges>
Password  : DNS343b4605a!
DNS1      : Provided via DHCP     <A/D Integrated>
DNS2      : Provided via DHCP     <A/D Integrated>
Host Name : DNSTORNAS01
Workgroup : TERRAFLORA
Realm Name: CORP.TERRAFLORA.COM   <internal A/D domain, NetBIOS is terraflora>
AD Server : DC1terraflora01



Note that the DNS-343 and test workstation were restarted between tests.


TESTS:

1) Behavior when selecting Active Directory as the Network Type so as to allow the DNS-343 to join the domain:

   RESULT:

•The computer object appears in A/D as expected - displays a 'success' message.
•Moving the object to an OU still allows access to the object from 'Microsoft Windows Network'


  'Microsoft Windows Network'

•The DNS-343 object (DNSTORNAS01) appears as expected in TERRAFLORA.



2) Behavior when attempting to connect using DC1TERRAFLORA (Domain Controller, LMCompatibilityLevel=2):

   RESULT:

•Double-clicking the DNSTORNAS01 object from 'Microsoft Windows Network' displays the username/password prompt.
•Using the IP Address (\\###.###.###.###) displays the shared object contents.


   EXPECTED BEHAVIOR:

•Shared object contents should have been displayed when double-clicking the DNSTORNAS01 object from 'Microsoft Windows Network'
•Selecting an object displayed inside DNSTORNAS01 should prompt for credentials if required.



3) Behavior when attempting to connect using a domain workstation (LMCompatibilityLevel=0, LMCompatibilityLevel=2, and/or LMCompatibilityLevel=3):

   RESULT:

•Double-clicking the DNSTORNAS01 object from 'Microsoft Windows Network' displays the username/password prompt.
•Using the IP Address (\\###.###.###.###) displays the shared object contents.


   EXPECTED BEHAVIOR:

•Shared object contents should have been displayed when double-clicking the DNSTORNAS01 object from 'Microsoft Windows Network'
•Selecting an object displayed inside DNSTORNAS01 should prompt for credentials if required.



4) Behavior when attempting to connect by mapping the resource using a command prompt:

   NET USE X: \\DNSTORNAS01\Volume_1 /USER:<username> *
   NET USE X: \\###.###.###.###\Volume_1 /USER:<username> *


   RESULT:

•The drive letter is successfully mapped.

"Look like 2 & 3 caused by the same problem, only can access through ip but not netbios name. But according to your test, with "Net" command, it works well with both IP and Netbios name"

5) Account Name/Password supplied at prompts throughout the tests:

   RESULT:

•Account name and password supplied had to be:

     Username: <REALM>\<username>    (ex: CORP\Administrator)
     Password: <password>            (ex: DNS343b4605a!)

Hi Access, why logon in this way is wrong. I check my NAS with other branded, it can logon in this way too. As 343 is a device inside a domain, it should be ok to logon in this method.

   EXPECTED BEHAVIOR:

•Should have had to supply the following:

     Username: <WORKGROUP>\<username>   (ex: TERRAFLORA\Administrator)
     Password: <password>               (ex: DNS343b4605a!)



In summary, there continues to be an issue with prompting for username/password when initially double-clicking the DNS-343 object from 'Microsoft Windows Network'.  Additionally, there appears to be and issue with the credentials that need to be passed for authentication; in my tests, I should have had to supply TERRAFLORA\<username> and not CORP\<username>.


Cheers,

[dsiegel]

dlink support is awful when it comes to this issue.  They should just admit that it doesn't work.  Instead, they have me running in circles with the device doing all kinds of things that were a complete waste of time. 

[chaicka]

@access,

If you have check the posts in this forum, I trust you will find mine, hilaireg and a few others on Active Directory related issues. Well, we have waited for few months now and still no sign of real Active Directory support. In fact, I have waited since its early firmware prior to 1.02 for Active Directory support. Again and again, I am getting disappointment after disappointment.

If use of DNS-343 with Active Directory and real NAS manageability is what you are looking for, then just return and refund. It's pointless to wait for fix when the next firmware release would most likely be not a full fix that truly fully supports Active Directory that is expected of a true NAS.

I have given up and in mist of replacement - QNAP. Though more expensive, it truly provides manageability of what's expected of a NAS (even for its non-Pro series).

[access]

@access,

If you have check the posts in this forum, I trust you will find mine, hilaireg and a few others on Active Directory related issues. Well, we have waited for few months now and still no sign of real Active Directory support. In fact, I have waited since its early firmware prior to 1.02 for Active Directory support. Again and again, I am getting disappointment after disappointment.

If use of DNS-343 with Active Directory and real NAS manageability is what you are looking for, then just return and refund. It's pointless to wait for fix when the next firmware release would most likely be not a full fix that truly fully supports Active Directory that is expected of a true NAS.

I have given up and in mist of replacement - QNAP. Though more expensive, it truly provides manageability of what's expected of a NAS (even for its non-Pro series).

Yep ......I think even in the short time here I am very dissapointed...
No contact back from the email sent to Sydney office...
so its a return it to them...funny you mention QNAP as i have already marked that as a replacement if necessary

[D-Link Multimedia]

If you would like to beta 1.04 with ONLY the ADS fix please contact me by Private Message.

[D-Link Multimedia]

and just another note...but this version should work with Windows 2008 as well.

[tailslide]

I'm running into the same troubles plus a couple others.. the ADS authentication stops working after a couple days and the only solution is to stop and start the addon, at that point it starts working again. This is not a good solution, so I tried uninstalling the ADS plugin.

 It uninstalled OK but now all the screens to setup the built in security are all still disabled!   Is there any way to go back to regular security without copying all the data off the drive, reformatting, and copying it back?

Edit:
Bonus: now it's forgetting my shares and making them reconfigure them when I restart the plugin