diff --git a/configuration/index.xml b/configuration/index.xml
index 749c130..e026575 100644
--- a/configuration/index.xml
+++ b/configuration/index.xml
@@ -33,7 +33,7 @@ There are several ways to define MFA, but only some of them allows you to disabl
       
       <guid>https://ahaenggli.github.io/AzureAD-LDAP-wrapper/configuration/settings/</guid>
       <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.
-Azure 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)</description>
+Azure 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) LDAP_USERS_SYNCONLYINGROUP LDAP_USERS_SETDEFAULTGROUP 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)</description>
     </item>
     
   </channel>
diff --git a/configuration/settings/index.html b/configuration/settings/index.html
index ecdec29..a39c744 100644
--- a/configuration/settings/index.html
+++ b/configuration/settings/index.html
@@ -13,7 +13,7 @@
 
 
   <meta name="description" 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.
-Azure 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)" />
+Azure 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) LDAP_USERS_SYNCONLYINGROUP LDAP_USERS_SETDEFAULTGROUP 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)" />
 
     <title>Settings | AzureAD-LDAP-wrapper</title>
 
@@ -40,21 +40,21 @@
   />
   <meta property="og:site_name" content="AzureAD-LDAP-wrapper" />
   <meta property="og:description" 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.
-Azure 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)" />
+Azure 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) LDAP_USERS_SYNCONLYINGROUP LDAP_USERS_SETDEFAULTGROUP 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)" />
 <meta property="og:type" content="article" />
 <meta property="og:url" content="https://ahaenggli.github.io/AzureAD-LDAP-wrapper/configuration/settings/" />
 
 <meta property="article:section" content="Configuration" />
     <meta
       property="article:modified_time"
-      content="2023-07-17T10:26:34+02:00"
+      content="2024-02-04T15:07:20+01:00"
     />
 
 
   <meta name="twitter:card" content="summary" />
 <meta name="twitter:title" content="Settings" />
   <meta name="twitter:description" 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.
-Azure 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)" />
+Azure 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) LDAP_USERS_SYNCONLYINGROUP LDAP_USERS_SETDEFAULTGROUP 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)" />
 
 
   <script type="application/ld+json">
@@ -65,8 +65,8 @@
       "name": "Settings",
       "url" : "https://ahaenggli.github.io/AzureAD-LDAP-wrapper/configuration/settings/",
       "headline": "Settings",
-      "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)",
-      "wordCount" : "1061",
+      "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) LDAP_USERS_SYNCONLYINGROUP LDAP_USERS_SETDEFAULTGROUP 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)",
+      "wordCount" : "1200",
       "inLanguage": "en",
       "isFamilyFriendly": "true",
       "mainEntityOfPage": {
@@ -77,7 +77,7 @@
       "copyrightYear" : "0001",
       "dateCreated": "0001-01-01T00:00:00.00Z",
       "datePublished": "0001-01-01T00:00:00.00Z",
-      "dateModified": "2023-07-17T10:26:34.00Z",
+      "dateModified": "2024-02-04T15:07:20.00Z",
       "publisher":{
           "@type":"Organization",
           "name": "AzureAD-LDAP-wrapper",
@@ -1345,6 +1345,8 @@ <h1>Settings</h1>
             <li><a href="#ldap_sambantpwd_maxcachetime-optional-default-infinity">LDAP_SAMBANTPWD_MAXCACHETIME (optional, default: infinity)</a></li>
             <li><a href="#ldap_daystokeepdeletedusers-optional-default-7">LDAP_DAYSTOKEEPDELETEDUSERS (optional, default: 7)</a></li>
             <li><a href="#ldap_sync_time-default-30-minutes">LDAP_SYNC_TIME (default: 30 minutes)</a></li>
+            <li><a href="#ldap_users_synconlyingroup">LDAP_USERS_SYNCONLYINGROUP</a></li>
+            <li><a href="#ldap_users_setdefaultgroup">LDAP_USERS_SETDEFAULTGROUP</a></li>
           </ul>
         </li>
         <li><a href="#ldaps">LDAPS</a>
@@ -1635,6 +1637,27 @@ <h3 id="ldap_sync_time-default-30-minutes">
     </h3>
 </div>
 <p>The interval in minutes for fetching users/groups from azure. The default is 30 minutes.</p>
+<div class="gdoc-page__anchorwrap">
+    <h3 id="ldap_users_synconlyingroup">
+        LDAP_USERS_SYNCONLYINGROUP
+        <a data-clipboard-text="https://ahaenggli.github.io/AzureAD-LDAP-wrapper/configuration/settings/#ldap_users_synconlyingroup" class="gdoc-page__anchor clip flex align-center" title="Anchor to: LDAP_USERS_SYNCONLYINGROUP" aria-label="Anchor to: LDAP_USERS_SYNCONLYINGROUP" href="#ldap_users_synconlyingroup">
+            <svg class="gdoc-icon gdoc_link"><use xlink:href="#gdoc_link"></use></svg>
+        </a>
+    </h3>
+</div>
+<p>When set, only users within the specified groups are fetched and made available in the wrapper.
+Multiple group names can be specified using the pipe character (|). The variable can be used in conjunction with <code>LDAP_USERS_SETDEFAULTGROUP</code>.</p>
+<div class="gdoc-page__anchorwrap">
+    <h3 id="ldap_users_setdefaultgroup">
+        LDAP_USERS_SETDEFAULTGROUP
+        <a data-clipboard-text="https://ahaenggli.github.io/AzureAD-LDAP-wrapper/configuration/settings/#ldap_users_setdefaultgroup" class="gdoc-page__anchor clip flex align-center" title="Anchor to: LDAP_USERS_SETDEFAULTGROUP" aria-label="Anchor to: LDAP_USERS_SETDEFAULTGROUP" href="#ldap_users_setdefaultgroup">
+            <svg class="gdoc-icon gdoc_link"><use xlink:href="#gdoc_link"></use></svg>
+        </a>
+    </h3>
+</div>
+<p>When set, the first specified group associated with the user will be used as the default group.
+Multiple group names can be specified using the pipe character (|). For example, <code>admins|finance|hr</code>. If a user is within both groups (finance and hr), the default group will be set to finance because it was defined first.
+With DSM 7, there are some issues regarding group permissions. ACL and UID/GID shifting can help. However, when losing the permissions, there seems to be some sort of fallback to the default group. With this setting, you can adjust the default group for your users.</p>
 <div class="gdoc-page__anchorwrap">
     <h2 id="ldaps">
         LDAPS
diff --git a/index.xml b/index.xml
index 28adf3c..c18e9a8 100644
--- a/index.xml
+++ b/index.xml
@@ -88,7 +88,7 @@ There are several ways to define MFA, but only some of them allows you to disabl
       
       <guid>https://ahaenggli.github.io/AzureAD-LDAP-wrapper/configuration/settings/</guid>
       <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.
-Azure 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)</description>
+Azure 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) LDAP_USERS_SYNCONLYINGROUP LDAP_USERS_SETDEFAULTGROUP 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)</description>
     </item>
     
     <item>
diff --git a/installation/use-synology-nas/index.html b/installation/use-synology-nas/index.html
index 8b3bfe2..04668d7 100644
--- a/installation/use-synology-nas/index.html
+++ b/installation/use-synology-nas/index.html
@@ -63,7 +63,7 @@
       "url" : "https://ahaenggli.github.io/AzureAD-LDAP-wrapper/installation/use-synology-nas/",
       "headline": "Use on a Synology NAS",
       "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?",
-      "wordCount" : "628",
+      "wordCount" : "649",
       "inLanguage": "en",
       "isFamilyFriendly": "true",
       "mainEntityOfPage": {
@@ -1360,6 +1360,10 @@ <h2 id="connect-synology-nas-to-ldap-wrapper">
 </li>
 <li>
 <p>Enter the credentials of your previously defined superuser (environment variable <code>LDAP_BINDUSER</code>) as Bind DN. Should your user not be found, try writing &ldquo;uid=root&rdquo; or the full name &ldquo;uid=root,cn=users,dc=domain,dc=tld&rdquo; instead of just &ldquo;root&rdquo;. Select your domain in Base DN.
+To prevent potential problems with permissions in Samba, it&rsquo;s recommended to enable <code>UID/GID shifting</code>. Refer to <a
+  class="gdoc-markdown__link"
+  href="https://github.com/ahaenggli/AzureAD-LDAP-wrapper/issues/47"
+>issue #47</a> for more details.
 <img
   src="../use/syno_ldap_infos.png"
   alt="enter ldap infos"
diff --git a/search/en.data.min.json b/search/en.data.min.json
index 22b84b1..507fcc7 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 Register an application with the Microsoft identity platform","parent":"Installation","content":" Prerequisites Register an application with the Microsoft identity platform Set permissions Get TenantId, AppId and AppSecret Use TenantId, AppId and AppSecret in your wrapper Prerequisites To register an application with the Microsoft identity platform, you need:\nA Microsoft Entra ID user account. If you don\u0026rsquo;t already have one, you can create an account for free. Register an application with the Microsoft identity platform Register a new application in your Microsoft Entra Admin Center. More descriptions can be found here.\nSign-in to the Microsoft Entra Admin Center. Browse to Identity \u0026gt; Applications \u0026gt; 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 Microsoft 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 Allow public client flows to Yes\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 the Microsoft identity platform Set permissions Get TenantId, AppId and AppSecret Use TenantId, AppId and AppSecret in your wrapper Prerequisites To register an application with the Microsoft identity platform, you need:\nA Microsoft Entra ID user account. If you don\u0026rsquo;t already have one, you can create an account for free. Register an application with the Microsoft identity platform Register a new application in your Microsoft Entra Admin Center."},{"id":1,"href":"/AzureAD-LDAP-wrapper/security/","title":"3. Security","parent":"LDAP-wrapper for Microsoft Entra ID","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 my work account (Microsoft Entra Account) 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 Microsoft Graph API / Entra ID 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 Microsoft Entra ID 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":"LDAP-wrapper for Microsoft Entra ID","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 Microsoft Entra Domain Services Why are personal microsoft accounts not supported? Samba is not working, what can I do? Are deleted users or groups in Entra 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 Microsoft Entra 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 Microsoft Entra Domain Services If you don\u0026rsquo;t need support for older software, the officially Synology solution to join your NAS to a Microsoft Entra Domain Services 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 Microsoft Entra 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 Microsoft Entra (formerly Azure AD joined devices)? 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 Entra also removed from the LDAP entries? Yes, but with a delay. After a user has been deleted in Microsoft Entra, 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/usage/portainer/","title":"6.1 Portainer","parent":"Usage examples","content":"Portainer supports LDAP authentication, allowing users to log in by authenticating against your LDAP directory. This guide outlines the steps to set up LDAP authentication over LDAP-wrapper with Portainer.\nPrerequisites Settings for Portainer LDAP Authentication with LDAP-wrapper LDAP Configuration LDAP Security User Search Configurations Prerequisites Before configuring LDAP authentication for Portainer, ensure the following prerequisites are met:\nLDAP-wrapper: Make sure you have a working LDAP-wrapper. Portainer: Install and set up a working instance of Portainer. Settings for Portainer LDAP Authentication with LDAP-wrapper LDAP Configuration LDAP Server: Specify the IP or name of your NAS with Port 389.\nExample: 192.168.1.2:389 or my-nas-name.local:389 Reader DN: Set it to uid=root, matching an entry of your LDAP-wrapper environment variable LDAP_BINDUSER. Password: Set it to the password corresponding to the entry in your LDAP-wrapper environment variable LDAP_BINDUSER. LDAP Security Ensure that StartTLS, Use TLS, and Skip verification are set to off. User Search Configurations Base DN: Define the base DN as cn=users,dc=domain,dc=tld.\nUsername Attribute: Specify mail.\nFilter: Use the following filter to restrict access:\n(|(\u0026amp;(uid=*)(memberOf=cn=users,cn=groups,dc=domain,dc=tld))(\u0026amp;(cn=administrators))) This filter ensures that only users within the administrators group can log into Portainer.\nDon\u0026rsquo;t forget to save your LDAP-wrapper configuration. Now, users attempting to log into Portainer will be authenticated against your LDAP directory. Only users within the administrators group, as specified in the LDAP filter, will be allowed access to Portainer.\n","description":"Portainer supports LDAP authentication, allowing users to log in by authenticating against your LDAP directory. This guide outlines the steps to set up LDAP authentication over LDAP-wrapper with Portainer.\nPrerequisites Settings for Portainer LDAP Authentication with LDAP-wrapper LDAP Configuration LDAP Security User Search Configurations Prerequisites Before configuring LDAP authentication for Portainer, ensure the following prerequisites are met:\nLDAP-wrapper: Make sure you have a working LDAP-wrapper. Portainer: Install and set up a working instance of Portainer."},{"id":4,"href":"/AzureAD-LDAP-wrapper/usage/authelia/","title":"6.2 Authelia with LDAP-wrapper","parent":"Usage examples","content":"Authelia supports LDAP authentication, enabling users to log in by authenticating against your LDAP directory. This guide outlines the steps to set up LDAP authentication with Authelia using LDAP-wrapper.\nPrerequisites Settings for Authelia LDAP Authentication with LDAP-wrapper Prerequisites Before configuring LDAP authentication for Authelia with LDAP-wrapper, ensure the following prerequisites are met:\nLDAP-wrapper: Ensure you have a functioning LDAP-wrapper. Authelia: Set up and configure Authelia for your environment. Settings for Authelia LDAP Authentication with LDAP-wrapper To configure LDAP authentication with Authelia using LDAP-wrapper, follow these steps:\nOpen your configuration.yml file in the Authelia configuration directory. Locate the authentication_backend section and configure it with the following example, adjusting the url,base_dn, user, and password based on your LDAP-wrapper setup: ## Authentication Backend Provider Configuration authentication_backend: ## Password Reset Options password_reset: ## Disable both the HTML element and the API for reset password functionality. disable: true ## External reset password url for Microsoft custom_url: \u0026#34;https://account.activedirectory.windowsazure.com/ChangePassword.aspx\u0026#34; ## The amount of time to wait before we refresh data from the authentication backend. Uses duration notation ## See the below documentation for more information ## Duration Notation docs: \u0026lt;https://www.authelia.com/c/common#duration-notation-format\u0026gt; ## Refresh Interval docs: \u0026lt;https://www.authelia.com/c/1fa#refresh-interval\u0026gt; refresh_interval: 5m ## ## LDAP (Authentication Provider) ## ldap: ## The LDAP implementation, this affects elements like the attribute utilised for resetting a password. implementation: custom ## The url to the ldap server. Format: \u0026lt;scheme\u0026gt;://\u0026lt;address\u0026gt;[:\u0026lt;port\u0026gt;]. url: ldap://my-nas-name.local:389 ## The dial timeout for LDAP. timeout: 5s ## Use StartTLS with the LDAP connection. start_tls: false tls: ## Server Name for certificate validation (in case it\u0026#39;s not set correctly in the URL). # server_name: ldap.domain.tld ## Skip verifying the server certificate (to allow a self-signed certificate). skip_verify: false ## Minimum TLS version for either Secure LDAP or LDAP StartTLS. minimum_version: TLS1.2 ## The distinguished name of the container searched for objects in the directory information tree. base_dn: dc=domain,dc=tld ## The attribute holding the username of the user. This attribute is used to populate the username in the session username_attribute: uid ## The additional_users_dn is prefixed to base_dn and delimited by a comma when searching for users. additional_users_dn: cn=users ## The users filter used in search queries to find the user profile based on input filled in login form. users_filter: (\u0026amp;(|({username_attribute}={input})({mail_attribute}={input}))(objectClass=person)) ## The additional_groups_dn is prefixed to base_dn and delimited by a comma when searching for groups. additional_groups_dn: cn=groups ## The groups filter used in search queries to find the groups based on relevant authenticated user. groups_filter: (\u0026amp;(member={dn})(objectClass=posixGroup)) ## The attribute holding the name of the group. group_name_attribute: cn ## The attribute holding the mail address of the user. If multiple email addresses are defined for a user, only the mail_attribute: mail ## The attribute holding the display name of the user. This will be used to greet an authenticated user. display_name_attribute: displayName ## Follow referrals returned by the server. ## This is especially useful for environments where read-only servers exist. Only implemented for write operations. permit_referrals: false ## The username and password of the admin user, matching an entry of your LDAP-wrapper environment variable `LDAP_BINDUSER`. user: uid=root ## Password can also be set using a secret: \u0026lt;https://www.authelia.com/c/secrets\u0026gt; password: 1234 Save the changes to your configuration.yml file. Restart Authelia to apply the new configuration. Now, Authelia is configured to authenticate users against your LDAP directory through LDAP-wrapper.\n","description":"Authelia supports LDAP authentication, enabling users to log in by authenticating against your LDAP directory. This guide outlines the steps to set up LDAP authentication with Authelia using LDAP-wrapper.\nPrerequisites Settings for Authelia LDAP Authentication with LDAP-wrapper Prerequisites Before configuring LDAP authentication for Authelia with LDAP-wrapper, ensure the following prerequisites are met:\nLDAP-wrapper: Ensure you have a functioning LDAP-wrapper. Authelia: Set up and configure Authelia for your environment. Settings for Authelia LDAP Authentication with LDAP-wrapper To configure LDAP authentication with Authelia using LDAP-wrapper, follow these steps:"},{"id":5,"href":"/AzureAD-LDAP-wrapper/usage/synology-radius-unifi/","title":"6.3 Synology Radius with UniFi","parent":"Usage examples","content":"UniFi allows you to use a custom Radius server like the default package from Synology. Combined with the LDAP-wrapper, this creates a powerful setup for your users.\nDSM 7.2.1-69057 Update 3\nLDAP-wrapper v2.0.2\nRADIUS Server Package 3.0.25-0515\nUniFi Network Application 8.0.24 Prerequisites Settings in Synology RADIUS Server Settings in UniFi Controller Prerequisites Before configuring Synology Radius and UniFi, ensure the following prerequisites are met:\nSynology NAS: Ensure you are up to date with your DSM, and install the current RADIUS Server package. LDAP-wrapper: Ensure you have a functioning LDAP-wrapper. UniFi AP: Ensure you are up to date and have access to your controller settings. Settings in Synology RADIUS Server Open the RADIUS Server package on your Synology NAS.\nConfigure the RADIUS Common Settings with the following parameters:\nAuthentication port: Set the RADIUS Server\u0026rsquo;s port number for interface protocols. The default value is 1812 for authentication. Select network interface: Choose the network interfaces connected to RADIUS client devices (e.g., a router). RADIUS Server provides authentication services only for access requests coming from the specified interface. TLS/SSL profile level: Choose \u0026ldquo;Intermediate compatibility,\u0026rdquo; which is the default setting. This option is recommended because it is compatible with general-purpose browsers but is not compatible with insecure cipher suites. Source for user authentication: Enable LDAP users. Check your certificates.\nRADIUS Server requires a valid certificate. Configure the RADIUS Clients by adding clients based on the IP address range.\nEach UniFi AP will directly contact your Synology RADIUS Server. Ensure that your firewall allows all those APs to connect to your NAS with the previously defined port (e.g., 1812). To set up clients by IP address range:\nClick Add and choose Subnet, then enter the following information:\nName: Enter a display name for the collection of clients, making it easier to identify. IP address: Enter the base IP addresses of the RADIUS clients (e.g., 192.168.10.1). Subnet mask: Enter a subnet mask, for example, 255.255.255.0. Shared secret: Enter a text string used as a password between the clients and RADIUS Server. This secret will also be needed in your UniFi configuration. Settings in UniFi Controller Log in to your UniFi controller.\nNavigate to Settings \u0026gt; Profiles \u0026gt; RADIUS and create a new entry.\nEnable Wired Networks. Enable Wireless Networks. Enter the IP address of your Synology NAS in the IP Address field. Specify the RADIUS authentication port (typically 1812) in the Port field. Enter the same shared secret configured in the Synology RADIUS Server in the Shared Secret field. Disable Accounting. Navigate to the Wireless Networks section (Settings \u0026gt; WiFi) and edit your network.\nEdit the Wireless Network where you want to enable RADIUS authentication.\nEnable WPA Enterprise. Select the previously added RADIUS Profile. Save the settings and apply the changes to your UniFi network.\nNow, UniFi is configured to use the Synology RADIUS Server for authentication. Users authenticated through UniFi will be verified against your LDAP directory using LDAP-wrapper, creating a robust and secure setup.\n","description":"UniFi allows you to use a custom Radius server like the default package from Synology. Combined with the LDAP-wrapper, this creates a powerful setup for your users.\nDSM 7.2.1-69057 Update 3\nLDAP-wrapper v2.0.2\nRADIUS Server Package 3.0.25-0515\nUniFi Network Application 8.0.24 Prerequisites Settings in Synology RADIUS Server Settings in UniFi Controller Prerequisites Before configuring Synology Radius and UniFi, ensure the following prerequisites are met:\nSynology NAS: Ensure you are up to date with your DSM, and install the current RADIUS Server package."},{"id":6,"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 your tenant (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 Microsoft Entra ID 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 Microsoft Entra ID 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 Microsoft Entra ID 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 your tenant (preferred).\nThere are several ways to define MFA, but only some of them allows you to disable MFA."},{"id":7,"href":"/AzureAD-LDAP-wrapper/configuration/","title":"Configuration","parent":"LDAP-wrapper for Microsoft Entra ID","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":8,"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":9,"href":"/AzureAD-LDAP-wrapper/installation/","title":"Installation","parent":"LDAP-wrapper for Microsoft Entra ID","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":10,"href":"/AzureAD-LDAP-wrapper/","title":"LDAP-wrapper for Microsoft Entra ID","parent":"","content":"LDAP-wrapper is a Node.js LDAP server built on top of (ldapjs) that allows users and groups from Microsoft Entra ID (formerly Azure Active Directory) to be accessed through the LDAP protocol. User authentication is performed using Microsoft Graph API on every login attempt. This allows your other applications to connect to the LDAP server and thus allows your end users to authenticate with a work or school account.\nThis it a possible workaround for older applications that lack Microsoft Entra ID 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 work accounts. 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 Microsoft Entra Domain Services (formerly AADDS / Azure Active Directory Domain Services), just to allow my three users to use their credentials almost everywhere. How the server works sequenceDiagram\rautonumber\rparticipant LDAP client\rparticipant LDAP-wrapper\rparticipant ME-ID (Graph API)\rNote over LDAP-wrapper: start LDAP server\rLDAP-wrapper-\u0026gt;\u0026gt;ME-ID (Graph API): Fetch users and groups\rNote over LDAP-wrapper: cache users and groups locally\rLDAP client-\u0026gt;\u0026gt;\u0026#43;LDAP-wrapper: Attempt to bind with user credentials\rLDAP-wrapper-\u0026gt;\u0026gt;\u0026#43;ME-ID (Graph API): Check user credentials\rME-ID (Graph API)--\u0026gt;\u0026gt;-LDAP-wrapper: Valid credentials\rNote over LDAP-wrapper: save password hash locally in the cache\rLDAP-wrapper-\u0026gt;\u0026gt;-LDAP client: Successful bind/authenticate\rloop every 30 minutes\rLDAP-wrapper-\u0026gt;\u0026gt;ME-ID (Graph API): Fetch users and groups again\rNote over LDAP-wrapper: merge and cache users and groups locally\rend The LDAP-wrapper starts an LDAP server and fetches users and groups from the Microsoft Graph API. These are cached and merged locally.\nWhen an LDAP client attempts to bind with user credentials, the LDAP-wrapper checks these credentials by communicating with the Microsoft Graph API. If the credentials are valid, the Microsoft Graph API sends a success response to the LDAP-wrapper, which then sends a successful bind message to the user\u0026rsquo;s LDAP client. Additionally, the 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 LDAP-wrapper periodically fetches user and group information from the Microsoft Graph API every 30 minutes, merging and caching the results locally. This process preserves attributes like uid, gid, sambaNTPassword, and sambaPwdLastSet.\n","description":"LDAP-wrapper is a Node.js LDAP server built on top of (ldapjs) that allows users and groups from Microsoft Entra ID (formerly Azure Active Directory) to be accessed through the LDAP protocol. User authentication is performed using Microsoft Graph API on every login attempt. This allows your other applications to connect to the LDAP server and thus allows your end users to authenticate with a work or school account.\nThis it a possible workaround for older applications that lack Microsoft Entra ID support or for scenarios where managing a local AD controller is undesirable."},{"id":11,"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 your Microsoft Entra 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 Microsoft Entra tenant. 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 TZ=\u0026#34;Europe/Zurich\u0026#34; ` -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 Microsoft Entra 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 your Microsoft Entra 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."},{"id":12,"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":13,"href":"/AzureAD-LDAP-wrapper/tags/","title":"Tags","parent":"LDAP-wrapper for Microsoft Entra ID","content":"","description":""},{"id":14,"href":"/AzureAD-LDAP-wrapper/usage/","title":"Usage examples","parent":"LDAP-wrapper for Microsoft Entra ID","content":" Some examples how to use the LDAP-wrapper. This may also help configure similar services/apps. ","description":" Some examples how to use the LDAP-wrapper. This may also help configure similar services/apps. "},{"id":15,"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 Register an application with the Microsoft identity platform","parent":"Installation","content":" Prerequisites Register an application with the Microsoft identity platform Set permissions Get TenantId, AppId and AppSecret Use TenantId, AppId and AppSecret in your wrapper Prerequisites To register an application with the Microsoft identity platform, you need:\nA Microsoft Entra ID user account. If you don\u0026rsquo;t already have one, you can create an account for free. Register an application with the Microsoft identity platform Register a new application in your Microsoft Entra Admin Center. More descriptions can be found here.\nSign-in to the Microsoft Entra Admin Center. Browse to Identity \u0026gt; Applications \u0026gt; 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 Microsoft 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 Allow public client flows to Yes\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 the Microsoft identity platform Set permissions Get TenantId, AppId and AppSecret Use TenantId, AppId and AppSecret in your wrapper Prerequisites To register an application with the Microsoft identity platform, you need:\nA Microsoft Entra ID user account. If you don\u0026rsquo;t already have one, you can create an account for free. Register an application with the Microsoft identity platform Register a new application in your Microsoft Entra Admin Center."},{"id":1,"href":"/AzureAD-LDAP-wrapper/security/","title":"3. Security","parent":"LDAP-wrapper for Microsoft Entra ID","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 my work account (Microsoft Entra Account) 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 Microsoft Graph API / Entra ID 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 Microsoft Entra ID 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":"LDAP-wrapper for Microsoft Entra ID","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 Microsoft Entra Domain Services Why are personal microsoft accounts not supported? Samba is not working, what can I do? Are deleted users or groups in Entra 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 Microsoft Entra 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 Microsoft Entra Domain Services If you don\u0026rsquo;t need support for older software, the officially Synology solution to join your NAS to a Microsoft Entra Domain Services 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 Microsoft Entra 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 Microsoft Entra (formerly Azure AD joined devices)? 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 Entra also removed from the LDAP entries? Yes, but with a delay. After a user has been deleted in Microsoft Entra, 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/usage/portainer/","title":"6.1 Portainer","parent":"Usage examples","content":"Portainer supports LDAP authentication, allowing users to log in by authenticating against your LDAP directory. This guide outlines the steps to set up LDAP authentication over LDAP-wrapper with Portainer.\nPrerequisites Settings for Portainer LDAP Authentication with LDAP-wrapper LDAP Configuration LDAP Security User Search Configurations Prerequisites Before configuring LDAP authentication for Portainer, ensure the following prerequisites are met:\nLDAP-wrapper: Make sure you have a working LDAP-wrapper. Portainer: Install and set up a working instance of Portainer. Settings for Portainer LDAP Authentication with LDAP-wrapper LDAP Configuration LDAP Server: Specify the IP or name of your NAS with Port 389.\nExample: 192.168.1.2:389 or my-nas-name.local:389 Reader DN: Set it to uid=root, matching an entry of your LDAP-wrapper environment variable LDAP_BINDUSER. Password: Set it to the password corresponding to the entry in your LDAP-wrapper environment variable LDAP_BINDUSER. LDAP Security Ensure that StartTLS, Use TLS, and Skip verification are set to off. User Search Configurations Base DN: Define the base DN as cn=users,dc=domain,dc=tld.\nUsername Attribute: Specify mail.\nFilter: Use the following filter to restrict access:\n(|(\u0026amp;(uid=*)(memberOf=cn=users,cn=groups,dc=domain,dc=tld))(\u0026amp;(cn=administrators))) This filter ensures that only users within the administrators group can log into Portainer.\nDon\u0026rsquo;t forget to save your LDAP-wrapper configuration. Now, users attempting to log into Portainer will be authenticated against your LDAP directory. Only users within the administrators group, as specified in the LDAP filter, will be allowed access to Portainer.\n","description":"Portainer supports LDAP authentication, allowing users to log in by authenticating against your LDAP directory. This guide outlines the steps to set up LDAP authentication over LDAP-wrapper with Portainer.\nPrerequisites Settings for Portainer LDAP Authentication with LDAP-wrapper LDAP Configuration LDAP Security User Search Configurations Prerequisites Before configuring LDAP authentication for Portainer, ensure the following prerequisites are met:\nLDAP-wrapper: Make sure you have a working LDAP-wrapper. Portainer: Install and set up a working instance of Portainer."},{"id":4,"href":"/AzureAD-LDAP-wrapper/usage/authelia/","title":"6.2 Authelia with LDAP-wrapper","parent":"Usage examples","content":"Authelia supports LDAP authentication, enabling users to log in by authenticating against your LDAP directory. This guide outlines the steps to set up LDAP authentication with Authelia using LDAP-wrapper.\nPrerequisites Settings for Authelia LDAP Authentication with LDAP-wrapper Prerequisites Before configuring LDAP authentication for Authelia with LDAP-wrapper, ensure the following prerequisites are met:\nLDAP-wrapper: Ensure you have a functioning LDAP-wrapper. Authelia: Set up and configure Authelia for your environment. Settings for Authelia LDAP Authentication with LDAP-wrapper To configure LDAP authentication with Authelia using LDAP-wrapper, follow these steps:\nOpen your configuration.yml file in the Authelia configuration directory. Locate the authentication_backend section and configure it with the following example, adjusting the url,base_dn, user, and password based on your LDAP-wrapper setup: ## Authentication Backend Provider Configuration authentication_backend: ## Password Reset Options password_reset: ## Disable both the HTML element and the API for reset password functionality. disable: true ## External reset password url for Microsoft custom_url: \u0026#34;https://account.activedirectory.windowsazure.com/ChangePassword.aspx\u0026#34; ## The amount of time to wait before we refresh data from the authentication backend. Uses duration notation ## See the below documentation for more information ## Duration Notation docs: \u0026lt;https://www.authelia.com/c/common#duration-notation-format\u0026gt; ## Refresh Interval docs: \u0026lt;https://www.authelia.com/c/1fa#refresh-interval\u0026gt; refresh_interval: 5m ## ## LDAP (Authentication Provider) ## ldap: ## The LDAP implementation, this affects elements like the attribute utilised for resetting a password. implementation: custom ## The url to the ldap server. Format: \u0026lt;scheme\u0026gt;://\u0026lt;address\u0026gt;[:\u0026lt;port\u0026gt;]. url: ldap://my-nas-name.local:389 ## The dial timeout for LDAP. timeout: 5s ## Use StartTLS with the LDAP connection. start_tls: false tls: ## Server Name for certificate validation (in case it\u0026#39;s not set correctly in the URL). # server_name: ldap.domain.tld ## Skip verifying the server certificate (to allow a self-signed certificate). skip_verify: false ## Minimum TLS version for either Secure LDAP or LDAP StartTLS. minimum_version: TLS1.2 ## The distinguished name of the container searched for objects in the directory information tree. base_dn: dc=domain,dc=tld ## The attribute holding the username of the user. This attribute is used to populate the username in the session username_attribute: uid ## The additional_users_dn is prefixed to base_dn and delimited by a comma when searching for users. additional_users_dn: cn=users ## The users filter used in search queries to find the user profile based on input filled in login form. users_filter: (\u0026amp;(|({username_attribute}={input})({mail_attribute}={input}))(objectClass=person)) ## The additional_groups_dn is prefixed to base_dn and delimited by a comma when searching for groups. additional_groups_dn: cn=groups ## The groups filter used in search queries to find the groups based on relevant authenticated user. groups_filter: (\u0026amp;(member={dn})(objectClass=posixGroup)) ## The attribute holding the name of the group. group_name_attribute: cn ## The attribute holding the mail address of the user. If multiple email addresses are defined for a user, only the mail_attribute: mail ## The attribute holding the display name of the user. This will be used to greet an authenticated user. display_name_attribute: displayName ## Follow referrals returned by the server. ## This is especially useful for environments where read-only servers exist. Only implemented for write operations. permit_referrals: false ## The username and password of the admin user, matching an entry of your LDAP-wrapper environment variable `LDAP_BINDUSER`. user: uid=root ## Password can also be set using a secret: \u0026lt;https://www.authelia.com/c/secrets\u0026gt; password: 1234 Save the changes to your configuration.yml file. Restart Authelia to apply the new configuration. Now, Authelia is configured to authenticate users against your LDAP directory through LDAP-wrapper.\n","description":"Authelia supports LDAP authentication, enabling users to log in by authenticating against your LDAP directory. This guide outlines the steps to set up LDAP authentication with Authelia using LDAP-wrapper.\nPrerequisites Settings for Authelia LDAP Authentication with LDAP-wrapper Prerequisites Before configuring LDAP authentication for Authelia with LDAP-wrapper, ensure the following prerequisites are met:\nLDAP-wrapper: Ensure you have a functioning LDAP-wrapper. Authelia: Set up and configure Authelia for your environment. Settings for Authelia LDAP Authentication with LDAP-wrapper To configure LDAP authentication with Authelia using LDAP-wrapper, follow these steps:"},{"id":5,"href":"/AzureAD-LDAP-wrapper/usage/synology-radius-unifi/","title":"6.3 Synology Radius with UniFi","parent":"Usage examples","content":"UniFi allows you to use a custom Radius server like the default package from Synology. Combined with the LDAP-wrapper, this creates a powerful setup for your users.\nDSM 7.2.1-69057 Update 3\nLDAP-wrapper v2.0.2\nRADIUS Server Package 3.0.25-0515\nUniFi Network Application 8.0.24 Prerequisites Settings in Synology RADIUS Server Settings in UniFi Controller Prerequisites Before configuring Synology Radius and UniFi, ensure the following prerequisites are met:\nSynology NAS: Ensure you are up to date with your DSM, and install the current RADIUS Server package. LDAP-wrapper: Ensure you have a functioning LDAP-wrapper. UniFi AP: Ensure you are up to date and have access to your controller settings. Settings in Synology RADIUS Server Open the RADIUS Server package on your Synology NAS.\nConfigure the RADIUS Common Settings with the following parameters:\nAuthentication port: Set the RADIUS Server\u0026rsquo;s port number for interface protocols. The default value is 1812 for authentication. Select network interface: Choose the network interfaces connected to RADIUS client devices (e.g., a router). RADIUS Server provides authentication services only for access requests coming from the specified interface. TLS/SSL profile level: Choose \u0026ldquo;Intermediate compatibility,\u0026rdquo; which is the default setting. This option is recommended because it is compatible with general-purpose browsers but is not compatible with insecure cipher suites. Source for user authentication: Enable LDAP users. Check your certificates.\nRADIUS Server requires a valid certificate. Configure the RADIUS Clients by adding clients based on the IP address range.\nEach UniFi AP will directly contact your Synology RADIUS Server. Ensure that your firewall allows all those APs to connect to your NAS with the previously defined port (e.g., 1812). To set up clients by IP address range:\nClick Add and choose Subnet, then enter the following information:\nName: Enter a display name for the collection of clients, making it easier to identify. IP address: Enter the base IP addresses of the RADIUS clients (e.g., 192.168.10.1). Subnet mask: Enter a subnet mask, for example, 255.255.255.0. Shared secret: Enter a text string used as a password between the clients and RADIUS Server. This secret will also be needed in your UniFi configuration. Settings in UniFi Controller Log in to your UniFi controller.\nNavigate to Settings \u0026gt; Profiles \u0026gt; RADIUS and create a new entry.\nEnable Wired Networks. Enable Wireless Networks. Enter the IP address of your Synology NAS in the IP Address field. Specify the RADIUS authentication port (typically 1812) in the Port field. Enter the same shared secret configured in the Synology RADIUS Server in the Shared Secret field. Disable Accounting. Navigate to the Wireless Networks section (Settings \u0026gt; WiFi) and edit your network.\nEdit the Wireless Network where you want to enable RADIUS authentication.\nEnable WPA Enterprise. Select the previously added RADIUS Profile. Save the settings and apply the changes to your UniFi network.\nNow, UniFi is configured to use the Synology RADIUS Server for authentication. Users authenticated through UniFi will be verified against your LDAP directory using LDAP-wrapper, creating a robust and secure setup.\n","description":"UniFi allows you to use a custom Radius server like the default package from Synology. Combined with the LDAP-wrapper, this creates a powerful setup for your users.\nDSM 7.2.1-69057 Update 3\nLDAP-wrapper v2.0.2\nRADIUS Server Package 3.0.25-0515\nUniFi Network Application 8.0.24 Prerequisites Settings in Synology RADIUS Server Settings in UniFi Controller Prerequisites Before configuring Synology Radius and UniFi, ensure the following prerequisites are met:\nSynology NAS: Ensure you are up to date with your DSM, and install the current RADIUS Server package."},{"id":6,"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 your tenant (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 Microsoft Entra ID 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 Microsoft Entra ID 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 Microsoft Entra ID 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 your tenant (preferred).\nThere are several ways to define MFA, but only some of them allows you to disable MFA."},{"id":7,"href":"/AzureAD-LDAP-wrapper/configuration/","title":"Configuration","parent":"LDAP-wrapper for Microsoft Entra ID","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":8,"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":9,"href":"/AzureAD-LDAP-wrapper/installation/","title":"Installation","parent":"LDAP-wrapper for Microsoft Entra ID","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":10,"href":"/AzureAD-LDAP-wrapper/","title":"LDAP-wrapper for Microsoft Entra ID","parent":"","content":"LDAP-wrapper is a Node.js LDAP server built on top of (ldapjs) that allows users and groups from Microsoft Entra ID (formerly Azure Active Directory) to be accessed through the LDAP protocol. User authentication is performed using Microsoft Graph API on every login attempt. This allows your other applications to connect to the LDAP server and thus allows your end users to authenticate with a work or school account.\nThis it a possible workaround for older applications that lack Microsoft Entra ID 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 work accounts. 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 Microsoft Entra Domain Services (formerly AADDS / Azure Active Directory Domain Services), just to allow my three users to use their credentials almost everywhere. How the server works sequenceDiagram\rautonumber\rparticipant LDAP client\rparticipant LDAP-wrapper\rparticipant ME-ID (Graph API)\rNote over LDAP-wrapper: start LDAP server\rLDAP-wrapper-\u0026gt;\u0026gt;ME-ID (Graph API): Fetch users and groups\rNote over LDAP-wrapper: cache users and groups locally\rLDAP client-\u0026gt;\u0026gt;\u0026#43;LDAP-wrapper: Attempt to bind with user credentials\rLDAP-wrapper-\u0026gt;\u0026gt;\u0026#43;ME-ID (Graph API): Check user credentials\rME-ID (Graph API)--\u0026gt;\u0026gt;-LDAP-wrapper: Valid credentials\rNote over LDAP-wrapper: save password hash locally in the cache\rLDAP-wrapper-\u0026gt;\u0026gt;-LDAP client: Successful bind/authenticate\rloop every 30 minutes\rLDAP-wrapper-\u0026gt;\u0026gt;ME-ID (Graph API): Fetch users and groups again\rNote over LDAP-wrapper: merge and cache users and groups locally\rend The LDAP-wrapper starts an LDAP server and fetches users and groups from the Microsoft Graph API. These are cached and merged locally.\nWhen an LDAP client attempts to bind with user credentials, the LDAP-wrapper checks these credentials by communicating with the Microsoft Graph API. If the credentials are valid, the Microsoft Graph API sends a success response to the LDAP-wrapper, which then sends a successful bind message to the user\u0026rsquo;s LDAP client. Additionally, the 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 LDAP-wrapper periodically fetches user and group information from the Microsoft Graph API every 30 minutes, merging and caching the results locally. This process preserves attributes like uid, gid, sambaNTPassword, and sambaPwdLastSet.\n","description":"LDAP-wrapper is a Node.js LDAP server built on top of (ldapjs) that allows users and groups from Microsoft Entra ID (formerly Azure Active Directory) to be accessed through the LDAP protocol. User authentication is performed using Microsoft Graph API on every login attempt. This allows your other applications to connect to the LDAP server and thus allows your end users to authenticate with a work or school account.\nThis it a possible workaround for older applications that lack Microsoft Entra ID support or for scenarios where managing a local AD controller is undesirable."},{"id":11,"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 your Microsoft Entra 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 Microsoft Entra tenant. 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 TZ=\u0026#34;Europe/Zurich\u0026#34; ` -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 Microsoft Entra 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 your Microsoft Entra 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."},{"id":12,"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) LDAP_USERS_SYNCONLYINGROUP LDAP_USERS_SETDEFAULTGROUP 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.\nLDAP_USERS_SYNCONLYINGROUP When set, only users within the specified groups are fetched and made available in the wrapper. Multiple group names can be specified using the pipe character (|). The variable can be used in conjunction with LDAP_USERS_SETDEFAULTGROUP.\nLDAP_USERS_SETDEFAULTGROUP When set, the first specified group associated with the user will be used as the default group. Multiple group names can be specified using the pipe character (|). For example, admins|finance|hr. If a user is within both groups (finance and hr), the default group will be set to finance because it was defined first. With DSM 7, there are some issues regarding group permissions. ACL and UID/GID shifting can help. However, when losing the permissions, there seems to be some sort of fallback to the default group. With this setting, you can adjust the default group for your users.\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) LDAP_USERS_SYNCONLYINGROUP LDAP_USERS_SETDEFAULTGROUP 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":13,"href":"/AzureAD-LDAP-wrapper/tags/","title":"Tags","parent":"LDAP-wrapper for Microsoft Entra ID","content":"","description":""},{"id":14,"href":"/AzureAD-LDAP-wrapper/usage/","title":"Usage examples","parent":"LDAP-wrapper for Microsoft Entra ID","content":" Some examples how to use the LDAP-wrapper. This may also help configure similar services/apps. ","description":" Some examples how to use the LDAP-wrapper. This may also help configure similar services/apps. "},{"id":15,"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. To prevent potential problems with permissions in Samba, it\u0026rsquo;s recommended to enable UID/GID shifting. Refer to issue #47 for more details. 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 bc0c1f7..1299012 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -39,7 +39,7 @@
     <lastmod>2024-01-11T15:18:30+01:00</lastmod>
   </url><url>
     <loc>https://ahaenggli.github.io/AzureAD-LDAP-wrapper/configuration/settings/</loc>
-    <lastmod>2023-07-17T10:26:34+02:00</lastmod>
+    <lastmod>2024-02-04T15:07:20+01:00</lastmod>
   </url><url>
     <loc>https://ahaenggli.github.io/AzureAD-LDAP-wrapper/tags/</loc>
   </url><url>