|
Fruit Smoothies posted:I have 2 old domain controllers that are still active servers. They've been demoted from domain controllers, but seemingly not 100%. I can't use the ntdsutil tool to connect to them, and I had to remove them in AD sites. There's a lot of entries in DNS but when I remove them, they refresh back in a few seconds. Any ideas? Are they still listed in DNS zones as name servers? You have to manually remove servers from sites and services and name servers list in DNS zones.
|
#
?
Nov 14, 2019 19:17
|
|
|
|
| # ? May 28, 2024 19:31 |
|
|
MF_James posted:Are they still listed in DNS zones as name servers? You have to manually remove servers from sites and services and name servers list in DNS zones. No they're not listed as name servers
|
|
#
?
Nov 15, 2019 00:14
|
|
|
klosterdev posted:If you've got AD, a longer term solution would be to set up security groups for all major shares, configure automapping in group policy management, and use item-level targeting to only have it map for users in those security groups. We've gotten so many fewer calls asking to map $Drive since I set it up, and it's another thing we have to think less about during our migration. Please no. Just make a separate clearly labeled mapping policy per security group. Dear God do I hate having to deconstruct some monstrosity of targeted settings inside a single policy when it could have been cleanly separated out. You can make a couple hundred million policies before AD starts to poo poo itself.
|
|
#
?
Nov 15, 2019 04:17
|
|
|
Digital_Jesus posted:Please no. Just make a separate clearly labeled mapping policy per security group. Is there a good way to organize group policy objects? Recently learned how to filter GPOs by security group, but my next concern about going full-ham one-GPO-does-one-thing is organizing everything without an obnoxiously long list to sort through each time I need to apply something. Obvs good naming convention is important, but ideally I'd like a way to compartmentalize by category or something that makes it easier to sort through.
|
|
#
?
Nov 15, 2019 04:35
|
|
|
Tab8715 posted:Why wouldn’t you want customers to use SSO for products or services? Once again - I am not arguing against SSO. SSO is fantastic and great and everyone should implement it everywhere yesterday. I'm just trying to bring some context into the discussion. For example, password resets are quick and can be processed by anyone with a pulse. SSO issues are more difficult and require a level of familiarity with how everything is supposed to work and troubleshooting skills. Being angry that companies don't provide SSO for free is a perfectly reasonable position, but to pretend that there is no overhead associated with providing SSO to customers is false.
|
|
#
?
Nov 15, 2019 05:45
|
|
|
H2SO4 posted:Once again - I am not arguing against SSO. SSO is fantastic and great and everyone should implement it everywhere yesterday. Of course there is overhead. There is also so little of it that it’s basically irrelevant. The burden of knowing what the hell is going on IS pushed in to the customer in almost every offering I have ever heard of. If you, a singular customer is having issues with sso and the rest of their customers are not, you have better luck of having your product licenses expiring before you get any meaningful vendor help.
|
|
#
?
Nov 15, 2019 06:53
|
|
|
I don't see how SSO problems couldn't be built into a troubleshooting workflow the same as all other common support issues that these SaaS providers have to deal with. SAML is a pretty well understood system at this point, there are tools to help diagnose it, and integrating with Azure AD using OAuth gets you SSO with (probably?) the most common directory without having to go near SAML.
|
|
#
?
Nov 15, 2019 11:44
|
|
|
I’m coming up on the end of a project where I’m migrating SSO for everything to Okta from ADFS, we just have the big ones left to do. The vendors that let you import a metadata xml file from your idp are the best. Next up are ones that at least let you self-service SAML setup. Anyone below that can go to hell, I shouldn’t have to schedule a call with support to do the cutover. There is however a special circle of hell for those I have to work through a third party to do the cutover, especially when you’re charging me and I have to get the SOW through legal.
|
|
#
?
Nov 15, 2019 14:29
|
|
|
devmd01 posted:I’m coming up on the end of a project where I’m migrating SSO for everything to Okta from ADFS, we just have the big ones left to do. I once had okta shut off SSO for my entire Gcloud tenant because we were using a feature in okta we weren't licensed for. It turned out that we didn't know we weren't licensed for it because hey, its in the menu's for us to select and configure and it doesn't mention needing licensing. It took nearly a week of me screaming at the top of my lungs to not only prove that sso was broken in the first place but also to get someone to tell me wtf.
|
|
#
?
Nov 15, 2019 15:01
|
|
|
H2SO4 posted:Once again - I am not arguing against SSO. SSO is fantastic and great and everyone should implement it everywhere yesterday. Don’t take me wrong, I was not accusing you of being against SSO just from a business perspective it makes no sense at all to not support such a technology. Password resets are generally quick but seriously who the hell wants to deal with crap like that? I wager humanity has wasted millions of hours resetting passwords and all of that time could have been spent doing something else entirely more productive.
|
|
#
?
Nov 15, 2019 16:46
|
|
|
klosterdev posted:Is there a good way to organize group policy objects? Recently learned how to filter GPOs by security group, but my next concern about going full-ham one-GPO-does-one-thing is organizing everything without an obnoxiously long list to sort through each time I need to apply something. Obvs good naming convention is important, but ideally I'd like a way to compartmentalize by category or something that makes it easier to sort through. Not really. The list sorts alphabetically so a good naming scheme helps. 1:1 GPO to thing isnt really necessary, you can combine things that are similar to save space if you do it intelligently. I really just hate item level targeting because people make huge messes with it under the false assumption fewer GPOs = Better for some weird reason.
|
|
#
?
Nov 16, 2019 03:34
|
|
|
Digital_Jesus posted:Not really. The list sorts alphabetically so a good naming scheme helps. 1:1 GPO to thing isnt really necessary, you can combine things that are similar to save space if you do it intelligently. Thanks! Been doing my best to create and organize our GPOs/security grouping by category in a way that would feel fairly intuitive for anybody who may inherit what I'm putting together down the line. Right now I've put together a Drive Maps GPO using item-level targeting for read/write security groups, but my long-term plan to get and keep file-access/mapping clean and organized is - Each $Site has one primary share, with a security group that can grant users Read+Execute - In the share are several inheritance-disabled folders, each for a program the site is responsible for, with their own Read/Write security groups - Each of the above security groups is a member of the security group that grants Read+Execute to the root of that site's share - Drive mapping GPO has one entry per $Site, with item level targeting allowing for anyone in the root Read+Execute group - If a user needs access to any of $Site's folders, they're added to the relevant security group for that folder, which also adds them to Read+Execute root group, causing the root drive for $Site to automap In the even longer term, I’m going to create security groups for common types of employees and use nested grouping to grant them the minimum-level access that those employee types need. Still need to test all this, once we've got our W10 and '08R2 migrations complete. Really excited about tackling this, and it should keep the auto-mapping list fairly short and consistant.
|
|
#
?
Nov 16, 2019 18:02
|
|
|
The “everyone gets a single DFS mapping” secured by non-inherited access groups with ABE enabled is my preferred method. gently caress multiple drive mappings.
|
|
#
?
Nov 16, 2019 18:54
|
|
|
Digital_Jesus posted:The “everyone gets a single DFS mapping” secured by non-inherited access groups with ABE enabled is my preferred method. gently caress multiple drive mappings. I still chuckle when I rediscover that you can’t use group policy for the new version of mapped folders in windows 10
|
|
#
?
Nov 16, 2019 20:40
|
|
|
Does it even make sense to user Hyper-V Server on a home lab system? Or should I just install Windows Server w/GUI directly to bare-metal and then give it the Hyper-V role? Not sure what the benefits are of going with Hyper-V Server/VM rather than Windows Server/Hyper-V role in a home lab.
|
|
#
?
Nov 16, 2019 22:20
|
|
|
PUBLIC TOILET posted:Does it even make sense to user Hyper-V Server on a home lab system? Or should I just install Windows Server w/GUI directly to bare-metal and then give it the Hyper-V role? Not sure what the benefits are of going with Hyper-V Server/VM rather than Windows Server/Hyper-V role in a home lab. Embrace powershell. GUIs are dead. Let them go.
|
|
#
?
Nov 17, 2019 00:37
|
|
|
Digital_Jesus posted:Embrace powershell. GUIs are dead. Let them go. Can’t install NPS without GUI yet Unless it’s changed, it’s tricky to do modern auth with PowerShell without the GUI components
|
|
#
?
Nov 17, 2019 00:55
|
|
|
We're deploying a new application replacing an old, and the design for the new application really wants several hundred AD groups to control access. The old application had no AD integration and used internal user management. Each user may need to be member of between 3 and 20 of these new groups. Am I right in thinking this is a potential problem due to how the user's Kerberos ticket will grow? I want to propose a wild shot solution of standing up a new domain only for holding groups for this application, making them as local groups in this domain, and keep users logging in through the regular domain. Am I right in thinking local groups on a different domain (same forest) will not "pollute" users' Kerberos tickets? We do have an identity management solution in place, so managing user memberships of groups on another domain should not be much of a problem. Is this a totally crazy idea?
|
|
#
?
Nov 22, 2019 11:36
|
|
|
nielsm posted:We're deploying a new application replacing an old, and the design for the new application really wants several hundred AD groups to control access. The old application had no AD integration and used internal user management. Each user may need to be member of between 3 and 20 of these new groups. Am I right in thinking this is a potential problem due to how the user's Kerberos ticket will grow? Isn't this the sort of thing AD LDS is for?
|
|
#
?
Nov 22, 2019 15:49
|
|
|
3 to 20 groups shouldn't blow up your token too bad. I've only ran into it a couple times in my career and the users affected had 150+ groups and 2 SIDHistory entries.
|
|
#
?
Nov 22, 2019 16:16
|
|
|
Toast Museum posted:Isn't this the sort of thing AD LDS is for? I don't know, is it? As far as I understand, since an LDS instance is not part of an AD forest, there can't be any trust relationships, and group memberships couldn't really be verified by the LDS server. skipdogg posted:3 to 20 groups shouldn't blow up your token too bad. I've only ran into it a couple times in my career and the users affected had 150+ groups and 2 SIDHistory entries. I definitely remember one situation where a user was prevented from accessing a web application served by an Apache2 server, it threw an error about the Authorize header being too long. I think that user was member of perhaps 50 groups, and it was resolved by removing some group memberships. (Lots of legacy crap that was no longer relevant.) With our naming standards and OU structure, each of these groups would probably be 20-30 characters for the CN, and upwards 110 characters for the full DN.
|
|
#
?
Nov 22, 2019 18:09
|
|
|
If I want to prevent a user access to their Office 365 mailbox, can I just disable ActiveSync, OWA, MAPI, POP3, and IMAP and they'll lose all access, even Outlook?
|
|
#
?
Nov 22, 2019 21:57
|
|
|
kiwid posted:If I want to prevent a user access to their Office 365 mailbox, can I just disable ActiveSync, OWA, MAPI, POP3, and IMAP and they'll lose all access, even Outlook? You can block sign in access at the o365 level or disable their ad account if you sync it to azure ad. Block sign in is r exact name of the feature. Just look up the account and apply.
|
|
#
?
Nov 22, 2019 21:59
|
|
|
Sickening posted:You can block sign in access at the o365 level or disable their ad account if you sync it to azure ad. Ah yes, that's probably what I'll do then, thanks.
|
|
#
?
Nov 22, 2019 22:09
|
|
|
nielsm posted:I don't know, is it? As far as I understand, since an LDS instance is not part of an AD forest, there can't be any trust relationships, and group memberships couldn't really be verified by the LDS server. Ahh Ok. Apache might have had the token limit set to 8K which is lower than the default windows size of 12K. The guy I last ran into was around 14K which caused problems with one of our apps. He was carrying around 2 SIDHistory entries, and the associated group info in his token as well. I actually dug up the report I ran at the time, and he had 179 group memberships across 3 domains in his token. The domain local and groups in other domains use up a lot more space in the token than a normal AD group. Does the app support Modern Auth? Maybe look at SAML instead of Kerberos?
|
|
#
?
Nov 22, 2019 23:07
|
|
|
The app is actually SharePoint based, and I wanted to recommend using SP groups, but the vendor strongly discourages that for vague reasons I'm not entirely sure I agree with. I'm not the one to make actual technical decisions on the environment, the most I can do is make recommendations. So really, I hope you don't mind me just using this thread to throw some ideas at the wall before offering them to the real audience. I had the impression that domain local groups in other domains would not be present in your token at all, if you don't log on to that domain, but they do?
|
|
#
?
Nov 23, 2019 01:14
|
|
|
nielsm posted:I don't know, is it? As far as I understand, since an LDS instance is not part of an AD forest, there can't be any trust relationships, and group memberships couldn't really be verified by the LDS server. I haven't actually used AD LDS, so it's entirely possible that I'm just confused about what it's for and what it can do. If I understand correctly, it allows app-specific modifications to the AD schema and AD objects without altering AD DS itself. Will anything besides this one app care about these new groups? If not, it sounds like you'd be able to populate the AD LDS instance from AD DS, create app-specific groups and assign memberships within AD LDS, and have the app query that instance rather than AD DS.
|
|
#
?
Nov 23, 2019 05:21
|
|
|
Toast Museum posted:Isn't this the sort of thing AD LDS is for? AD LDS would be perfect case but now we have claims based auth along with a slew of modern authentication protocols. I would suspect that it wouldn't be too difficult to integrate and most vendors support it.
|
|
#
?
Dec 1, 2019 07:10
|
|
|
Hopefully someone can explain this one to me. We have a standard Windows file server that was being accessed by an Ubuntu Linux server. In my /etc/fstab file, I have this entry: code:I ended up doing some maintenance on the file server this weekend and rebooting it and only then did the Ubuntu server seem to lose access and we noticed it was because we deleted that user account a month ago. My question is, how and why did the Ubuntu server retain access for a month when that account was deleted from Active Directory?
|
|
#
?
Dec 9, 2019 15:12
|
|
|
Generally with kerb once you are authenticated it's just keeping the active token alive. So long as the same device keeps the socket up, it keeps getting serviced until some timeout happens and forces it to renegotiate. I am pretty sure that if the account was disabled instead of deleted it would have caught it on a token refresh. Setting this GPO on the SMB server would probably stop this as well: https://docs.microsoft.com/en-us/wi...on-hours-expire
|
|
#
?
Dec 9, 2019 16:47
|
|
|
BangersInMyKnickers posted:Generally with kerb once you are authenticated it's just keeping the active token alive. So long as the same device keeps the socket up, it keeps getting serviced until some timeout happens and forces it to renegotiate. I am pretty sure that if the account was disabled instead of deleted it would have caught it on a token refresh. Setting this GPO on the SMB server would probably stop this as well: https://docs.microsoft.com/en-us/wi...on-hours-expire This was my guess as well. Kerberos token just kept refreshing on the same socket.
|
|
#
?
Dec 9, 2019 18:07
|
|
|
BangersInMyKnickers posted:Generally with kerb once you are authenticated it's just keeping the active token alive. So long as the same device keeps the socket up, it keeps getting serviced until some timeout happens and forces it to renegotiate. I am pretty sure that if the account was disabled instead of deleted it would have caught it on a token refresh. Setting this GPO on the SMB server would probably stop this as well: https://docs.microsoft.com/en-us/wi...on-hours-expire Awesome thanks. I suspect because a web app on the Ubuntu server was polling this file share on the minute every minute that a timeout would never occur. I’ll check that gpo out though.
|
|
#
?
Dec 9, 2019 21:49
|
|
|
Sickening posted:You can block sign in access at the o365 level or disable their ad account if you sync it to azure ad. Ah gently caress, apparently you can't block sign in for AD synced users because AD sync just overwrites it and I can't block it at the AD level because I still need these users to be able to sign in locally. So now I'm at the point where I either throw all these users into their own OU and set the sync to ignore it, or I turn off all access in the admin like this:  What would you recommend? My only concern about the latter is that they might still be able to access in some weird way I'm not thinking about? And the former, I just really don't want to do if I don't have to. Edit: I ended up killing the protocols. kiwid fucked around with this message at 02:23 on Dec 14, 2019 |
|
#
?
Dec 14, 2019 00:03
|
|
|
You may also have been able to create a conditional access policy that evaluates to denying access to Exchange Online, and throw the account into the group. Assuming you have Azure AD Premium.
|
|
#
?
Dec 14, 2019 11:46
|
|
|
Trying to do a Computer/User GPO to block all USB access on all computers with the exception of AD users in _____ AD Group. The policy itself is actually the same for User/Computer configuration. It doesn't seem to work? I'm on 2019 LTSC at least. I'm doing this in a "Test OU" with inheritance blocked. Created two seperate GPOs. Computer Configuration GPO which disables all USB access in "Test OU" and User Configuration GPO which enables GPOs for users in the AD group. The user policy has precedence over the computer policy. Test user and Test PC is in the "Test OU." I login with the test user and USB still seems to be blocked. Running GPRESULT shows that it the user policy to enable is being pushed down. Any ideas?
|
|
#
?
Dec 27, 2019 05:44
|
|
|
lol internet. posted:Trying to do a Computer/User GPO to block all USB access on all computers with the exception of AD users in _____ AD Group. The policy itself is actually the same for User/Computer configuration. It doesn't seem to work? I'm on 2019 LTSC at least. Which settings exactly are you changing? If the user policy to deny USB works like you want it to then I think you should be able to get away with creating one policy that disables USB and edit the security on the GPO to set Deny permissions on it for your "allow USB" group.
|
|
#
?
Dec 27, 2019 06:31
|
|
|
If you're filtering the policy by security group make sure you've given read rights to domain computers in the GPO. Something Microsoft changed a few years ago. Still gets me sometimes if I'm on autopilot. vvvv yup good point vvvv Internet Explorer fucked around with this message at 06:50 on Dec 27, 2019 |
|
#
?
Dec 27, 2019 06:34
|
|
|
Internet Explorer posted:If you're filtering the policy by security group make sure you've given read rights domain computers in the GPO. Something Microsoft changed a few years ago. Still gets me sometimes if I'm on autopilot. At least in current versions of rsat you get a reminder prompt that will automatically add the permission when you try to do something like this.
|
|
#
?
Dec 27, 2019 06:39
|
|
|
H2SO4 posted:Which settings exactly are you changing? Policy 1 = Computer Configuration > Policies > Administrative Templates > System > Removable Storage Access > ll Removable Storage classes: Deny all access [Setting Enabled to Deny USB access] Policy 2 = User Configuration > Policies > Administrative Templates > System > Removable Storage Access > ll Removable Storage classes: Deny all access [Setting Disabled to Enable USB access. This policy is filtering based on User] In regards to Domain Computers/Authenticated Users, it does have read access to the GPO and the GPO appears to be winning when I run gpresult but the USB seems to remain disabled for the user.
|
|
#
?
Dec 27, 2019 06:54
|
|
|
|
| # ? May 28, 2024 19:31 |
|
|
Iirc with conflicting GPOs with CPU/user the former will always win out. Try changing the allow to computer as well and still filter by user?
|
|
#
?
Dec 27, 2019 14:40
|
|
