Open Enterprise Server Documentation

[Trisha Quercioli]

Ifan answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it! Learn more

I'm looking for some practical advice w/r to NSS for AD. I don't see a whole lot on here about it, which has me a little concerned about using it. That said, I have a site that has been using OES w/ CIFS enabled for a quite a while. They have a need now for Folder Redirection and to do that, I have got to implement NSS for AD.

All the file servers are standalone OES 2018 SP2 VMs with local NSS volumes, fully patched up. There is no clustering and no DSfW. DFS and DST are NOT used. Storage Manager is used to provision home directories and Filr is used as well (Filr is using NCP to reach the volumes).

Identity Manager is in use as well and all the users are provisioned from a traditional identity vault into BOTH an Active Directory domain and the eDirectory tree in which the OES servers live. Passwords are sync'd bi-directionally with both child directories. The user's eDir CN matches the sAMAccountName in AD (that value is used for the user portion of the RDN and UPN as well).

From the looks of it, implementing NSS for AD doesn't look too bad. We already use AD here for DNS and everything resolves in both directions. Right now, the DirXML-ADContext attribute is populated but only lives in the vault, but I can easily push that down to the OES tree so NURM can use it to map users.

So my question is, is that the best approach? Using NURM and DirXML-ADContext to map users? This tree serves no other purpose than holding OES servers, so I'm wondering if I even need to continue to sync users into it? Should I just eliminate the eDir side or is there value in keeping the "mapped" users around?

It's also not clear to me how this gets updated on an ongoing basis. The IdM system is real-time event driven. As new users are added, will I have to have someone constantly running NURM? or will this mapping happen dynamically?

The rights command and NFARM tool can be used to manage rights and quota for AD users. The NURM tool can be used to map rights of eDir identities to their AD equivalent identities (user map has an option to configure matching attributes on both directories or leverage existing IDM-based user maps). The scheduled refresh can be used to refresh the user maps periodically.

Continued syncing to eDir required if you have users accessing NSS AD volumes through the client for OES. Please refer to this part of the documentation for additional details: -enterprise-server-2018/stor_nss_ad_lx/data/b1h322dq.html

"If you have NetIQ IDM 4.5 or later, and you have created an Active Directory to eDirectory user map using IDM Designer (not the IDM iManager plug-in), the User Resource Map utility (NURM) can leverage the map for replicating NSS ACLS for eDirectory users and groups to NSS ACLs for corresponding AD users and groups."

I have no idea what is meant by "an Active Directory to eDirectory user map". To me as an IdM developer that sounds like some sort of static map. I am assuming they mean if you are matching up AD and eDir users. There is no "map" to leverage. What I think it is doing is just reading the DirXML-ADContext. As long as IdM is populating that and it is correct NURM will use it. But to me, this has absolutely nothing to do directly with IdM. Maybe someone can confirm that?

Just to be clear, the SOLE reason I'm looking at implementing NSS for AD is to get Folder Redirection support. This site has run CIFS for years and has been slowly moving away from NCP access via the Micro Focus client. That said we still have MF client usage, so in the short run, I would continue to sync using IdM. However, if someday all the NCP access is gone, I would entertain NOT creating users in eDir for this purpose any longer.

The Filr support for NSS AD volume depends on the Server Type configuration in Net Folder Server. Only if the server type matches NSS for AD, then, Filr can recognise the rights set for AD identities on NSS AD volumes.

When you move to AD-only world, then, you should re configure your Filr deployment to create Net Folder Server with NSS for AD as the server type so that Filr recognise rights set for AD identities on NSS AD volumes.

Daily refresh is not gong to be sufficient as the IdM system creates users immediately via a feed from the ERP system. This would result in up to a 24 hour delay before a user could use their file shares.

For those folks familiar with IdM, the documentation is confusing and misleading. It's really quite simple. If DirXML-ADContext is populated, which it is if you use the default AD Driver IdM packages, then NURM basically has an automatic user mapping option that will use that to map users to AD. That's it, there is no other magic here. As a matter a fact, this really has nothing to do with IdM. You could populate DirXML-ADContext through ANY means, pick the NetIQ IdM option, and it will use it. The docs should be clarified to indicate that because you may have folks with old AD drivers and are populating it but may not be using the default packages. I actually tested this too by manually populating DirXML-ADContext.

If you go with the "IdM" option, then you do NOT need a User Map at all. All you need to do is create a Rights Mapping and pick the IdM option. Once the sync completes, you should be good to go, and that is what I experienced.

What I failed to consider though are Group based rights and Container based rights. This customer does not sync groups (we use entitlements from the identity vault), so there is no consistency to the groups between the OES eDir tree and the AD directory. So I have no good way to map group rights. Not sure what to do about this. Right now I'm manually granting AD groups rights in places the eDir group was used to grant rights. This is not a good long term solution since that means managing group rights in TWO locations. I'm toying with creating a separate "mapped" group container in both trees and using a User Map for just the groups.

Container based rights are a whole other problem. You can't use a container for assigning rights in AD, so here you have to come up with something else. You can map an eDir container to an AD group. For now I just manually assigned some AD groups rights to compensate for the missing container rights.

All eDir inherited rights stop working too. So for the admins that were getting rights through eDir assignments on the server objects, that all stops working once your turn on NSS for AD. So that means adding more explicit user or group rights (those are your only options as far as I can tell).

I'm very worried about the scalability of the Rights Mapping. This environment has nearly 40,000 users and several of the volumes have 10,000 - 15,000 trustee assignments. The Rights Mapping takes around 25 minutes to run on EACH of these volumes. If I run this daily, I could be looking at several hours of this running.

All that said, it is pretty neat to see rights being assigned directly to AD objects. I installed NFARM and tested that and it worked well and I also used the rights command via SSH. One thing that makes no sense is why the rights command uses the legacy AD sAMAccountName as the trustee. It should be using the UPN. sAMAccountName is deprecated and in some cases can be randomly generated. The rights command should be updated to leverage the UPN for the trustee, NOT the legacy sAMAccountName.

I do have one more question, I am thinking about setting up a cron job to run user-rights-map more frequently than once per day. What are the minimum eDirectory rights needed to update the user-rights-map?

If you have a SR opened with support you can get the supportconfig analyzed by running supportconfig -ur $srnum; where $srnum is your 11 digit service request number. A html report will be given which will list Critical, Warning, and Recommended messages. Some will have TIDs and/or videos to apply to fix the issue. Some will list a rpm to apply.

Edit the /opt/dsfwdude/conf/dsfwmon.conf to send an e-mail if a service has to be restarted. Do not adjust the delay time less than 5 minutes. The script could possibly step on itself, trying to check the services while restarting the services.

I like to use the command line to register my servers. It is easy and relatively fast compared to the GUI. Even easier is to use a script. Just copy the script to the server, modify the e-mail account and registration codes and run the script. If something happens to the update services and repositories just run the script to clean up the old and re-register.

This video will go over a script that can be used populate displayName with the value used in samAccountName. It will also show you how to modify the script if the value from another attribute is desired to be used for displayName.

As far as Domain Services for Windows goes, the install will now allow you to choose between a simplified install or the standard. The simplified install of DSfW reduces the number of screen, removing many of the screens that most people click next on with out any changes too. The install is also more intuitive. If follows along with the type of DSfW install you are doing instead of starting with the eDirectory configuration.

This pattern introduces a scalable architecture for mainframe applications using Micro Focus Enterprise Server in Scale-Out Performance and Availability Cluster (PAC) and an Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling group on Amazon Web Services (AWS). The solution is fully automated with AWS Systems Manager and Amazon EC2 Auto Scaling lifecycle hooks. By using this pattern, you can set up your mainframe online and batch applications to achieve high resiliency by automatically scaling in and out based on your capacity demands.

3a8082e126