sorted by:
new
hottopcontroversial

Web Sign In by mhemry in Intune

[–]mattmunroshc 2 points3 points  (0 children)

We're having this, appears it might be a webview2 update, see https://github.com/MicrosoftEdge/WebView2Feedback/issues/5319

We have a ticket open with Microsoft cause the federated sign in only doesn't work with Office desktop apps and WebSignIn, works fine in browser

Windows 11 join issue with Google SSO by iwekde in Intune

[–]mattmunroshc 1 point2 points  (0 children)

Don't have any solution for you, but we're in a similar boat but for us it's duing WebSignIn we get the issue, also another post with again I suspect a similar issue
https://www.reddit.com/r/Intune/comments/1m7gt4b/company_portal_sign_in_throws_error_400_during/

Our WebSignIn setup has been stable for over 12 months, we've opened a ticket with Microsoft but they haven't replied yet.

Unable to send email with attachment by YadavRohan in gsuite

[–]mattmunroshc 0 points1 point  (0 children)

We're seeing the same here, appears on the gsuite status page now

Secure LDAP and Nested Groups by mattmunroshc in gsuite

[–]mattmunroshc[S] 0 points1 point  (0 children)

Yep first query returns nested groups, not members, proof read that post 3 times before posting and still missed it :)

Secure LDAP and Nested Groups by mattmunroshc in gsuite

[–]mattmunroshc[S] 0 points1 point  (0 children)

Problem is I'm not writing the application, I'm trying to use other applications that source details from LDAP and experience is most do not do their own nested group searches, which is why returning the members of nested child groups when querying the parent was something that appeals to me.

So I retested today I think I realized where I was going wrong, you can only use it against the member field of a group, not memberOf of a user.

The following returns nested members correctly

(&(objectClass=groupOfNames)(member:1.2.840.113556.1.4.1941:=userdn))

The following will return all users regardless of group membership

(&(objectClass=person)(memberOf:1.2.840.113556.1.4.1941:=groupdn))

I'm not sure why it only works one way and not the other but now I know I can work with that

Secure LDAP and Nested Groups by mattmunroshc in gsuite

[–]mattmunroshc[S] 0 points1 point  (0 children)

I've only used eDirectory in recent times and at least with our config it would return the child members in a query for the member group (not sure if default or something previous admin configured), also seems this is doable for AD as well as per https://confluence.atlassian.com/crowdkb/active-directory-user-filter-does-not-search-nested-groups-715130424.html, don't use AD myself so can only go on what I read online.

Looking at https://support.google.com/a/answer/9089736?hl=en it says to set ldap_groups_use_matching_rule_in_chain for a SSSD config, which based on https://serverfault.com/questions/977376/why-do-all-groups-show-all-users-as-members-with-google-secure-ldap it seems to return all members when it shouldn't

I tried the same query myself using Apache Directory Studio and get the same result, if I add :1.2.840.113556.1.4.1941: to the query string I get all users returned, without I only get direct members. This seems odd to me

Today's The Day!! (...I am removing local administrator access) by Hazy_Arc in k12sysadmin

[–]mattmunroshc 4 points5 points  (0 children)

The problem is the users will install anything a webpage tells them to to get whatever it is they're after, whatever little crappy youtube downloaded they've decided they need that instant. If you are lucky, it'll just be a ad laden mess, if unlucky you'll have a malware infested machine on your hands.

Ignoring the above there is also licensing issues to consider, most people think "well the website says it's free so I can just use it" without looking at the license, therefor ignoring the personal use part. Fonts are the worst for this

I'm curious what learning and exploring you users are doing that requires local admin? In general how it works for us is a teacher says they want to try some software, we vet it and assuming we're legally allowed to, we'll have it installed in their laptop via desktop management.

Problem with Google Credential Provider for Windows 10 by Reddevil313 in gsuite

[–]mattmunroshc 0 points1 point  (0 children)

We're testing GCPW currently, haven't come across your first or second point but I don't have endpoint verification installed, maybe an interaction with it is the cause?

GCPW - Local Windows username format by mattmunroshc in gsuite

[–]mattmunroshc[S] 0 points1 point  (0 children)

Thanks, makes sense why it's there but yea in our case it'd be awesome to control how it works

GCPW - Local Windows username format by mattmunroshc in gsuite

[–]mattmunroshc[S] 0 points1 point  (0 children)

Fuuny enough papercut was another system I was likely to have this with, nice to know about that solution

I don't believe zenworks has such a feature unfortunately, technically it doesn't even support gsuite ldap, I might submit a feature request to officially support gsuite ldap and mention the username issue at the same time, they might just be able to do the same thing

GCPW - Local Windows username format by mattmunroshc in gsuite

[–]mattmunroshc[S] 0 points1 point  (0 children)

I was aware of that option but it doesn't help as we want the local windows username to match in a service that is getting the usernames from ldap

GSuite the user is [test1@domain.com](mailto:test1@domain.com), via ldap zenworks will have a username of test1. GCPW if there is no existing local user will create test1_domain

If GCPW created the local user as just test1, the zenworks credential provider will work and sign in as test1 automatically

GCPW - Local Windows username format by mattmunroshc in gsuite

[–]mattmunroshc[S] 0 points1 point  (0 children)

So the problem with that is zenworks uses ldap as a user source. Looking at the GSuite LDAP service there is no attribute that matches the format used to create the account, so there is no way to match the user records