|
OK So I have a fun one. I have an ADFS installation that cannot read the employeeNumber entry from Active Directory. I dug into it and the account didn't have read permissions for those attributes. Now, if I give full control over the AD Objects to the ADFS service, it can read the employeeNumber. If I remove Full Control but leave all the read permissions I cannot read the attribute any longer. Right now when I look at effective permissions, the account has permission to read the attribute on the object but it still cannot read the drat attribute. I just get blank. I truly cannot fathom it at this moment. Am I doing something completely stupid?
|
#
¿
Apr 2, 2018 17:34
|
|
|
|
| # ¿ May 21, 2024 19:24 |
|
|
incoherent posted:What happens when you try to use the ADFS credentials in ldp.exe and try to enumerate the the attributes? It's a hardcore tool, but should give you an ideal whats up Thank you for that link. I went through it and was able to enumerate what could be read by the account when it had Full Control vs. otherwise. Its nuts. I can set it to read everything, yet employeeNumber isn't enumerated. When I go to security descriptors, I can see that I have full read permissions and no go. I give it Full Control and BAM! I can read it. It's weird as hell. I think there are some bad bad settings in our AD from our previous lords. I'll dig deeper. And again thank you!
|
|
#
¿
Apr 3, 2018 16:53
|
|
|
incoherent posted:Sounds like a you'll need to call Microsoft professional services. Out of curiosity what is your forest/domain level? Also does the behavior happen when you bind to every domain controller? (or Global catalog DC?) So far every domain controller. Yea I think offical services is the way to go on this one too. The previous "team" of knuckle heads have done some super shady crap to this domain.
|
|
#
¿
Apr 4, 2018 18:53
|
|
|
skipdogg posted:If I had to guess someone set/marked the employeeNumber attribute in AD as confidential. It explains the issue you're seeing. This!  This right here! Thank you so much! I thought it would be something like this, but honestly I had no inkling of the nomenclature as I had never run into it in production before. And yea it probably needed to be a confidential thing because security. Which is all good. Just no one here from then to tell anyone else. Now my adfs service can't get rocked and totally screw up our AD because it can only read!
|
|
#
¿
Apr 5, 2018 20:35
|
|
|
Request below for how ATP works for your O365 Tenant vs. just EOP. What is good what is bad, etc. Currently we have a setup where our Student's email is hosted in our O365 Tenant and our Faculty / Staff are hosted locally in Exchange 2013, but AD is synced with that same O365 Tenant for Office and other services licensing. When I took over infrastructure here, O365 only had EOP in front of it, which was woefully under serving the security needs of the student email system. For on-prem we had Symantec Messaging Gateway VMs which were little better than an open relay. After some public phishing attacks etc. we finally got a little money to move to Local Sophos VMs for our Email gateways based on how awesome their AV has been to administer on campus. We wanted something like Proofpoint but the money just wasn't there. We have the incoming student O365 mail loop through our on campus filters, because again, EOP was sad at that point, which has worked pretty well at stopping a lot of the nonsense. However, we are finally ready to start looking at migrating the faculty/staff mailboxes up to the 365 tenant, and are re-evaluating mail filters. Because of some State oversight, "Cloud" solutions have to be considered and allowed which of course costs money and time to evaluate. O365 is already approved and we are looking at our new 3 year campus agreement coming up. We are looking at once we fully migrate our Faculty / Staff to just going all in and buying licenses for ATP. Does anyone have any advice or experience with ATP? Is it working well for you, does it make sense?
|
|
#
¿
Apr 29, 2019 13:38
|
|
|
stevewm posted:Wish they would fix this... We just bunny hopped over 2016 because of this issue. We have like 3 or 4 servers in production everything else gets 2019 unless something specifically breaks. Other Content: Office 365 Sub-Domains... So. We have a root domain and 3 subdomains: domain.root students.domain.root dev.domain.root test.domain.root I recently built dev and test because we are moving to a new SSO (shibboleth) and wanted to do some testing before we ripped the bandaid off and blew up the butt. But of course, Microsoft cannot make poo poo easy, ever. Currently our root is Managed and our Students are Federated. Don't ask, I don't know and if I could talk to the person who set it up this way I would have already killed them. But, we won't be swapping the root to federated until we have dev/test of Shibboleth up and running and we migrate them at the same time with students. I add the two new MSOL-Domains and try to move one to federated and BAM! nope, because the root is managed, sub-domains that are added AFTER the root get forced into whatever the root was because reasons. . It appears that from this article that the only way around it is to contact O365 support (who will totally know what I am talking about) to have them generate the domain without the RootDomain flag. I may also be bitching about this while I wait for my only dev account to be deleted from O365 so I can delete the domain and then generate those tickets. UGH. Still though, Sub-domains might be completely separate companies that use completely different SSO. Nice default, except when you run smack into it.
|
|
#
¿
Jul 8, 2019 21:10
|
|
|
Sirotan posted:kiwid, I was in the process of writing up a post recommending you use Microsoft Baseline Security Analyzer as a quick/easy/free way to check some of your systems for compliance, but I guess I've been out of the SMB game for too long now, and just learned it's no longer supported. If you also have SCCM in your environment, you could set up some compliance reporting. Otherwise, I use Nessus (sorry, Dirt Road Junglist), there is a free version called OpenVAS that you might be able to check out. I have never used it so this is not a recommendation, just a suggestion. Chiming in. We use OpenVAS for scanning our servers before we put them on the open internet. Is good. But, at least in the config we have, it scans the ports and then services that are available. Does have good reporting though.
|
|
#
¿
Jul 17, 2019 02:31
|
|
|
I have a fun Windows / Sharepoint 2013 (LOL) question. We ran Windows Updates on one of our test front-ends and an indexer last night to start getting things up to snuff. Getting this error on the main app on the front end we were updating:  SQL server is still "unpatched" from this point of view. The front-end is erroring out I *think* on the DB connection:  WFE (does not work): Server 2012 R2 -Most recent updates applied .Net Version 4.8.03761 WFE (didn't update, does work): Server 2012 R2 -Patches have been a while .Net Version 4.6.01055 Index (Updated, works): Server 2012 R2 - Most recent updates applied .Net Version: 4.8.03761 SQL (works): Server 2012 R2 - Patches have been a while - .Net Version 4.6.01055 I'm trying to figure out what exactly might be the issue here, I can tell its something with the SQL conversation but can't quite nail down what the exact issue is. Things I have tried: - Editing the configuration string to connect with TrustedConnection=Yes - Editing the configuration string to connect with TransparentNetworkIPResolution=False - https://docs.microsoft.com/en-us/ar...orkipresolution - Checked all the protocols in the registry - Both front ends are the same, nothing changed there TLS is still enabled SSLv3 and below disabled. Questions: 1. Any ideas of things I should try? Rabbit holes to go down? 2. Is there a process to get the Sharepoint Foundation app to try and connect to the DBs again without rebooting the server? I want to try doing some packet captures and compare with the working server and this is the bare metal install (I know). 3. Should I just restore my latest backup to VMWare and slow patch this POS?
|
|
#
¿
Dec 15, 2020 20:06
|
|
|
Bob Morales posted:Can you connect to the SQL server using SQL Management Studio? Yep, I can connect no problem, and the other servers can too. An update could have blown up the registry protocols. Ill take a look. ptier fucked around with this message at 21:03 on Dec 15, 2020 |
|
#
¿
Dec 15, 2020 20:28
|
|
|
ptier posted:Yep, I can connect no problem, and the other servers can too. An update could have blown up the registry protocols. Ill take a look. I looked, Registry says they have the same settings lowest is TLS 1.0. So no SSLv3 shenanigans. Probably just going to restore to VM and play with it. Because really they need to go to VM anyways.
|
|
#
¿
Dec 15, 2020 21:04
|
|
|
lol internet. posted:Exchange online environment. Question about the Outlook junk filter. Is this controlled separately from Exchange online? Does putting a whitelist on exchange online bypass the local junk filter on outlook? Basically items are being put into the junk folder which aren't actually junk (Email Alerts) I know you could white list it on the client but it's going into a lot of peoples junk folder. I assume this is a separate client side feature not controlled from the exchange online portal. They are separate but, In the rules for exchange online, you can set the from address or other identifying info to set the spam level to bypass. That should cause local outlook to not cover it as junk. One of the things the local junk filter looks at is the SCL ( spam confidence level). If exchange online says it’s clean usually thats enough. We recently migrated to O365 And had a number of emails like that from local systems that had to bypass the filter. ptier fucked around with this message at 12:54 on Jan 6, 2021 |
|
#
¿
Jan 6, 2021 12:51
|
|
|
So, this may be more of a Microsoft 365 question, and if there is an appropriate thread for that, please kick me there, I didn't see anything in my searching: Due to regulatory requirements, I have to disable accounts that have been inactive for 90 days. I am not going to split hairs on "what does that * mean * anyways?!". I agree. Especially when dealing with all the fields in AD that seem like they should be used for that and definitely * should not * be used for that. The local network version of the solution has worked fine since inception, it is: code:BUT, wrinkle time. Since March 2020 a large contingent has been working remotely. They are not VPNing in, because they just email and teams their day away and never hit the local DC. Then I start to google about how to programmatically get those logs or entries from Microsoft 365 Azure AD. I get a lot of: "you have to get the report manually from O365" there is a way to pull a list of last login to mailbox BUT it is also updated by lots of background processes finally hit on a feature in the Graph API for signInActivity, BUT its in BETA Using the graph scenario just to see what I can get, I was able to check my local list of inactive users against Azure AD Signin activity. Which has worked well. The rub comes that whenever I roll in and try to run that process again, I get 403's on the API call. If I pull back to just email address and name, it works fine. I have to go in and grant permissions to the app registration in Azure (even though it is already granted) and then it will start working again. I am getting a new token each run of my script, AND I have other app registrations that don't use the beta graph and its fine. I guess this is one of those "Don't use beta in prod, and this is how we enforce it, or side effect" but, damnit, this is dumb. Usually any kind of regulation requires this, why the hell is there not just a "Do thing, get data on this specific thing that most orgs needs to do." Also we really don't have people to put on this, so its just frustrating. If there is something else I can use or programmatically do for this, I would be forever in your debt.
|
|
#
¿
Apr 9, 2021 20:28
|
|
|
We are a Microsoft 365 Shop (University), with Entra ID P2, E5 Licensing and we use DUO for our main MFA provider because of all the disparate systems we integrate with. We are on the cusp of requiring SSPR registration ( its been optional and we have about 50% adoption rate ), and we are taking the opportunity to shave down our Authentication options. We are trying to get rid of:
The wrinkle that has reared its head is the new Authentication Methods policy page that will be forced sometime in September 2025. We use DUO as a conditional access policy and then SSPR for password reset, so the "MFA" parts of 365 for us are completely disabled. It appears right now that the new Auth Methods pane is really busted and kinda bullshit, so I am writing all of this from a "as of this writing". Once the new Auth methods pane is fully migrated the user doesn't get prompted for SSPR registration any longer. It would just require an MFA registration if I turned on a campaign which if my 365 Trial is to be believed, has a broken disable button after I turn it on, or its just reverting at "Cloud Speed". ( I have two M365 trials going to test out these changes because no way in hell am I just hitting the button and hoping for the best). Oh and best part, regardless if I have MS Authenticator set to NO, but have Software OATH Tokens set to TRUE, it still uses the add Microsoft Authenticator pane which I think is just how MS is rolling. The more I dig into it the more turbo hosed it feels. So from all of this I have a couple of determinations.
ptier fucked around with this message at 20:42 on Apr 30, 2024 |
|
#
¿
Apr 30, 2024 20:37
|
|
|
Thanks Ants posted:I don't envy you having to provide the end user support/documentation for someone who has MS Authenticator that only exists to do password recovery but no MFA prompts come via it, and in the meantime you can't evaluate MFA strength since Duo has no way to tell Entra what method you used. Yea, its really becoming a pain the butt.
|
|
#
¿
Apr 30, 2024 21:05
|
|
|
Thanks Ants posted:I don't envy you having to provide the end user support/documentation for someone who has MS Authenticator that only exists to do password recovery but no MFA prompts come via it, and in the meantime you can't evaluate MFA strength since Duo has no way to tell Entra what method you used. Praise Allah! https://techcommunity.microsoft.com/t5/microsoft-entra-blog/public-preview-external-authentication-methods-in-microsoft/ba-p/4078808 TL:DR 3rd party MFA providers will be given a 1st class auth method treatment soon! So I'm just gonna wait.
|
|
#
¿
May 6, 2024 20:15
|
|
|
Submarine Sandpaper posted:Giving the help desk access to the CLI instead of converting the MSO script that cleared the 2fa for a user is not really helpful. This is what we have ended up doing. Little boiler plate in the beginning of the script. The only thing I don't like / makes me not put it in "the wild" is that the secret is in the script. Could do a new one for each person... but we are transitioning to an integration platform where we are just going to turn all the scripts into forms. Its a long process but will get us further away from day to day powershell, which I find a bonus for all of our helpdesk staff unless they want to play and then they can learn with some training wheels.
|
|
#
¿
May 8, 2024 15:23
|
|
|
Aunt Beth posted:We’ve moved towards institutionalizing the day to day powershell in Powershell Universal UIs, it’s such an extensible platform for $500/year we get so much value out of it That is really cool! Wish I had seen that like 5 years ago. For us, we have so many integrations we need to make between a ton of different systems an integration platform was the next step for us and using powershell to do advanced processing in AD was the main thing we need it for.
|
|
#
¿
May 9, 2024 13:47
|
|
|
tehinternet posted:Can’t you keep the secret in Azure key vault then call it securely from your script with headless auth to lessen issues with having the secret in the script Yes, and now I know a thing. I will admit I did not dig into it much just because it was not going to be the solution we used anyways. So, yea, don't pay attention to the goon behind the curtain.
|
|
#
¿
May 13, 2024 19:18
|
|
|
|
| # ¿ May 21, 2024 19:24 |
|
|
Thanks Ants posted:"Waiting 15 minutes" is always the way with a lot of this M365 stuff. Especially when you're doing stuff in Teams and PSTN. We call it "cloud time" around these parts. Especially with Intune and waiting for policies to apply. Out of 16 PCs, 12 will do it right away and then 4 will take like half a day because CLOUD TIME!
|
|
#
¿
May 14, 2024 18:21
|
|