This has been a problem since the beginning. WFA may address this in future. But till then we need to find a way to work it out. wory not, I have solution which fits exactly into your requirement.
I have a workflow that when executed pulls out all the Users in the AD Group that is mentioned as "WFA operators groups" and create users with in WFA. Now you can assign Categories to those Operator users. You don't need to wait for them to login into WFA.
When the operators login using their respective AD credentials, they will get access to the right WFA categories. All problems resolved.
But there is a bad news that I'm not able to find the workflow right now 
, Not sure where I kept the dar.
I'll search for it and try to post it by tomorrow. Wait for my post.
sinhaa
Hi lopaka,
I couldn't find my old dar file. So I made a new solution and I think I've done it better than what I had last time.
Let's see how it works.
Assigning Category access for Active Directory "WFA Operators Groups" is not available in WFA. Its only the individual operator users that can be done. And another problem that domain users in WFA are only created when they login. This is a problem that the Admin needs to wait for operators users to login into WFA.
This solution I'm providing is a workflow. A workflow which when executed will pull out all Users in the WFA Operators Groups for every LDAP server mentioned and get them into WFA as operators. Now you can assign Categories to them as you wish. You need not wait for them to login into WFA before assigning categories to them.
When the operators login using their respective Domain credentials, they will get access to categories just as you wanted them to be.
Prerequisites:
- You need Powershell 3.0 or above on your WFA server. Windows2012 by default has this.
- Have the WFA Configurations defined for LDAP and Wfa Operators Users groups decided as you wish.
- Add credentials of a WFA ‘Admin’ user for ‘localhosthost’
Match: Exact
Type: Other
Name/IP: localhost
Username: <WFA Admin Username>
Password: <User Password>
4. Add credentials for the Active Directory server. We need it to query the AD server for users in groups.
Match: Exact
Type: Other
Name/IP: <Active Directory Server IP>
Username: <Username>
Password: <Password>
Now just import the attached WFA2_2_sinhaa__Workflow_Get_WFA_Ldap_Operator_Users.dar into your WFA server and Execute the workflow. It needs NO user inputs, just execute it.
Have fun.
sinhaa
Hi Joel,
@JoelEdstrom while it did add all the usernames in, it didn't add them with the domain\ prefix
----
I don't think you need this Domain\Username format for domain users login to WFA. Using just the Username completely works. However if you do login into WFA using Domain\Username, that too works but the thing is in MS Active Director there is no such attribute of a domain user which I can obtain.
Also this Domain\Username is the old NT login mechanism. Why don't you use the new username@domain login format. WFA totally supports it. All you need to do is
WFA->Configuration->Authentication
change the user name Attribute from sAMAccountName to userPrincipalName . That's All!!
As the image below.
@JoelEdstrom . Is there any way to have these users created as LDAP users instead by any chance?
-------
Did you notice that when you are creating a new user, WFA doesn't ask you if this is going to be a domain user or local user? All users in WFA by default are created local. As soon as the same user i.e. with same username succeeds login using the Domain authentication, the same same users get modified to domain users i.e. column "is ldap" will become true for them.
Every login attempt in WFA is first looked for local authentication, if local fail and LDAP is enabled the the same login is attempted using the Domains provided for domain authentication. If local fails but the domain succeeds, then the WFA user is allowed access and he/she is marked as a Doamin user i.e. column "is ldap" becomes true for him.
This is the very magic-logic behind the solution I provided 
. I get all the Domain users in from the Groups as mentioned in Your WFA LDAP configurations. I created local users with them. Now when real domain users actually attempt login into WFA, their local authentication will fail, it has to. But their Domain authentication will pass (assuming they give right username/password etc.). This upgrades the user to LDAP user. Now this will allow the user the access into WFA with the correct roles and category access as assigned by the Admin.
sinhaa
Richard ... I think there is an easier way to mask the builtin workflows from operators. In the 4.1 verson of WFA, under Administration -> WFA Configuration -> Advanced tab, uncheck packs which hold all the built-in workflows you don't want them seeing (probably all of them).
WFA starts out assuming you want to see all the builtins in the portal but when you go into production I think everyone would want to hide the provided examples. If WFA 4.x, the examples are formally part of Packs hence the ability to pick which packs you want to present or not.
In earlier versions of WFA a similar function was under the Other tab and called 'Show example workflows in portal',
Ok. I noticed that the "Show example workflows" was removed in later versions. Thanks for pointing this out 
- Products and Services
- General Discussion & Community Support
- Developer Network
- NetApp Learning Services
- Blogs
- Tech ONTAP Newsletter
