Best practices for moving NACL migration between vaults and domains

Hi community and M-Files, 

As we have multiple environments (dev, test, prod to name the standard ones), I am wondering about the best practice for moving/deploying configuration between those environments (especially NACLs). In our NACLs, we often have beside pseudo user security (metadata-driven security) also user groups (imported through AD). As we have different networks, those AD groups do have same names but obviously different domains. So for example on DEV, we have DEV\group1 and production we have PROD\group1.

We have currently developed everything on one network but now need to deploy it on other domains/networks. So my question or discussion point: what is the best practice to move vault configuration between different domains/networks, especially NACLs containing user groups, classes and views protected with user groups (different domains on different environments)?

I have looked into exported values and could found how configuration of NACLs is built up (every NACL as unique identifier). One naïve approach would be to just replace domains with proper domains of deployment environment. On the other side, I see as well that it references user groups about unique ID that is probably generated when AD groups are first imported into M-Files. As we plan to import and sync AD groups manually on all environments and not move them through exporting function (those are different AD groups on different environments), they would get different unique IDs etc. So that would mean that I would need to update those unique references as well in exported config. This all seems very complicated and error prone. 

Do you have an approach and experience with such a use case?

Thanks for great input.


  • Hi again, 

    I suppose that this is very hard topic and hard to explain. Here is an example and some notes I have, hopefully explain our demand better.

    On the one side, we have group definition (as mentioned above we could update groups to have same names but they are on different domains):

    <group aliases="<ALIAS>" deleted="false" externalname="<EXT. NAME>" full="true" id="105" name="<NAME>" ...>
            <user id="55" name="<SOME USER>" />
           <cached id="aclcache-11-1" />
        <external externalgroupimportmode="DirectAndNestedUsers" licensetypefornewaccounts="NamedUser" membershipsync="false" ...>
           <externalname><EXT. NAME></externalname>
           <organizationalunit><OUR ORG UNIT></organizationalunit>

    (Sorry attachment and code editor have not worked well both)

    On the other side, we use those groups in some NACLs references (M-Files seems to do it over ID instead alias):

    So our ideas are:

    Idea 1: Take configuration of groups into separate domain. Create custom mapping to replace Organization Unit. So we would take configuration of groups as well just map it to other Org Unit from AD. Question is would this way AD groups be imported.

    Idea 2: Import first other groups from other environment, name them the same. Import afterwards NACLs. Would this map accordingly? Imported groups would get other IDs. It seems M-Files maps here based on IDs and aliases.

    Either way I think about seems not to be the best case. I would really like to prevent that we need to re-create NACLs manually!

    Thanks for any thoughts and ideas.


  • Hi dejan,

    Could you create M-Files internal user groups (not AD synchronized) and use these to define NACLs? These user groups should have aliases. On deployment you replicate these user groups to each environment. As an enviroment specific configuration you include appropriate AD synchronized group as a subgroup to aliased groups.

  • Hi Henri, 

    I understand. So it would means, I need than manually add correct groups into those internal user groups.

    I am wondering if I import those groups with *not existing* AD groups into M-Files how it would react. Because in definition of the user group, there is always a link to external AD group. Wondering if I could take that config with me. Unfortunately, I have on other vaults already AD imported groups, so it means I would need to change the whole setup first there to try it out. The concept is good as it provides level of abstraction but still we have external link to external group. That part worries me.