From fc8c369a2437f523dcb7514c48cfe3542d18773a Mon Sep 17 00:00:00 2001
From: ahaenggli <adriano@haenggli.net>
Date: Fri, 21 Jul 2023 12:50:43 +0200
Subject: [PATCH] v2.0.1

---
 configuration/bypass-mfa/index.html      | 10 +++++-----
 configuration/settings/index.html        |  4 ++--
 installation/run-ldap-wrapper/index.html |  4 ++--
 search/en.data.min.json                  |  2 +-
 sitemap.xml                              |  6 +++---
 5 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/configuration/bypass-mfa/index.html b/configuration/bypass-mfa/index.html
index 31c1371..c820fee 100644
--- a/configuration/bypass-mfa/index.html
+++ b/configuration/bypass-mfa/index.html
@@ -49,7 +49,7 @@
 <meta property="article:section" content="Configuration" />
     <meta
       property="article:modified_time"
-      content="2023-03-04T20:54:20+01:00"
+      content="2023-07-21T12:16:16+02:00"
     />
 
 
@@ -69,7 +69,7 @@
       "url" : "https://ahaenggli.github.io/AzureAD-LDAP-wrapper/configuration/bypass-mfa/",
       "headline": "Bypass MFA",
       "description": "Officially MFA is not supported by this LDAP-wrapper. The login for users with activated MFA simply fails, as mentioned here and here. There is no interactive window to enter another factor, and LDAP does not support this either. If you need to use this LDAP-wrapper despite of activated MFA, there are two options:\nDisable MFA for this application in AzureAD (preferred).\nThere are several ways to define MFA, but only some of them allows you to disable MFA.",
-      "wordCount" : "350",
+      "wordCount" : "359",
       "inLanguage": "en",
       "isFamilyFriendly": "true",
       "mainEntityOfPage": {
@@ -80,7 +80,7 @@
       "copyrightYear" : "0001",
       "dateCreated": "0001-01-01T00:00:00.00Z",
       "datePublished": "0001-01-01T00:00:00.00Z",
-      "dateModified": "2023-03-04T20:54:20.00Z",
+      "dateModified": "2023-07-21T12:16:16.00Z",
       "publisher":{
           "@type":"Organization",
           "name": "AzureAD-LDAP-wrapper",
@@ -1159,7 +1159,7 @@ <h1>Bypass MFA</h1>
 <a
   class="gdoc-markdown__link"
   href="https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-all-users-mfa"
->Conditional Access</a> can be used to require MFA for some or all the users. This is the most flexible way to activate MFA, but it is a premium feature. The settings allows to exclude certain apps. If a login fails due to this MFA method, the error code is AADSTS50079, too. As a simple workaround, the app used by the LDAP-wrapper can be excluded:
+>Conditional Access</a> can be used to require MFA for some or all the users. This is the most flexible way to activate MFA, but it is a premium feature. The settings allows to exclude certain apps. If a login fails due to this MFA method, the error codea are either AADSTS50158 (for external MFA like Duo) or also AADSTS50079. As a simple workaround, the app used by the LDAP-wrapper can be excluded:
 <ul>
 <li>Add a URL in the app (e.g. &ldquo;https://localhost&rdquo;)
 <img
@@ -1180,7 +1180,7 @@ <h1>Bypass MFA</h1>
 <li>
 <p>Let the LDAP-wrapper internally treat some MFA/2FA related error codes as a successful login.<br>
 There is an experimental feature to <em><strong>bypass</strong></em> MFA/2FA. It must be manually enabled by setting the the env var <code>GRAPH_IGNORE_MFA_ERRORS</code> to true.<br>
-Even if the env var is set to true, the login attempt appears as &ldquo;Failure&rdquo; in the AzureAD sign-in logs due to MFA/2FA. Only the LDAP wrapper internally treats some MFA/2FA-related error codes as successful logins. Specifically, these are the error codes AADSTS50076 and AADSTS50079, as mentioned above.</p>
+Even if the env var is set to true, the login attempt appears as &ldquo;Failure&rdquo; in the AzureAD sign-in logs due to MFA/2FA. Only the LDAP wrapper internally treats some MFA/2FA-related error codes as successful logins. Specifically, these are the error codes AADSTS50076, AADSTS50079 and AADSTS50158, as mentioned above.</p>
 </li>
 </ol>
 
diff --git a/configuration/settings/index.html b/configuration/settings/index.html
index 2ff2d82..7a6059b 100644
--- a/configuration/settings/index.html
+++ b/configuration/settings/index.html
@@ -47,7 +47,7 @@
 <meta property="article:section" content="Configuration" />
     <meta
       property="article:modified_time"
-      content="2023-03-26T13:44:37+02:00"
+      content="2023-07-17T10:26:34+02:00"
     />
 
 
@@ -77,7 +77,7 @@
       "copyrightYear" : "0001",
       "dateCreated": "0001-01-01T00:00:00.00Z",
       "datePublished": "0001-01-01T00:00:00.00Z",
-      "dateModified": "2023-03-26T13:44:37.00Z",
+      "dateModified": "2023-07-17T10:26:34.00Z",
       "publisher":{
           "@type":"Organization",
           "name": "AzureAD-LDAP-wrapper",
diff --git a/installation/run-ldap-wrapper/index.html b/installation/run-ldap-wrapper/index.html
index ddc56a7..263b618 100644
--- a/installation/run-ldap-wrapper/index.html
+++ b/installation/run-ldap-wrapper/index.html
@@ -45,7 +45,7 @@
 <meta property="article:section" content="Installation" />
     <meta
       property="article:modified_time"
-      content="2023-03-26T20:48:22+02:00"
+      content="2023-07-17T10:26:34+02:00"
     />
 
 
@@ -74,7 +74,7 @@
       "copyrightYear" : "0001",
       "dateCreated": "0001-01-01T00:00:00.00Z",
       "datePublished": "0001-01-01T00:00:00.00Z",
-      "dateModified": "2023-03-26T20:48:22.00Z",
+      "dateModified": "2023-07-17T10:26:34.00Z",
       "publisher":{
           "@type":"Organization",
           "name": "AzureAD-LDAP-wrapper",
diff --git a/search/en.data.min.json b/search/en.data.min.json
index afb058d..6931770 100644
--- a/search/en.data.min.json
+++ b/search/en.data.min.json
@@ -1 +1 @@
-[{"id":0,"href":"/AzureAD-LDAP-wrapper/installation/create-azuread-application/","title":"1.1 Create an AzureAD application","parent":"Installation","content":" Prerequisites Register an application with Azure AD and create a service principal Set permissions Get TenantId, AppId and AppSecret Use TenantId, AppId and AppSecret in your wrapper Prerequisites To register an application in your Azure AD tenant, you need:\nAn Azure AD user account. If you don\u0026rsquo;t already have one, you can create an account for free. Register an application with Azure AD and create a service principal Register a new application in your aad-portal. More descriptions can be found here.\nSign-in to the Azure portal. Select Azure Active Directory and navigateo to App registrations. Select New registration. Name the application, for example \u0026ldquo;ldap-wrapper\u0026rdquo;. Select a supported account type, which determines who can use the application.\nImportant: Personal Microsoft accounts are not supported. Under Redirect URI, select nothing and keep it empty. Select Register.\nSet permissions Set the following Graph-API Application permissions:\nFor type Application allow User.Read.All and Group.Read.All.\nFor type Delegated allow User.Read.\nClick \u0026ldquo;Grant admin consent\u0026rdquo;. The status should be \u0026ldquo;Granted for\u0026rdquo;.\nIf you see en entry with \u0026ldquo;Not granted for\u0026rdquo;, click again: Set Treat application as a public client to Yes\n(former \u0026ldquo;Allow public client flows\u0026rdquo;)\nGet TenantId, AppId and AppSecret Copy and save those values for the later use as environment variables in the Docker container:\nAZURE_TENANTID: Directory (tenant) ID from the page \u0026ldquo;overview\u0026rdquo;. AZURE_APP_ID: Application (client) ID from the page \u0026ldquo;overview\u0026rdquo;. AZURE_APP_SECRET: Value of a new client secret from the page \u0026ldquo;Certificates \u0026amp; secrets\u0026rdquo;.\nUse TenantId, AppId and AppSecret in your wrapper Use a docker container or any other method to run the LDAP-wrapper and start it with the previously saved environment variables.\n","description":"Prerequisites Register an application with Azure AD and create a service principal Set permissions Get TenantId, AppId and AppSecret Use TenantId, AppId and AppSecret in your wrapper Prerequisites To register an application in your Azure AD tenant, you need:\nAn Azure AD user account. If you don\u0026rsquo;t already have one, you can create an account for free. Register an application with Azure AD and create a service principal Register a new application in your aad-portal."},{"id":1,"href":"/AzureAD-LDAP-wrapper/security/","title":"3. Security","parent":"AzureAD-LDAP-wrapper","content":"There are a few things you should definitely keep in mind:\nRestrict access through a firewall. Do NOT allow everyone in your network access to the LDAP-wrapper.\nOnly your (local hosted) applications or your NAS should have access.\nAn LDAP search on the NAS must be possible without any authentication in order to be able to select the domain/baseDN at all. Therefore, some queries can be run as anonymous by default. Data like domain/baseDN or schema can be fetched without authentication. Since this LDAP-wrapper is originally only meant to use the same credentials as in Azure on a NAS, this is the default behaviour. You can change this via the env var LDAP_ANONYMOUSBIND if required.\nIn order to use samba, the user credentials hashes are cached in the ldap attribute sambaNTPassword.\nIf you don\u0026rsquo;t need samba, the cache can be disabled by setting LDAP_SAMBANTPWD_MAXCACHETIME to 0.\nHowever, if you do not disable the cache, there is a special treatment for these hashed credentials. This handling can not be disabled.\nSuperusers, as defined in LDAP_BINDUSER, can get all cached credentials. Each user has access to his own cached credential hash. In all other cases the attribute is returned with XXXX instead of the hash value. In cases such as network/internet issues or Azure not being reachable, the cached hash is used for authentication.\nThis can be a problem if the user has been deactivated in the meantime or the password would be invalid. The use of the cached password during authentication can be disabled by setting the LDAP_ALLOWCACHEDLOGINONFAILURE parameter to false.\nUsing the experimental feature to bypass MFA/2FA\nOfficially MFA is not supported by this LDAP-wrapper. The login for users with activated MFA simply fails, as mentioned here and here. There is an experimental feature to bypass MFA/2FA. It must be manually enabled by setting the the env var GRAPH_IGNORE_MFA_ERRORS to true. Even if the env var is set to true, the login attempt appears as \u0026ldquo;Failure\u0026rdquo; in the AzureAD sign-in logs due to MFA/2FA. It is only the LDAP-wrapper that internally treats some MFA/2FA related error codes as a successful login.\nMapped docker volume\nBe aware that other users with access on your file system may also be able to read the JSON files in the mounted docker path (/app/.cache) and thus get access to the cached sambaNTPassword attribute.\n","description":"There are a few things you should definitely keep in mind:\nRestrict access through a firewall. Do NOT allow everyone in your network access to the LDAP-wrapper.\nOnly your (local hosted) applications or your NAS should have access.\nAn LDAP search on the NAS must be possible without any authentication in order to be able to select the domain/baseDN at all. Therefore, some queries can be run as anonymous by default."},{"id":2,"href":"/AzureAD-LDAP-wrapper/troubleshooting/","title":"4. Troubleshooting","parent":"AzureAD-LDAP-wrapper","content":"The first step is always to look at the Docker log. Many errors are handled there. For further steps, e.g. Samba debugging, read this guide. If you get stuck, feel free to open an issue - but please add the log files, maybe others will be able to read more from them than you.\nDoes it support MFA (multi-factor authentication)? How do I give some synced users the DSM-Administrator permission on a Synology-NAS? Can I use LDAPS (LDAP over SSL) instead of LDAP (with no encryption)? Can I use LDAP over TLS (STARTTLS) instead of LDAP (with no encryption)? Join NAS to Azure AD Domain Why are personal microsoft accounts not supported? Samba is not working, what can I do? Are deleted users or groups in Azure also removed from the LDAP entries? Does it support MFA (multi-factor authentication)? Yes and no\u0026hellip; There is an experimental feature to bypass MFA/2FA. It can be enabled by setting the the env var GRAPH_IGNORE_MFA_ERRORS to true. Officially no, because the login simply fails, as mentioned here and here. Even if the env var is set to true, the login attempt appears as \u0026ldquo;Failure\u0026rdquo; in the AzureAD sign-in logs due to MFA/2FA. It is only the LDAP-wrapper that internally treats some MFA/2FA related error codes as a successful login.\nHow do I give some synced users the DSM-Administrator permission on a Synology-NAS? Before DSM 7: Just create a group called \u0026ldquo;Administrators\u0026rdquo; and put the users in it. With DSM 7: You can delegate specific permissions to each synced group.\nCan I use LDAPS (LDAP over SSL) instead of LDAP (with no encryption)? Sure. Mount your certificate file and private key file to the docker container and then set the environment variables LDAPS_CERTIFICATE and LDAPS_KEY. You may also set LDAP_PORT to 636.\nCan I use LDAP over TLS (STARTTLS) instead of LDAP (with no encryption)? Nope, that\u0026rsquo;s not (yet) possible.\nJoin NAS to Azure AD Domain If you don\u0026rsquo;t need support for older software, the officially Synology solution to join your NAS to a Azure AD Domain will work fine. My wrapper creates an entire ldap server. So you can use it with several 3rd party (legacy) software in the same network.\nWhy are personal microsoft accounts not supported? This wrapper uses the ROPC flow for authentication. Microsoft doesn\u0026rsquo;t support that for personal accounts as mentioned here:\nPersonal accounts that are invited to an Azure AD tenant can\u0026rsquo;t use ROPC.\nSamba is not working, what can I do? Check the following points first:\nIs samba enabled and your user has permissions to use it? Are you using DSM \u0026gt;= 7? Set the ENV variable to true. Look into the docker Log. Are there any errors you should resolve? Did you really connect your device/NAS with a non-existing user from the env var LDAP_BINDUSER? Otherwise the required password hash for Samba is not available and access will fail. Before accessing files via network/Samba, each user must log in to dsm-web-gui or another tool that is directly connected to the ldap server. This also applies after a password change, since the password hash for Samba is only set after a successful login. Is your (Windows) device connected to Azure? Make sure you log in with username/password over the network, not with your pin code. Can you successfully access the shares with a local user? Make sure Synology Directory Service and Synology LDAP server are not installed. Maybe there is someting in the samba log. Get it to open an issue: Enable \u0026ldquo;collect debug logs\u0026rdquo; Try the access a shared folder multiple times ssh into your nas Run cat /var/log/samba/log.smbd and copy the latest error/fail/\u0026hellip; messages - please replace sensitive informations like domains, ip addresses or names. Don\u0026rsquo;t forget to disable \u0026ldquo;collect debug logs\u0026rdquo; before opening an issue Are deleted users or groups in Azure also removed from the LDAP entries? Yes, but with a delay. After a user has been deleted in Azure, it remains available there for about 30 days to undo the deletion. The API stops listing the user a earlier, a few hours after the deletion. In the meantime, the wrapper fetches the user as usual. After this time, the wrapper no longer receives the user. The deletion in the wrapper takes place 7 days later. Why not removing the user immediately? A user could also no longer be in the wrapper due to a misconfigured filter (env var). But just because of such an error, users (and their cached password hashes) should not be deleted immediately. Why not keeping it also 30 days? The user can no longer log in anyway. If the time span is too long (or short), it can be adjusted via the environment variable LDAP_DAYSTOKEEPDELETEDUSERS.\n","description":"The first step is always to look at the Docker log. Many errors are handled there. For further steps, e.g. Samba debugging, read this guide. If you get stuck, feel free to open an issue - but please add the log files, maybe others will be able to read more from them than you.\nDoes it support MFA (multi-factor authentication)? How do I give some synced users the DSM-Administrator permission on a Synology-NAS?"},{"id":3,"href":"/AzureAD-LDAP-wrapper/","title":"AzureAD-LDAP-wrapper","parent":"","content":"AzureAD-LDAP-wrapper is a Node.js LDAP server built on top of (ldapjs) that allows users and groups from Azure Active Directory to be accessed through the LDAP protocol. User authentication is performed using Microsoft Graph API on every login attempt. This enables other applications to connect to the LDAP server and utilize AzureAD login credentials, making it a possible solution for older applications that lack AzureAD support or for scenarios where managing a local AD controller is undesirable.\nI run the project on my Synology NAS in a Docker container. By connecting the NAS and some intranet web applications to the LDAP server, my users can log in to these services using their AzureAD credentials. Although it is possible to achieve this by joining the NAS to AADDS, I preferred not to maintain such a big setup, which includes a virtual machine, VPN, and AADDS, just to allow my three users to use their credentials almost everywhere. How the server works sequenceDiagram\rautonumber\rparticipant LDAP client\rparticipant AzureAD-LDAP-wrapper\rparticipant AAD (Graph API)\rNote over AzureAD-LDAP-wrapper: start LDAP server\rAzureAD-LDAP-wrapper-\u0026gt;\u0026gt;AAD (Graph API): Fetch users and groups\rNote over AzureAD-LDAP-wrapper: cache users and groups locally\rLDAP client-\u0026gt;\u0026gt;\u0026#43;AzureAD-LDAP-wrapper: Attempt to bind with user credentials\rAzureAD-LDAP-wrapper-\u0026gt;\u0026gt;\u0026#43;AAD (Graph API): Check user credentials AAD (Graph API)--\u0026gt;\u0026gt;-AzureAD-LDAP-wrapper: Valid credentials\rNote over AzureAD-LDAP-wrapper: save password hash locally in the cache\rAzureAD-LDAP-wrapper-\u0026gt;\u0026gt;-LDAP client: Successful bind/authenticate\rloop every 30 minutes\rAzureAD-LDAP-wrapper-\u0026gt;\u0026gt;AAD (Graph API): Fetch users and groups again\rNote over AzureAD-LDAP-wrapper: merge and cache users and groups locally\rend The diagram shows the flow of communication between an LDAP client, the AzureAD-LDAP-wrapper, and the Azure Active Directory (AAD) via Graph API.\nFirst, the AzureAD-LDAP-wrapper starts an LDAP server and fetches users and groups from the AAD Graph API. These are cached and merged locally.\nWhen an LDAP client attempts to bind with user credentials, the AzureAD-LDAP-wrapper checks these credentials by communicating with the AAD Graph API. If the credentials are valid, the AAD Graph API sends a success response to the AzureAD-LDAP-wrapper, which then sends a successful bind message to the user\u0026rsquo;s LDAP client. Additionally, the AzureAD-LDAP-wrapper saves the user\u0026rsquo;s password hash in the sambaNTPassword attribute and sets the sambaPwdLastSet attribute to \u0026ldquo;now\u0026rdquo;. This allows the user to access samba shares, such as those on a NAS, from Windows PCs.\nThe AzureAD-LDAP-wrapper periodically fetches user and group information from the AAD Graph API every 30 minutes, merging and caching the results locally. This process preserves attributes like uid, gid, sambaNTPassword, and sambaPwdLastSet.\n","description":"AzureAD-LDAP-wrapper is a Node.js LDAP server built on top of (ldapjs) that allows users and groups from Azure Active Directory to be accessed through the LDAP protocol. User authentication is performed using Microsoft Graph API on every login attempt. This enables other applications to connect to the LDAP server and utilize AzureAD login credentials, making it a possible solution for older applications that lack AzureAD support or for scenarios where managing a local AD controller is undesirable."},{"id":4,"href":"/AzureAD-LDAP-wrapper/configuration/bypass-mfa/","title":"Bypass MFA","parent":"Configuration","content":"Officially MFA is not supported by this LDAP-wrapper. The login for users with activated MFA simply fails, as mentioned here and here. There is no interactive window to enter another factor, and LDAP does not support this either. If you need to use this LDAP-wrapper despite of activated MFA, there are two options:\nDisable MFA for this application in AzureAD (preferred).\nThere are several ways to define MFA, but only some of them allows you to disable MFA.\nPer-user MFA\nMFA could be enabled individually for each user. A possible workaround seems to be the trusted IPs feature, which allows to disable MFA for some IPs, but this feature requires Azure AD Premium.\nIf a login fails due to this MFA method, the error code is AADSTS50079. Security defaults\nSecurity defaults seems to be the only ways for customers using the free Azure AD plan to enable multi-factor authentication in their whole environment. It looks like there are no workarounds to disable MFA for certain IPs or applications.\nIf a login fails due to this MFA method, the error code is AADSTS50076. Conditional Access\nConditional Access can be used to require MFA for some or all the users. This is the most flexible way to activate MFA, but it is a premium feature. The settings allows to exclude certain apps. If a login fails due to this MFA method, the error code is AADSTS50079, too. As a simple workaround, the app used by the LDAP-wrapper can be excluded: Add a URL in the app (e.g. \u0026ldquo;https://localhost\u0026rdquo;) The App can now be selected in the exclude list Let the LDAP-wrapper internally treat some MFA/2FA related error codes as a successful login.\nThere is an experimental feature to bypass MFA/2FA. It must be manually enabled by setting the the env var GRAPH_IGNORE_MFA_ERRORS to true.\nEven if the env var is set to true, the login attempt appears as \u0026ldquo;Failure\u0026rdquo; in the AzureAD sign-in logs due to MFA/2FA. Only the LDAP wrapper internally treats some MFA/2FA-related error codes as successful logins. Specifically, these are the error codes AADSTS50076 and AADSTS50079, as mentioned above.\n","description":"Officially MFA is not supported by this LDAP-wrapper. The login for users with activated MFA simply fails, as mentioned here and here. There is no interactive window to enter another factor, and LDAP does not support this either. If you need to use this LDAP-wrapper despite of activated MFA, there are two options:\nDisable MFA for this application in AzureAD (preferred).\nThere are several ways to define MFA, but only some of them allows you to disable MFA."},{"id":5,"href":"/AzureAD-LDAP-wrapper/configuration/","title":"Configuration","parent":"AzureAD-LDAP-wrapper","content":" The LDAP-wrapper works with very little configuration required. That being said, it is highly configurable for the needs of your specific application. ","description":" The LDAP-wrapper works with very little configuration required. That being said, it is highly configurable for the needs of your specific application. "},{"id":6,"href":"/AzureAD-LDAP-wrapper/configuration/customize-attributes/","title":"Customize attributes","parent":"Configuration","content":"It is possible to customize all the ldap attributes. That\u0026rsquo;s what I do in the DSM 7 workaround. Look at this file for an example. Customize it as you need and map the file in your docker setup as /app/customizer/ldap_customizer.js. This file has even priority over the DSM 7 workaround. Basically everything can be changed with it. Filter users or groups, overwrite a users default group, add/remove/edit entries or attributes, and much more.\n","description":"It is possible to customize all the ldap attributes. That\u0026rsquo;s what I do in the DSM 7 workaround. Look at this file for an example. Customize it as you need and map the file in your docker setup as /app/customizer/ldap_customizer.js. This file has even priority over the DSM 7 workaround. Basically everything can be changed with it. Filter users or groups, overwrite a users default group, add/remove/edit entries or attributes, and much more."},{"id":7,"href":"/AzureAD-LDAP-wrapper/installation/","title":"Installation","parent":"AzureAD-LDAP-wrapper","content":" Slow down. Take your time. Make sure you have enough coffee on hand.\nThere are a few steps you need to take to make it work. ","description":" Slow down. Take your time. Make sure you have enough coffee on hand.\nThere are a few steps you need to take to make it work. "},{"id":8,"href":"/AzureAD-LDAP-wrapper/installation/run-ldap-wrapper/","title":"Run the LDAP-wrapper","parent":"Installation","content":"The preferred way to use the LDAP wrapper is with Docker. Alternatively, the source can be downloaded and started manually with npm/node. As domain (and basedn, if manually specified) it is recommended to use the same as used in AzureAD tenant (e.g. @domain.tld). This way, the spelling of the users (e.g. username@domain.tld) will match at the end. Otherwise, your users will have to use username@example.com instead of the estimated username@domain.tld, for example.\nThe API results and a local copy of the LDAP entries are stored as JSON files inside the container at this path: /app/.cache\nMap this folder to provide persistent storage for your users/groups (and their samba password hashes).\nBe aware that other users in the file system may also be able to read the JSON files and thus get access to the cached sambaNTPassword attribute. Synology DSM Docker Install container on a Synology NAS Install Docker from the Synology Package Center. In Docker, go to \u0026ldquo;Registry\u0026rdquo; to download the latest container image. In Docker, go to \u0026ldquo;Image\u0026rdquo; to launch a new container. Use \u0026ldquo;bridge\u0026rdquo; as your network. Use \u0026ldquo;bridge\u0026rdquo; as your network.\nGive your container a name and enable auto-restart. Configure the environment variables in \u0026ldquo;Advanced Settings\u0026rdquo;. Be sure to double check your Azure values and define at least one binduser. The binduser (superuser like root) does not need to exist in your AzureAD. Replace example.com with your domain. Here is an example of a minimum required configuration:\nTZ: \u0026#34;Europe/Zurich\u0026#34; # optional AZURE_TENANTID: \u0026#34;0def2345-ff01-56789-1234-ab9d6dda1e1e\u0026#34; AZURE_APP_ID: \u0026#34;abc12345-ab01-0000-1111-a1e1eab9d6dd\u0026#34; AZURE_APP_SECRET: \u0026#34;iamasecret~yep-reallyreallysecret\u0026#34; LDAP_DOMAIN: \u0026#34;example.com\u0026#34; LDAP_BINDUSER: \u0026#34;ldapsearch|*secretldapsearch123*||root|*secretroot*\u0026#34; LDAP_DEBUG: \u0026#34;false\u0026#34; # set this to true for more logs GRAPH_IGNORE_MFA_ERRORS: \u0026#34;false\u0026#34; # set this to true to bypass MFA DSM7: \u0026#34;true\u0026#34; # set this to false if you are running DSM 6 or lower A full list of all environment variables can be found here.\nSet local Port 389 to the Container Port 13389. If you receive the error Local port 389 conflicts with other ports used by other services, make sure that Synology Directory Service and Synology LDAP Server are not installed - they also use this port. Add a local folder, such as docker/ldap, to the mount path /app/.cache in the volume settings. If you skip this step, your data will not be stored permanently. Click \u0026ldquo;Done\u0026rdquo; to start the container. Docker docker run -d ` -p 389:13389 ` --volume /volume1/docker/ldapwrapper:/app/.cache ` -e AZURE_TENANTID=\u0026#34;0def2345-ff01-56789-1234-ab9d6dda1e1e\u0026#34; ` -e AZURE_APP_ID=\u0026#34;abc12345-ab01-0000-1111-a1e1eab9d6dd\u0026#34; ` -e AZURE_APP_SECRET=\u0026#34;iamasecret~yep-reallyreallysecret\u0026#34; ` -e GRAPH_IGNORE_MFA_ERRORS=\u0026#34;false\u0026#34; ` -e LDAP_DOMAIN=\u0026#34;example.com\u0026#34; ` -e LDAP_BINDUSER=\u0026#34;root|mystrongpw||ldapsearch|ldapsearchpw123\u0026#34; ` ahaen/azuread-ldap-wrapper:latest Docker compose version: \u0026#39;3.2\u0026#39; services: azuread-ldap-wrapper: image: ahaen/azuread-ldap-wrapper:latest container_name: azuread-ldap-wrapper environment: TZ: \u0026#34;Europe/Zurich\u0026#34; AZURE_TENANTID: \u0026#34;0def2345-ff01-56789-1234-ab9d6dda1e1e\u0026#34; AZURE_APP_ID: \u0026#34;abc12345-ab01-0000-1111-a1e1eab9d6dd\u0026#34; AZURE_APP_SECRET: \u0026#34;iamasecret~yep-reallyreallysecret\u0026#34; LDAP_DOMAIN: \u0026#34;example.com\u0026#34; LDAP_BINDUSER: \u0026#34;ldapsearch|ldapsearch123\u0026#34; # LDAP_DEBUG: \u0026#34;true\u0026#34; # GRAPH_IGNORE_MFA_ERRORS: \u0026#34;true\u0026#34; # DSM7: \u0026#34;true\u0026#34; ports: - 389:13389 volumes: - /data/azuread-ldap/app:/app/.cache restart: unless-stopped Portainer version: \u0026#39;3.8\u0026#39; services: azuread-ldap-wrapper: image: \u0026#34;ahaen/azuread-ldap-wrapper:latest\u0026#34; container_name: azuread-ldap-wrapper ports: - 389:13389 network_mode: \u0026#34;bridge\u0026#34; volumes: - /volume1/docker/ldap:/app/.cache environment: TZ: \u0026#34;Europe/Zurich\u0026#34; AZURE_TENANTID: \u0026#34;0def2345-ff01-56789-1234-ab9d6dda1e1e\u0026#34; AZURE_APP_ID: \u0026#34;abc12345-ab01-0000-1111-a1e1eab9d6dd\u0026#34; AZURE_APP_SECRET: \u0026#34;iamasecret~yep-reallyreallysecret\u0026#34; LDAP_DOMAIN: \u0026#34;example.com\u0026#34; LDAP_BINDUSER: \u0026#34;root|root123||ldapsearch|ldapsearch123\u0026#34; # LDAP_DEBUG: \u0026#34;true\u0026#34; # GRAPH_IGNORE_MFA_ERRORS: \u0026#34;true\u0026#34; # DSM7: \u0026#34;true\u0026#34; npm/node This is a minimal example for a running configuration.\nYou can either set environment variables or create an .env file in the root directory.\n## .env file or environment variables ## # Values of your AzureAD application AZURE_APP_ID=\u0026#34;abc12345-ab01-0000-1111-a1e1eab9d6dd\u0026#34; AZURE_TENANTID=\u0026#34;0def2345-ff01-56789-1234-ab9d6dda1e1e\u0026#34; AZURE_APP_SECRET=\u0026#34;iamasecret~yep-reallyreallysecret\u0026#34; # Ignore MFA related errors, so user can login despite of activated MFA # GRAPH_IGNORE_MFA_ERRORS=\u0026#34;false\u0026#34; # Settings for your LDAP server LDAP_DOMAIN=\u0026#34;example.com\u0026#34; LDAP_BINDUSER=\u0026#34;root|mystrongpw||ldapsearch|ldapsearchpw123\u0026#34; # clone repo and open folder git clone https://github.com/ahaenggli/AzureAD-LDAP-wrapper.git cd AzureAD-LDAP-wrapper # install 3rd party libraries npm install # use a .env file or set your env vars # run with npm npm start # or start it with node (\u0026#34;--openssl-legacy-provider\u0026#34; is needed) # node --openssl-legacy-provider index.js Caution Check your Docker log for errors before attempting to use the ldap server. ","description":"The preferred way to use the LDAP wrapper is with Docker. Alternatively, the source can be downloaded and started manually with npm/node. As domain (and basedn, if manually specified) it is recommended to use the same as used in AzureAD tenant (e.g. @domain.tld). This way, the spelling of the users (e.g. username@domain.tld) will match at the end. Otherwise, your users will have to use username@example.com instead of the estimated username@domain.tld, for example."},{"id":9,"href":"/AzureAD-LDAP-wrapper/configuration/settings/","title":"Settings","parent":"Configuration","content":"The following is a list of all possible settings. The LDAP wrapper is intended to be used with Docker. Therefore, the settings must be made using environment variables.\nAzure Settings AZURE_APP_ID AZURE_TENANTID AZURE_APP_SECRET AZURE_ENDPOINT (optional) Graph API Settings GRAPH_ENDPOINT (optional) GRAPH_API_VERSION (optional) GRAPH_FILTER_USERS (optional) GRAPH_FILTER_GROUPS (optional) GRAPH_IGNORE_MFA_ERRORS (default: false) LDAP Settings LDAP_DOMAIN LDAP_BASEDN (optional) LDAP_SAMBADOMAINNAME (optional) LDAP_BINDUSER LDAP_ANONYMOUSBIND (default: domain) LDAP_DEBUG (default: false) LDAP_PORT (default: 13389) LDAP_SECURE_ATTRIBUTES (optional) LDAP_SENSITIVE_ATTRIBUTES (optional) LDAP_ALLOWCACHEDLOGINONFAILURE (default: true) LDAP_SAMBANTPWD_MAXCACHETIME (optional, default: infinity) LDAP_DAYSTOKEEPDELETEDUSERS (optional, default: 7) LDAP_SYNC_TIME (default: 30 minutes) LDAPS LDAPS_CERTIFICATE LDAPS_KEY Samba SAMBA_BASESID (optional) LDAP_SAMBA_USEAZURESID (default: true) misc DSM7 HTTPS_PROXY or HTTP_PROXY (optional) Azure Settings AZURE_APP_ID Your Application ID from azure (see #4)\nAZURE_TENANTID Your Tenant ID from azure (see #3)\nAZURE_APP_SECRET A Client secret-value from azure\nAZURE_ENDPOINT (optional) By default, the Azure AD global service endpoint (https://login.microsoftonline.com) is used. If you prefer to use a different endpoint, you can specify it here.\nGraph API Settings GRAPH_ENDPOINT (optional) By default, the Microsoft Graph global service endpoint (https://graph.microsoft.com) is used. If you prefer to use a different endpoint, you can specify it here.\nGRAPH_API_VERSION (optional) By default, the v1.0 API version is used for the Microsoft Graph endpoint. To use the beta API version instead, specify it here.\nGRAPH_FILTER_USERS (optional) This allows you to filter the users in the graph api using the $filter query parameter.\nThe default filter is set to userType eq 'Member'. That\u0026rsquo;s why external users (guests) will not be synced automatically by default in a Docker container.\nGRAPH_FILTER_GROUPS (optional) This allows you to filter the groups in the graph api using the $filter query parameter. The default filter is set in the Docker container to securityEnabled eq true, so only security groups are synchronized and not every single Teams group. More properties to filter are documented here.\nGRAPH_IGNORE_MFA_ERRORS (default: false) When set to true, some MFA/2FA-related error codes are treated as successful logins. So, it allows logins despite required MFA/2FA. MFA/2FA is thus bypassed.\nWarning: This feature is only experimental and may not work in all cases. Please open an issue if you encounter any problems.\nLDAP Settings LDAP_DOMAIN Your domain, for example domain.tld\nLDAP_BASEDN (optional) The LDAP_BASEDN parameter allows you to specify the base DN (Distinguished Name) for your LDAP server. If this parameter is not provided, the base DN is automatically generated based on the LDAP_DOMAIN value.\nFor example, if your LDAP_DOMAIN is domain.tld, the generated base DN would be dc=domain,dc=tld. Similarly, if your LDAP_DOMAIN is intra.domain.tld, the generated base DN would be dc=intra,dc=domain,dc=tld.\nBy specifying the LDAP_BASEDN, you have the flexibility to customize the base DN according to your LDAP server configuration and organizational structure.\nLDAP_SAMBADOMAINNAME (optional) Default is the first part of your baseDN, for dc=example,dc=net it would be EXAMPLE. For any other value, just set it manually with this env var.\nLDAP_BINDUSER Every AzureAD-user can bind (and auth) in this LDAP-Server. This parameter allows you to add additional - NOT in AzureAD existing - users. Format: \u0026ldquo;username|password\u0026rdquo;. This can be useful to \u0026ldquo;join\u0026rdquo; a device (e.g. NAS). Multiple users can be split by \u0026ldquo;||\u0026rdquo;. (e.g. ldapsearch1|mysecret||searchy2|othersecret). Those users are superusers (e.g. root, admin, \u0026hellip;) and have full read and modify permissions and can also see the sambaNTPassword-hash.\nLDAP_ANONYMOUSBIND (default: domain) Depending on the value, anonymous binding is handelt differently\nnone: no ldap query allowed without binding all: all ldap query are allowed without binding domain: only the domain entry is visible without binding LDAP_DEBUG (default: false) If set to true there are more detailed logs in the console output.\nLDAP_PORT (default: 13389) Sets the port for the listener. The wrapper listens on port 13389 by default. However, if you are running a Docker container directly on the host network, you may want to change the port to 389.\nLDAP_SECURE_ATTRIBUTES (optional) Allows to define secure attributes. Onlye superusers can see them all. Multiple attributes can be split by \u0026ldquo;|\u0026rdquo;. (e.g. customSecurityAttributes_*|PlannedDischargeDate).\nLDAP_SENSITIVE_ATTRIBUTES (optional) Allows to define sensitive attributes. Each user can see his own values, but not those of another user. Additionally, superusers can see them all, too. Multiple attributes can be split by \u0026ldquo;|\u0026rdquo;. (e.g. middlename|PrivatePhoneNumber).\nLDAP_ALLOWCACHEDLOGINONFAILURE (default: true) allows login from cached sambaNTPassword. If set to true, the login has failed and the error does NOT say \u0026ldquo;wrong credentials\u0026rdquo;, the password is checked against the cached sambaNTPassword. If it matches, the authentification is successfull.\nLDAP_SAMBANTPWD_MAXCACHETIME (optional, default: infinity) Maximum time in minutes that defines how long a cached sambaNTPassword hash can be used (for login and samba access). After that time, a user has to login \u0026rsquo;normal\u0026rsquo; via the bind method (e.g. dsm-web-gui) to reset the cached value. As default there is no time limit (-1=infinity). If this time limit is set to 0, no samba access is possible and therefore no password hash is cached.\nLDAP_DAYSTOKEEPDELETEDUSERS (optional, default: 7) Defines the number of days after deletion in Azure after which an entry is also removed in the wrapper. By default, te deletion in the wrapper takes place about 7 days later. The reason for the delay is simple: A user could also no longer be in the wrapper due to a misconfigured filter (env var). But just because of such an error, users (and their cached password hashes) should not be deleted immediately. However, you can set the value to 0 to delete a user/group immediately. Use a negative value like -1 to keep everything in the wrapper and not delete anything.\nLDAP_SYNC_TIME (default: 30 minutes) The interval in minutes for fetching users/groups from azure. The default is 30 minutes.\nLDAPS LDAPS_CERTIFICATE Path to your certificate.pem file. You also have to set LDAPS_KEY to run LDAP over SSL. You may also need to set LDAP_PORT to 636.\nLDAPS_KEY Path to private key file. You also have to set LDAPS_CERTIFICATE to run LDAP over SSL. You may also need to set LDAP_PORT to 636.\nSamba SAMBA_BASESID (optional) Base SID for all sambaSIDs generated for sambaDomainName, groups and users. Default is S-1-5-21-2475342291-1480345137-508597502.\nLDAP_SAMBA_USEAZURESID (default: true) Use the calculated SIDs for users/groups from AzureAD (GUID/ObjectId) instead of a \u0026ldquo;randomly\u0026rdquo; generated one. You can enable the old handling by setting the env var false.\nmisc DSM7 If set to true the ldap attributes uidNumber and gidNumber are converted from strings to numbers. Somehow this seems to be necessary to work with DSM 7.0. The default value is false.\nHTTPS_PROXY or HTTP_PROXY (optional) URL to your proxy, e.g. http://192.168.1.2:3128\n","description":"The following is a list of all possible settings. The LDAP wrapper is intended to be used with Docker. Therefore, the settings must be made using environment variables.\nAzure Settings AZURE_APP_ID AZURE_TENANTID AZURE_APP_SECRET AZURE_ENDPOINT (optional) Graph API Settings GRAPH_ENDPOINT (optional) GRAPH_API_VERSION (optional) GRAPH_FILTER_USERS (optional) GRAPH_FILTER_GROUPS (optional) GRAPH_IGNORE_MFA_ERRORS (default: false) LDAP Settings LDAP_DOMAIN LDAP_BASEDN (optional) LDAP_SAMBADOMAINNAME (optional) LDAP_BINDUSER LDAP_ANONYMOUSBIND (default: domain) LDAP_DEBUG (default: false) LDAP_PORT (default: 13389) LDAP_SECURE_ATTRIBUTES (optional) LDAP_SENSITIVE_ATTRIBUTES (optional) LDAP_ALLOWCACHEDLOGINONFAILURE (default: true) LDAP_SAMBANTPWD_MAXCACHETIME (optional, default: infinity) LDAP_DAYSTOKEEPDELETEDUSERS (optional, default: 7) LDAP_SYNC_TIME (default: 30 minutes) LDAPS LDAPS_CERTIFICATE LDAPS_KEY Samba SAMBA_BASESID (optional) LDAP_SAMBA_USEAZURESID (default: true) misc DSM7 HTTPS_PROXY or HTTP_PROXY (optional) Azure Settings AZURE_APP_ID Your Application ID from azure (see #4)"},{"id":10,"href":"/AzureAD-LDAP-wrapper/tags/","title":"Tags","parent":"AzureAD-LDAP-wrapper","content":"","description":""},{"id":11,"href":"/AzureAD-LDAP-wrapper/installation/use-synology-nas/","title":"Use on a Synology NAS","parent":"Installation","content":" To access a share on the NAS, for example, from a Windows PC, the credentials must be entered. These credentials are NOT sent to the LDAP-wrapper (or any other LDAP server). They are sent to samba so that it can generate a hash from the password. Afterwards samba fetches the password hash from the LDAP-wrapper and compares the two hashes. Perhaps you are now wondering why this is important to know? Well, the AzureAD-LDAP-wrapper must have this hash before you access a shared folder. Otherwise, you will get an error due to invalid credentials. Maybe you are now wondering how the LDAP-wrapper can obtain the necessary hash? The answer is simple:\nCredential hashes must be cached. Therefore LDAP_SAMBANTPWD_MAXCACHETIME must NOT be set to 0. The user MUST first log in to a service that is directly connected to the LDAP-wrapper (DSM, web application, etc.). Only after that the login in samba can work. The same applies after a password change. The new password has a new hash, so the user must first log in again via another service. This restriction cannot be circumvented.\nConnect Synology NAS to LDAP-wrapper Synology SSO Update existing Docker container on a Synology NAS Connect Synology NAS to LDAP-wrapper To enable users to log in to Synology NAS with their Azure credentials, you need to connect the NAS to the AzureAD-LDAP-wrapper. Here are the steps:\nGo to Control Panel \u0026gt; Domain/LDAP and click \u0026ldquo;Join\u0026rdquo;. Enter the IP address (e.g., 127.0.0.1) of your NAS as the server address. Enter the credentials of your previously defined superuser (environment variable LDAP_BINDUSER) as Bind DN. Should your user not be found, try writing \u0026ldquo;uid=root\u0026rdquo; or the full name \u0026ldquo;uid=root,cn=users,dc=domain,dc=tld\u0026rdquo; instead of just \u0026ldquo;root\u0026rdquo;. Select your domain in Base DN. If you see a warning about a local group having the same name as a synchronized group, you can ignore it and skip the warning in \u0026ldquo;Details\u0026rdquo;. Your NAS should now be connected successfully to the Azure AD LDAP-wrapper. Check the \u0026ldquo;LDAP User\u0026rdquo; and \u0026ldquo;LDAP Group\u0026rdquo; tabs to ensure that all entries are fully synced. Assign the desired permissions to your synchronized users and groups. You can now log in with your Azure AD credentials. Note that before accessing shared folders or files via network or Samba, each user must log in to DSM web GUI or another tool directly connected to the LDAP server. This step is also required after a password change, as the password hash for Samba is only set after a successful login.\nSynology SSO If you don\u0026rsquo;t need samba (network access for shared folders) you can try enabling the Synology OpenID Connect SSO service. Please be aware, it\u0026rsquo;s not working on every DSM version. First tests on a Synology Live Demo with DSM 7.1-42661 were successfull. Unfortunately it didn\u0026rsquo;t work locally on my personal NAS, probably because it\u0026rsquo;ss behind a Firewall/Proxy.\nAdd your URL to access the NAS in Azure Go to Domain/LDAP \u0026gt; SSO Client and Tick Enable OpenID Connect SSO service Select azure as the profile and set the same appid, tenant and secret you used for the docker container. The redirect URI is again your URL to access the NAS. Save everything You should now see \u0026lsquo;Azure SSO Authentication\u0026rsquo; on your DSM login screen Update existing Docker container on a Synology NAS Redownload the latest version Stop your container\nClear your container Check the changelog file (for breaking changes) and apply new settings\nStart your container\nCheck the logs for (new) errors (right click on container and choose \u0026ldquo;Details\u0026rdquo;) Before accessing files via network/samba, each user needs to login in the dsm-web-gui or any other tool directly connected to the ldap server. It\u0026rsquo;s the same after a password change, because the password-hash for samba is only set after a successfull login.\n","description":"To access a share on the NAS, for example, from a Windows PC, the credentials must be entered. These credentials are NOT sent to the LDAP-wrapper (or any other LDAP server). They are sent to samba so that it can generate a hash from the password. Afterwards samba fetches the password hash from the LDAP-wrapper and compares the two hashes. Perhaps you are now wondering why this is important to know?"}]
\ No newline at end of file
+[{"id":0,"href":"/AzureAD-LDAP-wrapper/installation/create-azuread-application/","title":"1.1 Create an AzureAD application","parent":"Installation","content":" Prerequisites Register an application with Azure AD and create a service principal Set permissions Get TenantId, AppId and AppSecret Use TenantId, AppId and AppSecret in your wrapper Prerequisites To register an application in your Azure AD tenant, you need:\nAn Azure AD user account. If you don\u0026rsquo;t already have one, you can create an account for free. Register an application with Azure AD and create a service principal Register a new application in your aad-portal. More descriptions can be found here.\nSign-in to the Azure portal. Select Azure Active Directory and navigateo to App registrations. Select New registration. Name the application, for example \u0026ldquo;ldap-wrapper\u0026rdquo;. Select a supported account type, which determines who can use the application.\nImportant: Personal Microsoft accounts are not supported. Under Redirect URI, select nothing and keep it empty. Select Register.\nSet permissions Set the following Graph-API Application permissions:\nFor type Application allow User.Read.All and Group.Read.All.\nFor type Delegated allow User.Read.\nClick \u0026ldquo;Grant admin consent\u0026rdquo;. The status should be \u0026ldquo;Granted for\u0026rdquo;.\nIf you see en entry with \u0026ldquo;Not granted for\u0026rdquo;, click again: Set Treat application as a public client to Yes\n(former \u0026ldquo;Allow public client flows\u0026rdquo;)\nGet TenantId, AppId and AppSecret Copy and save those values for the later use as environment variables in the Docker container:\nAZURE_TENANTID: Directory (tenant) ID from the page \u0026ldquo;overview\u0026rdquo;. AZURE_APP_ID: Application (client) ID from the page \u0026ldquo;overview\u0026rdquo;. AZURE_APP_SECRET: Value of a new client secret from the page \u0026ldquo;Certificates \u0026amp; secrets\u0026rdquo;.\nUse TenantId, AppId and AppSecret in your wrapper Use a docker container or any other method to run the LDAP-wrapper and start it with the previously saved environment variables.\n","description":"Prerequisites Register an application with Azure AD and create a service principal Set permissions Get TenantId, AppId and AppSecret Use TenantId, AppId and AppSecret in your wrapper Prerequisites To register an application in your Azure AD tenant, you need:\nAn Azure AD user account. If you don\u0026rsquo;t already have one, you can create an account for free. Register an application with Azure AD and create a service principal Register a new application in your aad-portal."},{"id":1,"href":"/AzureAD-LDAP-wrapper/security/","title":"3. Security","parent":"AzureAD-LDAP-wrapper","content":"There are a few things you should definitely keep in mind:\nRestrict access through a firewall. Do NOT allow everyone in your network access to the LDAP-wrapper.\nOnly your (local hosted) applications or your NAS should have access.\nAn LDAP search on the NAS must be possible without any authentication in order to be able to select the domain/baseDN at all. Therefore, some queries can be run as anonymous by default. Data like domain/baseDN or schema can be fetched without authentication. Since this LDAP-wrapper is originally only meant to use the same credentials as in Azure on a NAS, this is the default behaviour. You can change this via the env var LDAP_ANONYMOUSBIND if required.\nIn order to use samba, the user credentials hashes are cached in the ldap attribute sambaNTPassword.\nIf you don\u0026rsquo;t need samba, the cache can be disabled by setting LDAP_SAMBANTPWD_MAXCACHETIME to 0.\nHowever, if you do not disable the cache, there is a special treatment for these hashed credentials. This handling can not be disabled.\nSuperusers, as defined in LDAP_BINDUSER, can get all cached credentials. Each user has access to his own cached credential hash. In all other cases the attribute is returned with XXXX instead of the hash value. In cases such as network/internet issues or Azure not being reachable, the cached hash is used for authentication.\nThis can be a problem if the user has been deactivated in the meantime or the password would be invalid. The use of the cached password during authentication can be disabled by setting the LDAP_ALLOWCACHEDLOGINONFAILURE parameter to false.\nUsing the experimental feature to bypass MFA/2FA\nOfficially MFA is not supported by this LDAP-wrapper. The login for users with activated MFA simply fails, as mentioned here and here. There is an experimental feature to bypass MFA/2FA. It must be manually enabled by setting the the env var GRAPH_IGNORE_MFA_ERRORS to true. Even if the env var is set to true, the login attempt appears as \u0026ldquo;Failure\u0026rdquo; in the AzureAD sign-in logs due to MFA/2FA. It is only the LDAP-wrapper that internally treats some MFA/2FA related error codes as a successful login.\nMapped docker volume\nBe aware that other users with access on your file system may also be able to read the JSON files in the mounted docker path (/app/.cache) and thus get access to the cached sambaNTPassword attribute.\n","description":"There are a few things you should definitely keep in mind:\nRestrict access through a firewall. Do NOT allow everyone in your network access to the LDAP-wrapper.\nOnly your (local hosted) applications or your NAS should have access.\nAn LDAP search on the NAS must be possible without any authentication in order to be able to select the domain/baseDN at all. Therefore, some queries can be run as anonymous by default."},{"id":2,"href":"/AzureAD-LDAP-wrapper/troubleshooting/","title":"4. Troubleshooting","parent":"AzureAD-LDAP-wrapper","content":"The first step is always to look at the Docker log. Many errors are handled there. For further steps, e.g. Samba debugging, read this guide. If you get stuck, feel free to open an issue - but please add the log files, maybe others will be able to read more from them than you.\nDoes it support MFA (multi-factor authentication)? How do I give some synced users the DSM-Administrator permission on a Synology-NAS? Can I use LDAPS (LDAP over SSL) instead of LDAP (with no encryption)? Can I use LDAP over TLS (STARTTLS) instead of LDAP (with no encryption)? Join NAS to Azure AD Domain Why are personal microsoft accounts not supported? Samba is not working, what can I do? Are deleted users or groups in Azure also removed from the LDAP entries? Does it support MFA (multi-factor authentication)? Yes and no\u0026hellip; There is an experimental feature to bypass MFA/2FA. It can be enabled by setting the the env var GRAPH_IGNORE_MFA_ERRORS to true. Officially no, because the login simply fails, as mentioned here and here. Even if the env var is set to true, the login attempt appears as \u0026ldquo;Failure\u0026rdquo; in the AzureAD sign-in logs due to MFA/2FA. It is only the LDAP-wrapper that internally treats some MFA/2FA related error codes as a successful login.\nHow do I give some synced users the DSM-Administrator permission on a Synology-NAS? Before DSM 7: Just create a group called \u0026ldquo;Administrators\u0026rdquo; and put the users in it. With DSM 7: You can delegate specific permissions to each synced group.\nCan I use LDAPS (LDAP over SSL) instead of LDAP (with no encryption)? Sure. Mount your certificate file and private key file to the docker container and then set the environment variables LDAPS_CERTIFICATE and LDAPS_KEY. You may also set LDAP_PORT to 636.\nCan I use LDAP over TLS (STARTTLS) instead of LDAP (with no encryption)? Nope, that\u0026rsquo;s not (yet) possible.\nJoin NAS to Azure AD Domain If you don\u0026rsquo;t need support for older software, the officially Synology solution to join your NAS to a Azure AD Domain will work fine. My wrapper creates an entire ldap server. So you can use it with several 3rd party (legacy) software in the same network.\nWhy are personal microsoft accounts not supported? This wrapper uses the ROPC flow for authentication. Microsoft doesn\u0026rsquo;t support that for personal accounts as mentioned here:\nPersonal accounts that are invited to an Azure AD tenant can\u0026rsquo;t use ROPC.\nSamba is not working, what can I do? Check the following points first:\nIs samba enabled and your user has permissions to use it? Are you using DSM \u0026gt;= 7? Set the ENV variable to true. Look into the docker Log. Are there any errors you should resolve? Did you really connect your device/NAS with a non-existing user from the env var LDAP_BINDUSER? Otherwise the required password hash for Samba is not available and access will fail. Before accessing files via network/Samba, each user must log in to dsm-web-gui or another tool that is directly connected to the ldap server. This also applies after a password change, since the password hash for Samba is only set after a successful login. Is your (Windows) device connected to Azure? Make sure you log in with username/password over the network, not with your pin code. Can you successfully access the shares with a local user? Make sure Synology Directory Service and Synology LDAP server are not installed. Maybe there is someting in the samba log. Get it to open an issue: Enable \u0026ldquo;collect debug logs\u0026rdquo; Try the access a shared folder multiple times ssh into your nas Run cat /var/log/samba/log.smbd and copy the latest error/fail/\u0026hellip; messages - please replace sensitive informations like domains, ip addresses or names. Don\u0026rsquo;t forget to disable \u0026ldquo;collect debug logs\u0026rdquo; before opening an issue Are deleted users or groups in Azure also removed from the LDAP entries? Yes, but with a delay. After a user has been deleted in Azure, it remains available there for about 30 days to undo the deletion. The API stops listing the user a earlier, a few hours after the deletion. In the meantime, the wrapper fetches the user as usual. After this time, the wrapper no longer receives the user. The deletion in the wrapper takes place 7 days later. Why not removing the user immediately? A user could also no longer be in the wrapper due to a misconfigured filter (env var). But just because of such an error, users (and their cached password hashes) should not be deleted immediately. Why not keeping it also 30 days? The user can no longer log in anyway. If the time span is too long (or short), it can be adjusted via the environment variable LDAP_DAYSTOKEEPDELETEDUSERS.\n","description":"The first step is always to look at the Docker log. Many errors are handled there. For further steps, e.g. Samba debugging, read this guide. If you get stuck, feel free to open an issue - but please add the log files, maybe others will be able to read more from them than you.\nDoes it support MFA (multi-factor authentication)? How do I give some synced users the DSM-Administrator permission on a Synology-NAS?"},{"id":3,"href":"/AzureAD-LDAP-wrapper/","title":"AzureAD-LDAP-wrapper","parent":"","content":"AzureAD-LDAP-wrapper is a Node.js LDAP server built on top of (ldapjs) that allows users and groups from Azure Active Directory to be accessed through the LDAP protocol. User authentication is performed using Microsoft Graph API on every login attempt. This enables other applications to connect to the LDAP server and utilize AzureAD login credentials, making it a possible solution for older applications that lack AzureAD support or for scenarios where managing a local AD controller is undesirable.\nI run the project on my Synology NAS in a Docker container. By connecting the NAS and some intranet web applications to the LDAP server, my users can log in to these services using their AzureAD credentials. Although it is possible to achieve this by joining the NAS to AADDS, I preferred not to maintain such a big setup, which includes a virtual machine, VPN, and AADDS, just to allow my three users to use their credentials almost everywhere. How the server works sequenceDiagram\rautonumber\rparticipant LDAP client\rparticipant AzureAD-LDAP-wrapper\rparticipant AAD (Graph API)\rNote over AzureAD-LDAP-wrapper: start LDAP server\rAzureAD-LDAP-wrapper-\u0026gt;\u0026gt;AAD (Graph API): Fetch users and groups\rNote over AzureAD-LDAP-wrapper: cache users and groups locally\rLDAP client-\u0026gt;\u0026gt;\u0026#43;AzureAD-LDAP-wrapper: Attempt to bind with user credentials\rAzureAD-LDAP-wrapper-\u0026gt;\u0026gt;\u0026#43;AAD (Graph API): Check user credentials AAD (Graph API)--\u0026gt;\u0026gt;-AzureAD-LDAP-wrapper: Valid credentials\rNote over AzureAD-LDAP-wrapper: save password hash locally in the cache\rAzureAD-LDAP-wrapper-\u0026gt;\u0026gt;-LDAP client: Successful bind/authenticate\rloop every 30 minutes\rAzureAD-LDAP-wrapper-\u0026gt;\u0026gt;AAD (Graph API): Fetch users and groups again\rNote over AzureAD-LDAP-wrapper: merge and cache users and groups locally\rend The diagram shows the flow of communication between an LDAP client, the AzureAD-LDAP-wrapper, and the Azure Active Directory (AAD) via Graph API.\nFirst, the AzureAD-LDAP-wrapper starts an LDAP server and fetches users and groups from the AAD Graph API. These are cached and merged locally.\nWhen an LDAP client attempts to bind with user credentials, the AzureAD-LDAP-wrapper checks these credentials by communicating with the AAD Graph API. If the credentials are valid, the AAD Graph API sends a success response to the AzureAD-LDAP-wrapper, which then sends a successful bind message to the user\u0026rsquo;s LDAP client. Additionally, the AzureAD-LDAP-wrapper saves the user\u0026rsquo;s password hash in the sambaNTPassword attribute and sets the sambaPwdLastSet attribute to \u0026ldquo;now\u0026rdquo;. This allows the user to access samba shares, such as those on a NAS, from Windows PCs.\nThe AzureAD-LDAP-wrapper periodically fetches user and group information from the AAD Graph API every 30 minutes, merging and caching the results locally. This process preserves attributes like uid, gid, sambaNTPassword, and sambaPwdLastSet.\n","description":"AzureAD-LDAP-wrapper is a Node.js LDAP server built on top of (ldapjs) that allows users and groups from Azure Active Directory to be accessed through the LDAP protocol. User authentication is performed using Microsoft Graph API on every login attempt. This enables other applications to connect to the LDAP server and utilize AzureAD login credentials, making it a possible solution for older applications that lack AzureAD support or for scenarios where managing a local AD controller is undesirable."},{"id":4,"href":"/AzureAD-LDAP-wrapper/configuration/bypass-mfa/","title":"Bypass MFA","parent":"Configuration","content":"Officially MFA is not supported by this LDAP-wrapper. The login for users with activated MFA simply fails, as mentioned here and here. There is no interactive window to enter another factor, and LDAP does not support this either. If you need to use this LDAP-wrapper despite of activated MFA, there are two options:\nDisable MFA for this application in AzureAD (preferred).\nThere are several ways to define MFA, but only some of them allows you to disable MFA.\nPer-user MFA\nMFA could be enabled individually for each user. A possible workaround seems to be the trusted IPs feature, which allows to disable MFA for some IPs, but this feature requires Azure AD Premium.\nIf a login fails due to this MFA method, the error code is AADSTS50079. Security defaults\nSecurity defaults seems to be the only ways for customers using the free Azure AD plan to enable multi-factor authentication in their whole environment. It looks like there are no workarounds to disable MFA for certain IPs or applications.\nIf a login fails due to this MFA method, the error code is AADSTS50076. Conditional Access\nConditional Access can be used to require MFA for some or all the users. This is the most flexible way to activate MFA, but it is a premium feature. The settings allows to exclude certain apps. If a login fails due to this MFA method, the error codea are either AADSTS50158 (for external MFA like Duo) or also AADSTS50079. As a simple workaround, the app used by the LDAP-wrapper can be excluded: Add a URL in the app (e.g. \u0026ldquo;https://localhost\u0026rdquo;) The App can now be selected in the exclude list Let the LDAP-wrapper internally treat some MFA/2FA related error codes as a successful login.\nThere is an experimental feature to bypass MFA/2FA. It must be manually enabled by setting the the env var GRAPH_IGNORE_MFA_ERRORS to true.\nEven if the env var is set to true, the login attempt appears as \u0026ldquo;Failure\u0026rdquo; in the AzureAD sign-in logs due to MFA/2FA. Only the LDAP wrapper internally treats some MFA/2FA-related error codes as successful logins. Specifically, these are the error codes AADSTS50076, AADSTS50079 and AADSTS50158, as mentioned above.\n","description":"Officially MFA is not supported by this LDAP-wrapper. The login for users with activated MFA simply fails, as mentioned here and here. There is no interactive window to enter another factor, and LDAP does not support this either. If you need to use this LDAP-wrapper despite of activated MFA, there are two options:\nDisable MFA for this application in AzureAD (preferred).\nThere are several ways to define MFA, but only some of them allows you to disable MFA."},{"id":5,"href":"/AzureAD-LDAP-wrapper/configuration/","title":"Configuration","parent":"AzureAD-LDAP-wrapper","content":" The LDAP-wrapper works with very little configuration required. That being said, it is highly configurable for the needs of your specific application. ","description":" The LDAP-wrapper works with very little configuration required. That being said, it is highly configurable for the needs of your specific application. "},{"id":6,"href":"/AzureAD-LDAP-wrapper/configuration/customize-attributes/","title":"Customize attributes","parent":"Configuration","content":"It is possible to customize all the ldap attributes. That\u0026rsquo;s what I do in the DSM 7 workaround. Look at this file for an example. Customize it as you need and map the file in your docker setup as /app/customizer/ldap_customizer.js. This file has even priority over the DSM 7 workaround. Basically everything can be changed with it. Filter users or groups, overwrite a users default group, add/remove/edit entries or attributes, and much more.\n","description":"It is possible to customize all the ldap attributes. That\u0026rsquo;s what I do in the DSM 7 workaround. Look at this file for an example. Customize it as you need and map the file in your docker setup as /app/customizer/ldap_customizer.js. This file has even priority over the DSM 7 workaround. Basically everything can be changed with it. Filter users or groups, overwrite a users default group, add/remove/edit entries or attributes, and much more."},{"id":7,"href":"/AzureAD-LDAP-wrapper/installation/","title":"Installation","parent":"AzureAD-LDAP-wrapper","content":" Slow down. Take your time. Make sure you have enough coffee on hand.\nThere are a few steps you need to take to make it work. ","description":" Slow down. Take your time. Make sure you have enough coffee on hand.\nThere are a few steps you need to take to make it work. "},{"id":8,"href":"/AzureAD-LDAP-wrapper/installation/run-ldap-wrapper/","title":"Run the LDAP-wrapper","parent":"Installation","content":"The preferred way to use the LDAP wrapper is with Docker. Alternatively, the source can be downloaded and started manually with npm/node. As domain (and basedn, if manually specified) it is recommended to use the same as used in AzureAD tenant (e.g. @domain.tld). This way, the spelling of the users (e.g. username@domain.tld) will match at the end. Otherwise, your users will have to use username@example.com instead of the estimated username@domain.tld, for example.\nThe API results and a local copy of the LDAP entries are stored as JSON files inside the container at this path: /app/.cache\nMap this folder to provide persistent storage for your users/groups (and their samba password hashes).\nBe aware that other users in the file system may also be able to read the JSON files and thus get access to the cached sambaNTPassword attribute. Synology DSM Docker Install container on a Synology NAS Install Docker from the Synology Package Center. In Docker, go to \u0026ldquo;Registry\u0026rdquo; to download the latest container image. In Docker, go to \u0026ldquo;Image\u0026rdquo; to launch a new container. Use \u0026ldquo;bridge\u0026rdquo; as your network. Use \u0026ldquo;bridge\u0026rdquo; as your network.\nGive your container a name and enable auto-restart. Configure the environment variables in \u0026ldquo;Advanced Settings\u0026rdquo;. Be sure to double check your Azure values and define at least one binduser. The binduser (superuser like root) does not need to exist in your AzureAD. Replace example.com with your domain. Here is an example of a minimum required configuration:\nTZ: \u0026#34;Europe/Zurich\u0026#34; # optional AZURE_TENANTID: \u0026#34;0def2345-ff01-56789-1234-ab9d6dda1e1e\u0026#34; AZURE_APP_ID: \u0026#34;abc12345-ab01-0000-1111-a1e1eab9d6dd\u0026#34; AZURE_APP_SECRET: \u0026#34;iamasecret~yep-reallyreallysecret\u0026#34; LDAP_DOMAIN: \u0026#34;example.com\u0026#34; LDAP_BINDUSER: \u0026#34;ldapsearch|*secretldapsearch123*||root|*secretroot*\u0026#34; LDAP_DEBUG: \u0026#34;false\u0026#34; # set this to true for more logs GRAPH_IGNORE_MFA_ERRORS: \u0026#34;false\u0026#34; # set this to true to bypass MFA DSM7: \u0026#34;true\u0026#34; # set this to false if you are running DSM 6 or lower A full list of all environment variables can be found here.\nSet local Port 389 to the Container Port 13389. If you receive the error Local port 389 conflicts with other ports used by other services, make sure that Synology Directory Service and Synology LDAP Server are not installed - they also use this port. Add a local folder, such as docker/ldap, to the mount path /app/.cache in the volume settings. If you skip this step, your data will not be stored permanently. Click \u0026ldquo;Done\u0026rdquo; to start the container. Docker docker run -d ` -p 389:13389 ` --volume /volume1/docker/ldapwrapper:/app/.cache ` -e AZURE_TENANTID=\u0026#34;0def2345-ff01-56789-1234-ab9d6dda1e1e\u0026#34; ` -e AZURE_APP_ID=\u0026#34;abc12345-ab01-0000-1111-a1e1eab9d6dd\u0026#34; ` -e AZURE_APP_SECRET=\u0026#34;iamasecret~yep-reallyreallysecret\u0026#34; ` -e GRAPH_IGNORE_MFA_ERRORS=\u0026#34;false\u0026#34; ` -e LDAP_DOMAIN=\u0026#34;example.com\u0026#34; ` -e LDAP_BINDUSER=\u0026#34;root|mystrongpw||ldapsearch|ldapsearchpw123\u0026#34; ` ahaen/azuread-ldap-wrapper:latest Docker compose version: \u0026#39;3.2\u0026#39; services: azuread-ldap-wrapper: image: ahaen/azuread-ldap-wrapper:latest container_name: azuread-ldap-wrapper environment: TZ: \u0026#34;Europe/Zurich\u0026#34; AZURE_TENANTID: \u0026#34;0def2345-ff01-56789-1234-ab9d6dda1e1e\u0026#34; AZURE_APP_ID: \u0026#34;abc12345-ab01-0000-1111-a1e1eab9d6dd\u0026#34; AZURE_APP_SECRET: \u0026#34;iamasecret~yep-reallyreallysecret\u0026#34; LDAP_DOMAIN: \u0026#34;example.com\u0026#34; LDAP_BINDUSER: \u0026#34;ldapsearch|ldapsearch123\u0026#34; # LDAP_DEBUG: \u0026#34;true\u0026#34; # GRAPH_IGNORE_MFA_ERRORS: \u0026#34;true\u0026#34; # DSM7: \u0026#34;true\u0026#34; ports: - 389:13389 volumes: - /data/azuread-ldap/app:/app/.cache restart: unless-stopped Portainer version: \u0026#39;3.8\u0026#39; services: azuread-ldap-wrapper: image: \u0026#34;ahaen/azuread-ldap-wrapper:latest\u0026#34; container_name: azuread-ldap-wrapper ports: - 389:13389 network_mode: \u0026#34;bridge\u0026#34; volumes: - /volume1/docker/ldap:/app/.cache environment: TZ: \u0026#34;Europe/Zurich\u0026#34; AZURE_TENANTID: \u0026#34;0def2345-ff01-56789-1234-ab9d6dda1e1e\u0026#34; AZURE_APP_ID: \u0026#34;abc12345-ab01-0000-1111-a1e1eab9d6dd\u0026#34; AZURE_APP_SECRET: \u0026#34;iamasecret~yep-reallyreallysecret\u0026#34; LDAP_DOMAIN: \u0026#34;example.com\u0026#34; LDAP_BINDUSER: \u0026#34;root|root123||ldapsearch|ldapsearch123\u0026#34; # LDAP_DEBUG: \u0026#34;true\u0026#34; # GRAPH_IGNORE_MFA_ERRORS: \u0026#34;true\u0026#34; # DSM7: \u0026#34;true\u0026#34; npm/node This is a minimal example for a running configuration.\nYou can either set environment variables or create an .env file in the root directory.\n## .env file or environment variables ## # Values of your AzureAD application AZURE_APP_ID=\u0026#34;abc12345-ab01-0000-1111-a1e1eab9d6dd\u0026#34; AZURE_TENANTID=\u0026#34;0def2345-ff01-56789-1234-ab9d6dda1e1e\u0026#34; AZURE_APP_SECRET=\u0026#34;iamasecret~yep-reallyreallysecret\u0026#34; # Ignore MFA related errors, so user can login despite of activated MFA # GRAPH_IGNORE_MFA_ERRORS=\u0026#34;false\u0026#34; # Settings for your LDAP server LDAP_DOMAIN=\u0026#34;example.com\u0026#34; LDAP_BINDUSER=\u0026#34;root|mystrongpw||ldapsearch|ldapsearchpw123\u0026#34; # clone repo and open folder git clone https://github.com/ahaenggli/AzureAD-LDAP-wrapper.git cd AzureAD-LDAP-wrapper # install 3rd party libraries npm install # use a .env file or set your env vars # run with npm npm start # or start it with node (\u0026#34;--openssl-legacy-provider\u0026#34; is needed) # node --openssl-legacy-provider index.js Caution Check your Docker log for errors before attempting to use the ldap server. ","description":"The preferred way to use the LDAP wrapper is with Docker. Alternatively, the source can be downloaded and started manually with npm/node. As domain (and basedn, if manually specified) it is recommended to use the same as used in AzureAD tenant (e.g. @domain.tld). This way, the spelling of the users (e.g. username@domain.tld) will match at the end. Otherwise, your users will have to use username@example.com instead of the estimated username@domain.tld, for example."},{"id":9,"href":"/AzureAD-LDAP-wrapper/configuration/settings/","title":"Settings","parent":"Configuration","content":"The following is a list of all possible settings. The LDAP wrapper is intended to be used with Docker. Therefore, the settings must be made using environment variables.\nAzure Settings AZURE_APP_ID AZURE_TENANTID AZURE_APP_SECRET AZURE_ENDPOINT (optional) Graph API Settings GRAPH_ENDPOINT (optional) GRAPH_API_VERSION (optional) GRAPH_FILTER_USERS (optional) GRAPH_FILTER_GROUPS (optional) GRAPH_IGNORE_MFA_ERRORS (default: false) LDAP Settings LDAP_DOMAIN LDAP_BASEDN (optional) LDAP_SAMBADOMAINNAME (optional) LDAP_BINDUSER LDAP_ANONYMOUSBIND (default: domain) LDAP_DEBUG (default: false) LDAP_PORT (default: 13389) LDAP_SECURE_ATTRIBUTES (optional) LDAP_SENSITIVE_ATTRIBUTES (optional) LDAP_ALLOWCACHEDLOGINONFAILURE (default: true) LDAP_SAMBANTPWD_MAXCACHETIME (optional, default: infinity) LDAP_DAYSTOKEEPDELETEDUSERS (optional, default: 7) LDAP_SYNC_TIME (default: 30 minutes) LDAPS LDAPS_CERTIFICATE LDAPS_KEY Samba SAMBA_BASESID (optional) LDAP_SAMBA_USEAZURESID (default: true) misc DSM7 HTTPS_PROXY or HTTP_PROXY (optional) Azure Settings AZURE_APP_ID Your Application ID from azure (see #4)\nAZURE_TENANTID Your Tenant ID from azure (see #3)\nAZURE_APP_SECRET A Client secret-value from azure\nAZURE_ENDPOINT (optional) By default, the Azure AD global service endpoint (https://login.microsoftonline.com) is used. If you prefer to use a different endpoint, you can specify it here.\nGraph API Settings GRAPH_ENDPOINT (optional) By default, the Microsoft Graph global service endpoint (https://graph.microsoft.com) is used. If you prefer to use a different endpoint, you can specify it here.\nGRAPH_API_VERSION (optional) By default, the v1.0 API version is used for the Microsoft Graph endpoint. To use the beta API version instead, specify it here.\nGRAPH_FILTER_USERS (optional) This allows you to filter the users in the graph api using the $filter query parameter.\nThe default filter is set to userType eq 'Member'. That\u0026rsquo;s why external users (guests) will not be synced automatically by default in a Docker container.\nGRAPH_FILTER_GROUPS (optional) This allows you to filter the groups in the graph api using the $filter query parameter. The default filter is set in the Docker container to securityEnabled eq true, so only security groups are synchronized and not every single Teams group. More properties to filter are documented here.\nGRAPH_IGNORE_MFA_ERRORS (default: false) When set to true, some MFA/2FA-related error codes are treated as successful logins. So, it allows logins despite required MFA/2FA. MFA/2FA is thus bypassed.\nWarning: This feature is only experimental and may not work in all cases. Please open an issue if you encounter any problems.\nLDAP Settings LDAP_DOMAIN Your domain, for example domain.tld\nLDAP_BASEDN (optional) The LDAP_BASEDN parameter allows you to specify the base DN (Distinguished Name) for your LDAP server. If this parameter is not provided, the base DN is automatically generated based on the LDAP_DOMAIN value.\nFor example, if your LDAP_DOMAIN is domain.tld, the generated base DN would be dc=domain,dc=tld. Similarly, if your LDAP_DOMAIN is intra.domain.tld, the generated base DN would be dc=intra,dc=domain,dc=tld.\nBy specifying the LDAP_BASEDN, you have the flexibility to customize the base DN according to your LDAP server configuration and organizational structure.\nLDAP_SAMBADOMAINNAME (optional) Default is the first part of your baseDN, for dc=example,dc=net it would be EXAMPLE. For any other value, just set it manually with this env var.\nLDAP_BINDUSER Every AzureAD-user can bind (and auth) in this LDAP-Server. This parameter allows you to add additional - NOT in AzureAD existing - users. Format: \u0026ldquo;username|password\u0026rdquo;. This can be useful to \u0026ldquo;join\u0026rdquo; a device (e.g. NAS). Multiple users can be split by \u0026ldquo;||\u0026rdquo;. (e.g. ldapsearch1|mysecret||searchy2|othersecret). Those users are superusers (e.g. root, admin, \u0026hellip;) and have full read and modify permissions and can also see the sambaNTPassword-hash.\nLDAP_ANONYMOUSBIND (default: domain) Depending on the value, anonymous binding is handelt differently\nnone: no ldap query allowed without binding all: all ldap query are allowed without binding domain: only the domain entry is visible without binding LDAP_DEBUG (default: false) If set to true there are more detailed logs in the console output.\nLDAP_PORT (default: 13389) Sets the port for the listener. The wrapper listens on port 13389 by default. However, if you are running a Docker container directly on the host network, you may want to change the port to 389.\nLDAP_SECURE_ATTRIBUTES (optional) Allows to define secure attributes. Onlye superusers can see them all. Multiple attributes can be split by \u0026ldquo;|\u0026rdquo;. (e.g. customSecurityAttributes_*|PlannedDischargeDate).\nLDAP_SENSITIVE_ATTRIBUTES (optional) Allows to define sensitive attributes. Each user can see his own values, but not those of another user. Additionally, superusers can see them all, too. Multiple attributes can be split by \u0026ldquo;|\u0026rdquo;. (e.g. middlename|PrivatePhoneNumber).\nLDAP_ALLOWCACHEDLOGINONFAILURE (default: true) allows login from cached sambaNTPassword. If set to true, the login has failed and the error does NOT say \u0026ldquo;wrong credentials\u0026rdquo;, the password is checked against the cached sambaNTPassword. If it matches, the authentification is successfull.\nLDAP_SAMBANTPWD_MAXCACHETIME (optional, default: infinity) Maximum time in minutes that defines how long a cached sambaNTPassword hash can be used (for login and samba access). After that time, a user has to login \u0026rsquo;normal\u0026rsquo; via the bind method (e.g. dsm-web-gui) to reset the cached value. As default there is no time limit (-1=infinity). If this time limit is set to 0, no samba access is possible and therefore no password hash is cached.\nLDAP_DAYSTOKEEPDELETEDUSERS (optional, default: 7) Defines the number of days after deletion in Azure after which an entry is also removed in the wrapper. By default, te deletion in the wrapper takes place about 7 days later. The reason for the delay is simple: A user could also no longer be in the wrapper due to a misconfigured filter (env var). But just because of such an error, users (and their cached password hashes) should not be deleted immediately. However, you can set the value to 0 to delete a user/group immediately. Use a negative value like -1 to keep everything in the wrapper and not delete anything.\nLDAP_SYNC_TIME (default: 30 minutes) The interval in minutes for fetching users/groups from azure. The default is 30 minutes.\nLDAPS LDAPS_CERTIFICATE Path to your certificate.pem file. You also have to set LDAPS_KEY to run LDAP over SSL. You may also need to set LDAP_PORT to 636.\nLDAPS_KEY Path to private key file. You also have to set LDAPS_CERTIFICATE to run LDAP over SSL. You may also need to set LDAP_PORT to 636.\nSamba SAMBA_BASESID (optional) Base SID for all sambaSIDs generated for sambaDomainName, groups and users. Default is S-1-5-21-2475342291-1480345137-508597502.\nLDAP_SAMBA_USEAZURESID (default: true) Use the calculated SIDs for users/groups from AzureAD (GUID/ObjectId) instead of a \u0026ldquo;randomly\u0026rdquo; generated one. You can enable the old handling by setting the env var false.\nmisc DSM7 If set to true the ldap attributes uidNumber and gidNumber are converted from strings to numbers. Somehow this seems to be necessary to work with DSM 7.0. The default value is false.\nHTTPS_PROXY or HTTP_PROXY (optional) URL to your proxy, e.g. http://192.168.1.2:3128\n","description":"The following is a list of all possible settings. The LDAP wrapper is intended to be used with Docker. Therefore, the settings must be made using environment variables.\nAzure Settings AZURE_APP_ID AZURE_TENANTID AZURE_APP_SECRET AZURE_ENDPOINT (optional) Graph API Settings GRAPH_ENDPOINT (optional) GRAPH_API_VERSION (optional) GRAPH_FILTER_USERS (optional) GRAPH_FILTER_GROUPS (optional) GRAPH_IGNORE_MFA_ERRORS (default: false) LDAP Settings LDAP_DOMAIN LDAP_BASEDN (optional) LDAP_SAMBADOMAINNAME (optional) LDAP_BINDUSER LDAP_ANONYMOUSBIND (default: domain) LDAP_DEBUG (default: false) LDAP_PORT (default: 13389) LDAP_SECURE_ATTRIBUTES (optional) LDAP_SENSITIVE_ATTRIBUTES (optional) LDAP_ALLOWCACHEDLOGINONFAILURE (default: true) LDAP_SAMBANTPWD_MAXCACHETIME (optional, default: infinity) LDAP_DAYSTOKEEPDELETEDUSERS (optional, default: 7) LDAP_SYNC_TIME (default: 30 minutes) LDAPS LDAPS_CERTIFICATE LDAPS_KEY Samba SAMBA_BASESID (optional) LDAP_SAMBA_USEAZURESID (default: true) misc DSM7 HTTPS_PROXY or HTTP_PROXY (optional) Azure Settings AZURE_APP_ID Your Application ID from azure (see #4)"},{"id":10,"href":"/AzureAD-LDAP-wrapper/tags/","title":"Tags","parent":"AzureAD-LDAP-wrapper","content":"","description":""},{"id":11,"href":"/AzureAD-LDAP-wrapper/installation/use-synology-nas/","title":"Use on a Synology NAS","parent":"Installation","content":" To access a share on the NAS, for example, from a Windows PC, the credentials must be entered. These credentials are NOT sent to the LDAP-wrapper (or any other LDAP server). They are sent to samba so that it can generate a hash from the password. Afterwards samba fetches the password hash from the LDAP-wrapper and compares the two hashes. Perhaps you are now wondering why this is important to know? Well, the AzureAD-LDAP-wrapper must have this hash before you access a shared folder. Otherwise, you will get an error due to invalid credentials. Maybe you are now wondering how the LDAP-wrapper can obtain the necessary hash? The answer is simple:\nCredential hashes must be cached. Therefore LDAP_SAMBANTPWD_MAXCACHETIME must NOT be set to 0. The user MUST first log in to a service that is directly connected to the LDAP-wrapper (DSM, web application, etc.). Only after that the login in samba can work. The same applies after a password change. The new password has a new hash, so the user must first log in again via another service. This restriction cannot be circumvented.\nConnect Synology NAS to LDAP-wrapper Synology SSO Update existing Docker container on a Synology NAS Connect Synology NAS to LDAP-wrapper To enable users to log in to Synology NAS with their Azure credentials, you need to connect the NAS to the AzureAD-LDAP-wrapper. Here are the steps:\nGo to Control Panel \u0026gt; Domain/LDAP and click \u0026ldquo;Join\u0026rdquo;. Enter the IP address (e.g., 127.0.0.1) of your NAS as the server address. Enter the credentials of your previously defined superuser (environment variable LDAP_BINDUSER) as Bind DN. Should your user not be found, try writing \u0026ldquo;uid=root\u0026rdquo; or the full name \u0026ldquo;uid=root,cn=users,dc=domain,dc=tld\u0026rdquo; instead of just \u0026ldquo;root\u0026rdquo;. Select your domain in Base DN. If you see a warning about a local group having the same name as a synchronized group, you can ignore it and skip the warning in \u0026ldquo;Details\u0026rdquo;. Your NAS should now be connected successfully to the Azure AD LDAP-wrapper. Check the \u0026ldquo;LDAP User\u0026rdquo; and \u0026ldquo;LDAP Group\u0026rdquo; tabs to ensure that all entries are fully synced. Assign the desired permissions to your synchronized users and groups. You can now log in with your Azure AD credentials. Note that before accessing shared folders or files via network or Samba, each user must log in to DSM web GUI or another tool directly connected to the LDAP server. This step is also required after a password change, as the password hash for Samba is only set after a successful login.\nSynology SSO If you don\u0026rsquo;t need samba (network access for shared folders) you can try enabling the Synology OpenID Connect SSO service. Please be aware, it\u0026rsquo;s not working on every DSM version. First tests on a Synology Live Demo with DSM 7.1-42661 were successfull. Unfortunately it didn\u0026rsquo;t work locally on my personal NAS, probably because it\u0026rsquo;ss behind a Firewall/Proxy.\nAdd your URL to access the NAS in Azure Go to Domain/LDAP \u0026gt; SSO Client and Tick Enable OpenID Connect SSO service Select azure as the profile and set the same appid, tenant and secret you used for the docker container. The redirect URI is again your URL to access the NAS. Save everything You should now see \u0026lsquo;Azure SSO Authentication\u0026rsquo; on your DSM login screen Update existing Docker container on a Synology NAS Redownload the latest version Stop your container\nClear your container Check the changelog file (for breaking changes) and apply new settings\nStart your container\nCheck the logs for (new) errors (right click on container and choose \u0026ldquo;Details\u0026rdquo;) Before accessing files via network/samba, each user needs to login in the dsm-web-gui or any other tool directly connected to the ldap server. It\u0026rsquo;s the same after a password change, because the password-hash for samba is only set after a successfull login.\n","description":"To access a share on the NAS, for example, from a Windows PC, the credentials must be entered. These credentials are NOT sent to the LDAP-wrapper (or any other LDAP server). They are sent to samba so that it can generate a hash from the password. Afterwards samba fetches the password hash from the LDAP-wrapper and compares the two hashes. Perhaps you are now wondering why this is important to know?"}]
\ No newline at end of file
diff --git a/sitemap.xml b/sitemap.xml
index b0fe178..d026d54 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -15,7 +15,7 @@
     <lastmod>2023-03-26T13:44:37+02:00</lastmod>
   </url><url>
     <loc>https://ahaenggli.github.io/AzureAD-LDAP-wrapper/configuration/bypass-mfa/</loc>
-    <lastmod>2023-03-04T20:54:20+01:00</lastmod>
+    <lastmod>2023-07-21T12:16:16+02:00</lastmod>
   </url><url>
     <loc>https://ahaenggli.github.io/AzureAD-LDAP-wrapper/configuration/</loc>
     <lastmod>2023-03-04T20:54:20+01:00</lastmod>
@@ -27,10 +27,10 @@
     <lastmod>2023-03-04T20:54:20+01:00</lastmod>
   </url><url>
     <loc>https://ahaenggli.github.io/AzureAD-LDAP-wrapper/installation/run-ldap-wrapper/</loc>
-    <lastmod>2023-03-26T20:48:22+02:00</lastmod>
+    <lastmod>2023-07-17T10:26:34+02:00</lastmod>
   </url><url>
     <loc>https://ahaenggli.github.io/AzureAD-LDAP-wrapper/configuration/settings/</loc>
-    <lastmod>2023-03-26T13:44:37+02:00</lastmod>
+    <lastmod>2023-07-17T10:26:34+02:00</lastmod>
   </url><url>
     <loc>https://ahaenggli.github.io/AzureAD-LDAP-wrapper/tags/</loc>
   </url><url>