Section Access using NTNAME & NTDOMAINSID, for Active Directory local group having members coming from multiple domains

[evan_kurowski]

Hello Qlik community,

Is it possible to authenticate the following with section access?

Scenario is an AD local group, in the domain 'NAM', containing members from multiple domain.

The group name is 'NAM\QLIK_USERS', and the members are: 

• NAM\JONES12
• LATAM\SMITH34
• EMEA\GRIMES83

The following will work for members of the group having an account in the same domain the group resides (because the accounts in NAM & groups in NAM share the same NTDOMAINSID), but members from other domains appear to be getting rejected based on the NTDOMAINSID criteria (because even though they are members of a group in NAM, it appears they can't temporarily borrow the NTDOMAINSID of the group they belong to).

  Section Access;
LOAD * INLINE [
ACCESS, NTNAME, NTDOMAINSID
USER, NAM\QLIK_USERS, S-1-5-21-90210-8675309
];

Is there a way to restructure this, or add entries so all members of the group from all domains will be authenticated both via NTNAME & NTDOMAINSID? (but not by creating additional groups)

Thanks, appreciate any guidance on this. ~E

[Miguel_Angel_Baeyens]

You could add as many lines for the group as different domains it contains.

I personally don't use the ID fields in section access anymore (especially since deploying in cloud instances) but NTNAME only.

[evan_kurowski · Accepted solution]

Hello Miguel,  

I agree, life would be simpler with just AD names, but there are public proclamations that declare solely named based identifiers aren’t the most strident.  (even instances of people who advertise services to “crack or spoof” NT identifiers solely name based. See: LinkedIn.)


Part of this might stem from possibility of gleaning name based identifiers from clear-text areas of partially encrypted files (such as XML portions of .qvw).  Or maybe simple social engineering such as screen-share, log file, or blog post reveals details. With NTDOMAINSID difficulty increases.

Testing combinations now and so far the first results were positive.

If the users originated from domains having the following NTDOMAINSID

• NAM                 S-1-5-21-90210-8675309
• LATAM    S-1-5-21-88888
• EMEA               S-1-5-21-33333
  
   

Adding the following additional rows to section access have so far granted access to accounts not originating from the same domain as the containing group.

//the multiple ntdomainsid cover all possible domain contributing members to the domain local group
Section Access;
LOAD * INLINE [
ACCESS, NTNAME, NTDOMAINSID
USER, NAM\QLIK_USERS, S-1-5-21-90210-8675309
USER, NAM\QLIK_USERS, S-1-5-21-88888
USER, NAM\QLIK_USERS, S-1-5-21-33333
];

[Miguel_Angel_Baeyens]

Good to know that it works. Somehow, it makes sense.

Yes, I have read our good ol' Vlad about security and section access. But I have had tough experiences (read: being locked out) with changing domain IDs due to reconstruction of instances (most recently due to the several waves of patches for Spectre and Meltdown). At least in our case, since users do not have physical access to the QVW file, not even an active directory user, I have considered it enough to avoid any snoops. I know one can never be safe enough but there must be also a line. (Else I'd be using NTSID as well, and still!).

[evan_kurowski]

Having more positive results for initial rounds of testing.

Clients are drawn to the potential of simplified group administration with poly-domain local groups, but difficulty connecting the section access has caused some to either expand the volume of AD groups involved (creating groups per domain), reduce stridency of section access (dropping SID authentication fields and going with names only), or skipping groups entirely and reverting to account level approach (resulting in a lot more section access entries, but easier to understand and verify).

Agree with potential for NTDOMAINSID lockout in smaller implementations (i.e. a single device or small-business). At enterprise scale it is reasonable to expect domainsid consistency, and also offer alternate domains for "backup" recovery (lockout only if enterprise changed every domainsid at once).

Didn't set out to answer own thread, but if technique outlined continues to hold up and no one else pops in with "No, no, no!  Here's how you do it!" then after a pause will mark this answered.

[maksim_senin]

Hi Evan,

One more point - when using AD groups it's necessary to create global security groups since local security group does not work in case of Section Access. At least this is true for WinServ 2012 and QV 11.2.

[evan_kurowski]

One more point - when using AD groups it's necessary to create global security groups since local security group does not work in case of Section Access. At least this is true for WinServ 2012 and QV 11.2.

Hello Maxim,

I appreciate your response, but I'm going to push back on that assertion and request perhaps some research or documentation.

The reason I'm saying is because I'm my 3rd major Qlik 11.2 implementation/architecture where we implemented Section Access via domain local groups, and it has been operational for us in all instances.

First, let's emphasize for readers learning about the Active Directory (AD), groups scope is the paramount concept to understand, not all groups scopes are created equal.

AD groups come in flavors: Machine Local, Domain Local, Global, Universal

I always found this page to have a good description of the group scopes, and the matrix of capabilities was useful: https://ss64.com/nt/syntax-groups.html

It appears to me that there was a mixup in nomenclature (as sometimes happens with Windows), the capabilities of the Global group and the Domain Local group have misnomers.  (mixed up in kind of the way the ODBC32 bit administrator is in folder SysWOW64, and the ODBC64 bit administrator is in System32)

'Global' groups can only accept members from a single domain.  So if you want a group that can conveniently contain your users from NORTHAMERICA and LATAM, you can't use a global group to fulfill a poly-domain user base.  (it behaves almost ANTI globally.  the term 'global' here describes the groups's organizational INTENTIONS, rather than its actual capabilities).

'Domain Local' groups CAN accept members from multiple domains, so there doesn't seem to be anything local at all about these groups, and being able to add users across multiple domains make them probably the most convenient type to use for section access. (and you can even nest groups within groups.  More flexibility)

#A quick way to check on what type you're working with?  

# try the net command in a prompt

#if this works you have a global group

net group /domain theAdgroupname

#if this works you're dealing with a domain local group

net localgroup /domain theAdgroupname

Not everyone's experience is the same, but when we implement Section Access via domain local groups, we test users from at least 2 possible domain both for access & denial.

All permitted users are members of Domain Local group NORTHAM\MUHGROOVYGROUP, while all denied users have a Qlik CAL, but no group membership.

• · NORTHAM\USER1 = permitted
• · NORTHAM\USER2 = denied
• · LATAM\USER3 = permitted
• · LATAM\USER4 = denied

The second part that confirms this is during these implementations we've opened several tickets with Qlik support regarding the same, and they've never questioned or challenged the technique.

What can sometimes create the PERCEPTION there are issues, is when there isn't a solid grasp of the nuances between 'Global' vs. 'Domain Local', and the designer gets frustrated because the 'Global' group is doing opposite of what they expected.

The other situation was when drawing using across multiple domain, the Directory Services Connector on the QMC Setup needs a configuration entry per-contributing domain.  Sometimes the default just covers an entry for the hosting domain and leaves it at that, you have to remember to go in and add an LDAP entry for other domains.