Andy M

DUO RDP login has a convenient deployment mode where you can use GPOs to push out the Integration key, Secret key (SKEY), and API hostname settings. However, if you follow their documentation (as least today 2021-01-29) all authenticated users on the domain will be able to read the SKEY. This could allow attackers to generate the 2FA codes themselves .  All users would be able to access the key through any of the steps below: Open GPMC Pull the registry.pol file from the SYSVOL share I informed DUO of this issue and they will be updating their documentation. Remediation: If you intend to keep deploying the DUO settings through GPO then the steps below should keep the SKEY safe(r). Instead of allowing "Authenticated Users" to read the GPO, we will be restricting it to Domain Computers. This would still allow an attacker to read the SKEY GPO if they compromise a computer, but I don't think it's an issue since they would be able to pull it from the registry anyway.  Make...

This guide will show you how to create shims that allow regular users to run applications that normally require local admin. Shims should only be used as a measure of last resort. In many cases simply granting users to certain folders or reg keys eliminates the need to create a shim. You can use LUA Buglight to identify what those reg keys/files are.   How it works The shim will force the application to use "RunAsInvoker" when it is launched. RunAsInvoker tells the application to open with the privilege level of whatever launched it. For example, if a regular user opens the application through explorer.exe (a non admin process) then the application will open with regular user permissions.  Things to keep in mind: Shims should be installed after the application Shims might need to be re-installed if an application is updated Not all apps play well with shims. Make sure to test the application before putting it into production Pre-Requisites Install the Microsoft Applicati...

Note: The steps below are not recommended by Microsoft . Verify that modern authentication is enabled before moving forward. When an Exchange users is migrated to Office 365 they may get constant credential prompts. Even if the user enters the correct credentials the prompt will come back in a few minutes. The user might also lose the ability to access shared mailboxes and public folders.  The fix is to set all of the reg keys below to 1 , doing so will enable modern authentication. Office 2013: HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version Office 2016: HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity\EnableADAL All versions 2013+ Create this even if you are on 2016 where it is enabled by default HKEY_CURRENT_USER\Software\Microsoft\Exchange\AlwaysUseMSOAuthForAutoDiscover Restart Outlook and the prompts should go away.  https://docs.microsoft.com/en-us/exchange/troubleshoot/modern-authentication/...

I got the error below when trying to connect to an remote desktop gateway.  Event ID 304 The user "DOMAIN\User", on client computer "0.0.0.0", met connection authorization policy and resource authorization policy requirements, but could not connect to resource "remote.example.com". Connection protocol used: "HTTP". The following error occurred: "23005". The solution was to create the internal DNS record pointing "remote.example.com" to the gateway. Looks like this item was accidentally skipped during setup.

I ran into an issue where the Window search service would constantly crash. The Event viewer showed the error below, and the crashdumps folder has a ton of SearchProtocolHost.exe.21580.dmp files. Faulting application name: SearchProtocolHost.exe, version: 7.0.9600.19660, time stamp: 0x5e4586a5 Faulting module name: mso20win32client.dll, version: 0.0.0.0, time stamp: 0x5e8a785b Exception code: 0x0241938e Fault offset: 0x00196a44 Faulting process id: 0x24a4 Faulting application start time: 0x01d617e35d974e4f Faulting application path: C:\windows\sysWow64\SearchProtocolHost.exe Faulting module path: C:\Program Files (x86)\Common Files\Microsoft Shared\Office16\mso20win32client.dll Report Id: b5c9d48f-83d6-11ea-80fa-000c290a7afd Faulting package full name:  Faulting package-relative application ID:  Analyzing the crash dumps pointed to MSPST32.DLL but none of the users had PSTs loaded. I found this article , but it did not resolve the issue. Eventually the f...

I have been dealing with an issue where a user's outlook would switch to online mode at random. The only way to resolve the issue was to log the user out of the computer and back in. Re-creating the account resolved the issue, but it came back the next day. Procmon and ProcExp didn't point to any clear causes. Eventually I was able to find the root cause by looking at the permissions of the mailboxes. The two mailboxes had Full Access to each other and auto mapping (never use auto mapping!) was enabled. This resulted in a situation where the mailboxes were fighting for who would be the primary mailbox, and who would be the secondary. Removing the permissions resolved the issue and both mailboxes worked correctly inside of Outlook.