AD Group in SA

[cbushey1]

Hi there,

I am trying to configure our Section Access to use AD groups and I have a couple of questions as I am unable to get this to work.

1. Does it matter what type of AD group (Local, Global, Universal)?

2. What is the proper way to specify it in the script? 

3. Do I need to specify the domain? It is the same domain as everything else.

Assuming the name of my AD group is qlik_developers, and it is created within the business unit of Application...

LOAD * INLINE [

ACCESS, NTNAME, ROLE

ADMIN, QLIK_DEVELOPERS, ROLE1

];

Thanks in advance!

[Brett_Bleess]

Correct, if you have cross-domains in play, if the trust relationships are not correct, or you are putting security groups from one domain into a different domain, that is likely going to be problematic.  The best practice in this case is going to be to create the groups within the domain in which the users belong... If you have users from different domains, I would try a specific group in each domain in which to put those users that belong to that specific domain and see if that gets things working...

Regards,
Brett

[cbushey1]

@Brett_Bleess - sorry for the delay here but I am hoping you can still help out.

My security group (qlik_developers) has multiple DC values so I am not sure if I need to list them all or what. Here is what I see when I look in AD at my new group:

CN=qlik_developers,OU=QlikApp,DC=USA,DC=HRT,DC=local

I have tried entering the following in the SA code but I cant even see it in AP after assigning the qlik_developers account a license.

ACCESS, NTNAME

USER,USA\QLIK_DEVELOPERS

Thoughts?

[cbushey1]

@atoz1158  Since you were able to get this working, what are your thoughts here?

[atoz1158]

Hi

What we have is a single top level domain with a number of trusted sub-domains. Qlikview runs in the top level domain and therefore any usernames in the sub-domains are found, clearly our infrastructure teams have set things up correctly and it makes it easy for the likes of myself to administer section access in Qlikview.

Regards

Adrian

[cbushey1]

Thanks Adrian,

We too have top-level and sub-domains, however we set up our qlik instance in a sub domain. Within that same sub domain, I have created the security group. There is no trust between top-level and sub-domain for security issues but that shouldn't come into play since everything is being handled in the sub-domain. Not sure though why this wont work. 

[cbushey1]

I was able to do more testing today and from what I can see the document is not appearing in Access Point for members of the Qlik Developers group as the document is set to filter AP based on section access. If I un-check this, I can see the document but then I am prompted to enter login details and it never lets me in. 

I have also tested renaming the group to all caps, as well as removing the "_" in the name. Neither helped. 

I have tried to assign both users of the group as well as the individual users to the Authorization tab (and Doc Cal) of the document and neither worked.

If I just list the user account in the Section Access and assign that user to the Auth and Doc Cal tabs, it works fine but defeats the purpose of a security group.

Could it be DSC connector is not reading the AD correctly for groups? We use the Configurable LDAP line with the following settings (which is the default except for the label):

@atoz1158 @Brett_Bleess 

[Brett_Bleess]

I see you are using a Configurable LDAP DSP, my best hunch given that would be something is not configured correctly there to get the group memberships back, so I would be sure that is working properly for starters.  I would also recommend reviewing the Help and Design Blog posts I gave you too in order to ensure you have not missed something there too.  The only other thing I have is to comment out the Section Access: line in the script such that the table will load as a normal table into the data model which will allow you to then use list box(es) to place those fields in a sheet to see how the data model responds when you select a group etc., as if everything is greyed out, that would indicated there is no connection between the group and the data model, which would explain why the app is not appearing, as strict exclusion is designed such that if any reduction field etc. results in no records, the user will not be allowed to open the application in that case...  Best I have, you are likely best off getting in touch with your account manager otherwise to arrange for a consultant to take a look at things with you to assist you in getting it sorted out, as I am assuming you cannot attach the application?  I would ensure the Configurable LDAP setup is based upon the subdomain too, that is going to be far more efficient than having it hitting the top level and having to scan down to the sub...  If you are using Active Directory as the directory, I would also recommend using the Active Directory DSP rather than the Configurable LDAP DSP.

Regards,
Brett

[cbushey1]

@Brett_Bleess - Thanks for the suggestions, let me address each one below. 

1. Configurable LDAP - The problem is that I don't know what fields I need to include. I used the default settings except for the label. If you have suggestions or can point to a resource for what to include that would be helpful.
2. Review the links - I did this when you first posted them. I dont see anything in there that points to anything I needed to change.
3. Comment out Section  Access - I know this is a good way to troubleshoot but my app is a very simple example (will attach app) and it works just fine for the other accounts listed in the section access, just not the group.
4. Consultant - I really hate hearing this option. Many of my support tickets end with that suggestion as well and it isnt too useful. I get it if I am trying to do something complex but you will see from the sample app just how simple this is. Also, I had a support tech help configure the ldap as we were having an issue several months back.
5. Subdomain - The DSC is configured to use the subdomain and all QV components are in the same sub domain.
6. AD vs Configurable LDAP - I could try switching the DSC to AD and see if that helps.