locked
Azure Active Directory LDAP support RRS feed

  • Question

  • From @BCAlpine via Twitter:

    "Is there a method of exposing azure active directory from office365 as an LDAP service so that we can connect our NAS to it?"

    Thanks,

    @AzureSupport

    Tuesday, April 5, 2016 7:54 PM

All replies

  • We are using a Synology NAS at both our offices and have transitioned out of our internal Active Directory now as we've moved to Azure Active Directory and Windows 10 for all our users.  In doing so though we have had to create secondary usernames and passwords for local file access for the NAS.

    Synology provides Domain joining (which we were previously using), LDAP and SSO Client connectivity. If we could use any of the services to attach to our Azure AD, we would be saving our users multi-username-password problems and they would be much happier! :)

    REF: https://www.synology.com/en-global/knowledgebase/DSM/help/DSM/AdminCenter/file_directory_service_ldap


    KevenD.

    Tuesday, April 5, 2016 9:17 PM
  • One of our forum engineers has provided the following response:

    "No.  o365 is a set of SaaS services that consumes identity from AAD. For workloads on azure  IaaS such as providing ldap legacy access you may consider the following preview https://azure.microsoft.com/en-us/services/active-directory-ds/<o:p></o:p>

    As far as utilizing with NAS,  network attached storage on premises,  I suspect it's possible over VPN or ExpressRoute but as for how well it works... that I  couldn't predict.   As far as utilizing OneDrive for business...  We have a sync for that which wouldn't utilize a network drive. <o:p></o:p>

    Maybe I don't understand the context of the question... <o:p></o:p>

    Regards,
    David "<o:p></o:p>

    Tuesday, April 5, 2016 10:14 PM
  • We recognize the OneDrive for Business as a service we are paying for, but have been unable to utilize it for our needs for the following three reasons:

    1- Sharing doesn't work the way we do.  When we first moved to O365 and got OneDrive Business one of the first things I looked into was migrating our data to it.  I went through support as I could not find a method to create a set of shared directories that was immediately available to all of our users and was informed that was not the way the data can work in ODB.  Instead everyone only ever sees their own files until they go looking through other people's files.  As an organization we don't work that way but instead keep files in folders by category and want to keep them that way.

    2- Most of our users are now using Surface Pros.  SSD space ranges from 128-256GB per device and our shared storage is 460GB of base data and 1.2TB of photos.  We can't possibly house that on all our devices locally.

    3 - Speed is an issue.  When you're working on art files that are ranging on 50mb-500mb in size, having to use web based files means a lot of waiting to open up a file.  Network based NAS storage opens up significantly faster.

    I was looking into the existing Office 365 Admin dashboard and the Azure AD management window has a section called "Domain Services Preview", which has a description of "ENABLE DOMAIN SERVICES FOR THIS DIRECTORY: Enable Domain Services such as domain join, Kerberos, and LDAP."  When I click "YES" to enable this option however I am presented with two select pull downs, the first being the DNS DOMAIN NAME OF DOMAIN SERVICES and the second being CONNECT DOMAIN SERVICES TO THIS VIRTUAL NETWORK.  The first one is populated with all of my domain names for our O365 account, the second isn't populated at all regardless of which domain I select in the first.  This will not allow me to save without something being selected in the second pull down so .. this is where I was hoping we might be able to activate LDAP to our NAS to provide a single point of sign in for our users.  Am I entirely off base here?


    KevenD.


    • Edited by kevend Wednesday, April 6, 2016 5:18 PM
    Wednesday, April 6, 2016 5:16 PM
  • I think the "connect domain services to this virtual network" works only with Networks/Servers hosted in Azure.
    Friday, September 23, 2016 8:15 PM
  • I understand what you're asking Kevin, and I'm attempting to do the same thing.

    The Synology NAS has an LDAPS client builtin that allows the NAS to connect to an LDAP server so LDAP users can be granted permissions on the NAS.

    I have an Azure AD account, and have enabled LDAP services as per MS documentation (requiring certificates, etc), and I am able to connect my NAS ldap client to my Azure AD LDAPS service.  I would have expected at this point to be able to browse users and groups contained in Azure AD, BUT unfortunately Synology doesn't know how to map the correct attributes in order to pull users and groups.  I did contact Synology support to determine the correct attribute mappings and they weren't able to help at all.  this is the only documentation related to attribute mappings from Synology: https://www.synology.com/en-global/knowledgebase/DSM/help/DSM/AdminCenter/file_directory_service_ldap

    I know this has to be possible...there must be a way to map the correct attributes so I can finally start using Azure AD (tied to office 365 identities) to login and consume resources on my sinology NAS.  It's just finding the correct mappings....which apparently no one has ever done...or no one has ever posted....as I've looked for months.

    Friday, November 18, 2016 1:43 PM
  • Kevin,

    I've made progress with attribute mappings between the sinology nas and azure AD.  I'm now able to retrieve users and groups but am still not able to assign permissions to them.  I thought I'd share the mappings now, and you might possibly be able to fill in the holes and share with me.

    in the LDAP client configuration, choose the "custom" profile and edit the profile mappings as such:

    filter\attribute       Mapping Target

    Filter_passwd        objectclass=user

    filter_shadow       

    filter_group           objectclass=group

    group_cn               samaccountname

    group_gidnumber   HASH(objectguid)

    group_memberuid  member

    passwd_uidnumber HASH(objectguid)

    passwd_uid            samaccountname

    passwd_gidnumber

    shadow_uid            samaccountname

    shadow_userpassword  UserPassword

    Now some of these might very well be incorrect, but I can at least retrieve a list of users and groups.

    Joe

    Friday, November 18, 2016 3:34 PM
  • Joe,

    We tried your suggested mappings and did  not get users or groups from Synology web admin panel.

    Were you using command line programs to list users and groups?


    Wednesday, December 21, 2016 3:59 PM
  • I created the mappings via the sinology DSM web interface, under control panel.

    I was able to view users and groups from Azure, but was not able to grant access to them.

    Synology support does not support this at all, and were not able to provide any assistance.

    I ended up removing this config after spending weeks trying to get it to work. 

    And I got a hefty bill from MS for having domain services enabled during this time as well.

    I will have to find another solution....very unfortunate...I might have to convert the business to an MS server.

    Joe

    Monday, January 9, 2017 12:58 PM
  • I created the mappings via the sinology DSM web interface, under control panel.

    I was able to view users and groups from Azure, but was not able to grant access to them.

    Synology support does not support this at all, and were not able to provide any assistance.

    I ended up removing this config after spending weeks trying to get it to work. 

    And I got a hefty bill from MS for having domain services enabled during this time as well.

    I will have to find another solution....very unfortunate...I might have to convert the business to an MS server.

    Joe


    I couldn’t get this mapping to work too and this solution is quite expensive too. I at least was able to map the users. I have created a python script that runs every hour on the diskstation and synchronizes the users from the Azure AD to the diskstation. The accounts are mapped but the passwords not. There is no single sign on but our users can map network drives to the diskstation using their own account. If users are added or removed from the Azure AD the script adds or removes them from the diskstation. The script can be used as a starting point for your own mapping but requires almost certainly adoption to fit the needs of your organization. I have posted the script as a Gist.
    Tuesday, April 11, 2017 10:41 AM
  • Thanks for the script Streck33. The customer running the NAS is under 20 people, with little turn around so I'll likely continue with manual effort, but will keep the script handy for larger customers.

    I'm going to attempt a vpn tunnel to azure from the NAS to see if domain join is possible in that configuration.  Only issue is overall cost...not real feasible to pay hundreds of dollars a month for under 20 people...but feel the need to figure this out as it's been bugging me for quite some time.

    Tuesday, April 11, 2017 11:20 AM
  • Hi Joe,

    Quite the same situation here. We are also about 20 people but with more turn-around (consulting and lot’s of students). I had some spare time and liked to play around so I create the script and thought it might be helpful to others too (until synology offers proper support).


    • Edited by Streck33 Tuesday, April 11, 2017 12:18 PM
    Tuesday, April 11, 2017 12:11 PM

  • Thank you for putting the work into this, Joe. :)  I thought I was being all clever thinking that I might have found a unique way of FINALLY connecting my Synology to my Windows environment so that I no longer have to store/remember/type passwords.  I am not too surprised that you ran into problems, despite MSFT being all braggy and hyped with how interoperable and compatible they are (and not exactly helpful about it either when you run into problems as outlined above).

    If I understand correct, you are able to see users and groups, but are not able to assign permissions.  Are you able to put these AAD users into Synology groups?  That might be enough for me as all I am looking to do is save myself the password management hassle.

    So the thinking is that I would:

    1. Create a local Synology Group called "Backup Administrators"
    2. Give this group write permissions to a shared folder
    3. Put my AAD user in that group

    And then whalah, it should work, right?

    Wednesday, April 26, 2017 9:44 AM
  • Also, I wanted to verify my understanding of Streck33's script that it simply synchronizes identities, but not authentication.  So I would still need to manage passwords in that case.  (Seriously guys, why is this so f*cking complicated!!! ALL THE FRUSTRATE!!!)
    Wednesday, April 26, 2017 9:46 AM
  • Though I was able to see the users and groups from AAD via the synology web console, I was not able to add them to local synology groups, grant user access directly, or do any type of authentication.

    Synology has recently released a Beta Active Directory Server package which I have not played with much, but with any luck features will be added to enable some form of AAD sync.  Very basic at this point...I don't really see much of a difference between it and the directory server package, with the exception of being able to join windows workstations to the synology active directory instance.

    Wednesday, April 26, 2017 6:46 PM
  • Sorry for the delay here, I've been neck-deep in learning Hyper-V tech.  In fact I've got my whole setup now running on a Windows Server 2016 with a bunch of VMs cleanly separating out my daily concerns.  It's pretty rad. :D

    My plans this week are to do exactly what you suggest, Joe: set up a DC in one of my newfound powers of Hyper-V, and then install the Synology AD server on my DS413j and see how it goes.  

    Additionally, I do have an Azure account and my Microsoft Account is added to the domain there in Azure Active Directory.  The super magic would be to get my domain connected to Azure AD, sync my Microsoft Account to my "on-premise" (sounds fancy when it's actually just a VM instance haha) domain and then use THAT to access my Synology.

    I will update here with any success (but mostly expecting not that).

    Tuesday, May 2, 2017 3:46 AM
  • yeah, that's why I enabled directory services in Azure AD, and attempted an LDAPS connection from the synology NAS...this is really a Synology shortcoming, not so much Azure AD.  I can connect to Azure AD directory services with other LDAP clients...but not synology's ldap client.

    I've submitted a feature request with Synology for this functionality. 

    Wednesday, May 3, 2017 3:35 PM
  • this is really a Synology shortcoming

    Yeah?  It would seem to me that if we could sync AAD back to AD, that this would be a non-issue, correct?  Or is there something I am missing?

    Also, is this feature request publicly accessible w/ an upvoter? :P

    Wednesday, May 3, 2017 4:31 PM
  • AD \ Azure sync can be setup two way, but there needs to be an initial sync from your on prem AD environment first...and that's limited to Microsoft AD DS. AADsync (DirSync) runs on windows only I believe, and certainly doesn't on synology products.

    I'm looking for that feature request, but am having a hard time finding it.

    Here's the synology feature request site:  https://forum.synology.com/enu/viewforum.php?f=3

    Wednesday, May 3, 2017 5:32 PM
  • AD \ Azure sync can be setup two way

    So wait... a previous version of Azure AD Connect offers exactly what we're looking to accomplish?  That is like the cherry on the cake of fail here.  Nice work all around, team!

    FWIW, I am running a hyper-v/virtualized environment, running on a Hyper-V 2016 server, so I can do all the Windows here. :)  Thanks for your insight/assistance/info, Joe!

    Wednesday, May 3, 2017 5:54 PM
  • Not sure if this is it, but it's something.  Please add your voice to the chorus of fail here:

    https://forum.synology.com/enu/viewtopic.php?f=3&t=126134

    Wednesday, May 3, 2017 5:57 PM
  • No no, two way sync still works with Azure AD Connect and will likely always work.  there have been so many iterations of that tool over the years that I end up just calling it DirSync half the time.

    On a somewhat related topic, I see that the synology router VPN server now has a beta site-to-site VPN config option now.  This could allow a site-to-site between the router and Azure, allowing the synology NAS to join the azure domain....not tested so not 100% sure it would work...but sounds promising.

    site-to-site is not available on the NAS VPN though....unfortunately.

    Wednesday, May 3, 2017 7:15 PM
  • No no, two way sync still works with Azure AD Connect and will likely always work

    Well now you got me confused Joe, as the thread I provided earlier is explicitly stating that two-way sync is not possible.  What am I missing/misunderstanding here?

    site-to-site is not available on the NAS VPN though....unfortunately

    Wow I had to look this up to grasp what you were saying, but I had no idea Synology made routers. :o  This is good to hear, though.  Please feel free to update this thread with any news you find.  I for one am glad I am not the only one enduring the pain here.

    Wednesday, May 3, 2017 8:45 PM
  • Azure AD Connect (the new DirSync) does NOT offer two way sync for users. It takes users from on-prem and creates users in Azure AD. The only things it is doing syncing from Azure AD to on-prem AD are Azure AD Premium features, such as password reset writeback and Office 365 groups writeback.

    User writeback is something that has been asked for a while, but it is currently not there. It existed for a very short time in preview, but it was removed.
    https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-feature-preview#user-writeback

    Thursday, May 4, 2017 6:13 AM
  • Thanks for the clarification Andreas, and apologies for misleading you Mike.  I didn't clue in to you meaning a full 2 way sync of all AD objects.

    Thursday, May 4, 2017 11:10 AM
  • No worries, Joe.  Lots of moving pieces here.

    And +1 on the useful information/confirmation, Andreas.

    Thursday, May 4, 2017 2:30 PM