Exchange has been this way for a long time here’s me explaining this very problem with older versions of Exchange. If you create a ‘Group’, be that a Distribution Group, or a ‘Microsoft 365’ Group, the default setting is to NOT ALLOW mail from anyone outside your organisation. If you attempt to send mail to that group you will see errors like these;
Errors;
550 5.7.133 RESOLVER.RST.SenderNotAuthenticatedForGroup; authentication required; Delivery restriction check failed because the sender was not authenticated when sending to this group
550 5.7.133 RESOLVER.RST.SenderNotAuthenticatedForGroup; authentication required; Delivery restriction check failed because the sender not authenticated when sending to the group’
550 5.7.193 UnifiedGroupAgent; Delivery failed because the sender isn’t a group member or external senders aren’t permitted to send to this group.
Allow External Senders (On Premises & Hybrid Exchange)
If you have your own on premises Exchange server, this includes those of you that have migrated to Exchange online, but are in Hybrid Mode and are syncing your domain objects into Microsoft/Office 365 (Azure). Then you should change this setting in the on premises Exchange Admin Centre.
Recipients > Groups > Select the group in question > Edit > Delivery Management > Change to ‘Senders inside and outside of my organisation’ > Save.
Note: Remember in hybrid mode this will need to sync to Microsoft online, so apply the ‘cup of coffee rule’ before testing it.
Recipients > Groups > Select the group in question > Edit > Delivery Management > Change to ‘Senders inside and outside of my organisation’ > Save.
New Exchange Admin Center
Microsoft 365 Groups: Recipients > Groups > Microsoft 365 > ‘Double Click’ the group in question > Settings > Allow external senders to email this group > Save.
Distribution Groups: Recipients > Groups > Distribution List > ‘Double Click’ the group in question > Settings > Edit Delivery Management.
Allow messages from people inside and outside my organisation > Save changes.
Related Articles, References, Credits, or External Links
ExMerge has been around for a long time, its used (as the name implies) to merge pst files into existing mailbox’s. However its also a great tool to export/backup users mail box’s if you’re doing a migration, or if you have got your “Disaster Recovery” hat on.
The following is a run through of how to export from a mail store to pst files – Note on a live system this can take some time, the example below was done in VMware on a test Exchange box that had 1000 users (as it was a test server the mailbox’s were tiny) If you need to do this on a production server plan in a LOT of time if your moving a large amount of data.
Solution
Note: I’ve mentioned it in the video, but just to reiterate, your mailbox’s need to be smaller than 2GB, if that can not be achieved, you can either;
1. Use ExMerge and export particular “date ranges” and produce multiple .pst files for the same mailbox (hopefully less than 2GB).
I did a Duo run through a few weeks ago, and to be honest their documentation is usually pretty good. I was spinning this up as a PoC for a client so I thought I’d put my take on the procedure here.
ADFS Duo Pre-Requisites
I already have a Duo Authentication Proxy server setup and my users are enrolled, you will need to set this up first. See the following article;
Log into the the Duo Admin Portal > Applications > Protect an Application > Search for and select Microsoft ADFS > Protect This Application.
Copy the Integration Key, Secret Key and the API hostname to notepad.
Download the Duo AD FA MFA Adapter on your ‘first‘ ADFS server. Enter the information you copied to Notepad, (above). Tick ‘Bypass Duo Authentication when offline’, and because my users are logging on with their Office 365 UPNs, I’m also ticking ‘Use UPN username format’ (SEE USERNAME NORMALISATION NOTE BELOW.)
Note: I only have one ADFS server, if you have an ADFS Server farm you will need to install each one with the SAME shared session key, you can generate one of these yourself in PowerShell with the following commands;
I only have one, so I’ll simply ‘Generate new session key‘ > Finish the install wizard.
Note: If one has already been deployed, and you don’t know the key, go to the ADFS server on which it’s working, and look in the following registry key.
USERNAME NORMALISATION: Because I’m logging users on with UPNs (first-name.last-name.domain-name.com) Back in the Duo Portal under protected applications Microsoft ADFS > Set username normalisation to ‘None” > Scroll down and save the change.
Server 2019 Only: I’m deploying on Server 2019 so I also need to execute the following Powershell command, you will need to enter YOUR API Hostname (you copied above).
Tick ‘Duo Authentication for AD FS {version}’ > Apply > OK.
Relying Party Trust > Here I have my Office 365 trust, yours may be for something else! Edit Access Control Policy.
Click ‘Use Access Control Policy’ > The one I want is ‘Permit Everyone and Require MFA for Specific Group‘. This way I can select who gets 2FA challenged, and I can migrate users slowly into this group once I know they are enrolled, (also I use the same group to Sync the users to Duo to make things simple). Change the <parameter> and locate you domain security group.
Now when the users connect to ADFS, after they logon, they are challenged to provide 2FA authentication.
like so;
Related Articles, References, Credits, or External Links
I’m doing some work for a client that has Azure AD Sync running, and we keep kicking each other off the server, so I thought I’d login with another account. However, when I tried to open the Synchronisation Service Manager;
Unable to connect to the Synchronisation Service
Some possible reasons are:
1) The service is not started.
2) Your account is not a member of the requires security group.
See the Synchronisation Service documentation for details.
Solution
Well it was the second option in my case. Open Server Manager > Tools > Computer Management > System tools > Local Users and groups > Groups > ADSyncAdmins > Add your user in here.
Related Articles, References, Credits, or External Links
Once deployed, authentication is handled by the appliances own internal user database, in larger organisations this is a little impractical. So the ability to create an Active Directory Group, and delegate access to Firesight to members of that group is a little more versatile.
Solution
I’m making the assumption that the appliance does not already have external authentication setup at all, so I’ll cover everything from start to finish.
Newer Versions
Logon to the Appliance > System >Users > External Authentication > Add External Authentication Object
Older Versions
Logon to the Appliance > System > Local User Management > External Authentication > Create External Authentication Object.
Authentication Method: LDAP
Name: Chose a sensible name for the connection.
Server Type: MS Active Directory
Host Name/IP Address: the IP of your domain controller
Port:389 (this is standard LDAP)
If you have a second Domain Controller enter the details here.
Note: In Active Directory, I’ve created a USER to make the connection to Active Directory with, and I’ve also created a SECURITY GROUP that my administrators will be in.
You can use the ldp.exe tool to locate and find the correct LDAP path for the user you created, (and the group because you will need that in a minute as well).
Base DN: Usually the root of the domain, in standard LDAP format.
Username: The LDAP path to the user you created.
Password: For the user above.
UI Access Attribute: sAMAccountName
Shell Access Attribute: sAMAccountName
I’m simply having one administrative group, if you have a granular RBAC requirement, there are a number of pre-configured roles you can assign your AD groups to, (or you can create custom ones). So I’m adding the LDAP path of my administrators group to the ‘Administrator’ role.
Also set the default role to ‘Security Analyst (Read Only).
Group Member Attribute: member.
Username: A user in the AD Administrative group you created.
Password: Password for the above account.
Press ‘Test’
All being well you should see a success, Press Save.
Newer Versions
Switch the ‘slider’ to enabled > Save > Save and Apply. (Now skip to All Systems below).
Older Versions
You now need to add this to the policy being applied to this appliance. System > Local System Policy > Select the policy in use >Edit.
External Authentication
Status: Enabled
Default User Role: System Analyst (Read Only)
Finally change the slider button and ensure it is ticked. Save policy and exit.
Now apply the policy (green tick).
Tick the appliance > Apply.
Success.
All Systems
Now you can login with your administrative AD accounts.
You can also create a local user to match an AD account.
And get the appliance to use AD for authentication of this user.
Related Articles, References, Credits, or External Links
Seen when reinstalling SQL 2008 R2 on a domain controller. Note: as a background the SQL Server was installed previously and then the server was promoted to a domain controller. Then when the attempt to reinstall SQL was carried out this happened:
Microsoft SQL Server 2008 R2 Setup
The following error has occurred.
SQL Server Browser service group does not exists. Check for earlier failures in the setup
Note: Yes thats a typo, but there is a typo in the error message.
Solution
1. You need to create the group(s) manually, logon to a domain controller > Windows Key+R (to run) > type ‘dsa.msc’ > Enter.
This ensures that traffic that is sent over an RDP connection to a server is protected by TLS/SSL Encryption. IT DOES NOT stop clients connecting to an RDP server if they do not have a trusted certificate. If you need that level of security, that should already be done by 802.1x.
Solution
Create an RDP Certificate Template
1. On the domain CA Launch the Certification Authority Management Console > Certificates Templates > Right click > Manage.
2. Locate, and make a duplicate of, the Computer template.
3. General tab > Set the display and template name to RemoteDesktopSecure.
5. New > Name=SSL Secured Remote Desktop > Object Identifier=1.3.6.1.4.1.311.54.1.2 > OK.
6. Select the policy you have just created > OK.
7. Remove the other policies, so only the one we have just created remains > OK.
8. Security tab > Ensure that the the computer groups you want to apply the template to, are selected for Read and Enroll. (Below I’ve put three examples, firstly I create a group for my servers, secondly I just apply it to my domain controllers, or lastly I allow all Domain Computers). How you want to apply this depends on you.
9. Issue/Publish the new certificate template.
Create a GPO to secure RDP access with Certificates.
10. From the Group Policy Management Console, create (or edit) a GPO and give it a sensible name.
Locate the ‘Server authentication certificate template’ policy.
12. Enable it and set the template name to RemoteDesktopSecure > Apply > OK.
13. In the same location, locate the ‘Require use of specific security layer for remote (RDP) connections’ policy.
14. Enable the policy and set the security layer to SSL (TLS 1.0) > Apply > OK > Exit the policy editor.
15. Link the GPO to an OU that contains the servers you want to apply the policy to.
16. You may need to wait a short while, but eventually the servers will get their certificates.
Note: This view is simply ‘Microsoft Management Console’ with the ‘Certificates (Local Computer)’ snap-in added.
17. To prove it’s working, try connecting from a client that does not trust your Domain CA, and you should see an error something like this.
Check What Certificate RDP Is Using
You can check the thumbprint of the certificate the server is using. Windows Key+R > Regedit {Enter} > Navigate to;
[box]
HKEY_LOCAL_MACHINE
> SYSTEM > CurrentControlSet > Control > Terminal Server > WinStations > TemplateCertificate
[/box]
You can check this with the actual Certificate> Windows Key+R > mmc {enter} > File > Add/Remove Snap-in > Certificates > Local Computer > Open Certificates > Personal > Certificates > Locate the certificate you ‘Think’ RDP is using and you can compare its thumbprint with the registry key you found above.
Or you can execute the following PowerShell command to get the RDP certificates thumbprint;
Step 2 Configure Windows 2012 Server to allow RADIUS
7. On the Windows 2008 Server > Launch Server Manager > Roles > Add Role.
8. If you get a welcome page > Next > Select Network Policy and Access Server > Next >Next.
9. Select ‘Network Policy Server’ > Next > Install.
10. Close, when complete.
11. Whilst still in Server Manager > Network Policy and Access Server > NPS (Local).
12. Register Server in Active Directory >OK > OK.
13. Expand RADIUS Clients and Servers > Right click RADIUS Clients > New.
14. Give the firewall a friendly name, (take note of what this is, you will need it again) > Specify its IP > Enter the shared secret you setup above (number 5) > OK.
15. Expand policies > right click ‘Connection Request Policies’ > New > Give the policy a name > Next.
16. Add a condition > Set the condition to ‘Client Friendly Name’ > Add.
17. Specify the name you set up above (number 14) > OK > Next > Next > Next.
18. Change the attribute to User-Name > Next > Finish.
19. Now right click ‘Network Policies’ > New > Give the policy a name> Next.
20. Add a condition > User Groups > Add.
21. Add in the AD security group you want to allow access to > OK > Next > Next.
22. Select ‘Unencrypted Authentication PAPSPAP” > Next > No > Next > Next > Finish.
Step 3 Test RADIUS Authentication
23. Back at the ASDM, in the same page you were in previously, select your server and then click ‘Test’.
24. Change the selection to Authentication > Enter your domain credentials > OK.
25. You are looking for a successful outcome.
Note: if it fails check there is physical connectivity between the two devices, the shared secrets match. Also ensure UDP ports 1645 and 1646 are not being blocked.
To Test AAA RADIUS Authentication from Command Line
[box]
test aaa-server authentication PNL-RADIUS host 172.16.254.223 username petelong password password123
[/box]
26. Finally, save the firewall changes > File > Save running configuration to flash.
Related Articles, References, Credits, or External Links
Microsoft have released the Local Administrator Password Solution (LAPS). What is does is automatically change the load administrator password on workstations, (and servers if required) periodically. It then keeps those passwords securely in AD. Microsoft tried to mitigate attacks from the local admin account back in the days of Windows Vista by shipping with this account disabled, which is fine, but most large deployments I’ve worked on, I’ve been specifically asked to enable the local administrator account and set its password on deployment.
Some organisations create a different account and leave the local administrator account disabled, but they still suffer from the same problem, (all the machines have the same local admin password), and it gets known, if you have a disgruntled ex-employee they may know this password. Yes you can change them all periodically but it’s a bit of a faff. Note: LAPS can manage local accounts that are admin accounts but not necessarily the ‘administrator’ account.
The LAPS solution works by creating some new attributes on the computer object, ms-MCS-AdmPwd which actually stores the password, and ms-MCS-AdmPwdExpirationTime which is the time stamp for the password expiration. What LAPS sets out to do, is provide a random complex password for the local administrator account, and protect that password in AD by use of an ADACL. In doing so it will protect your machines from a ‘Pass the Hash’ attack which can use common local administrators passwords to compromise a network.
Solution
Microsoft LAPS – Step 1 Setup a Management Machine
1. On a management machine download and install the LAPS software, Things will be easier if this machine is also running RSAT tools for Active Directory, and the Group Policy Management Console as well.
2. Be aware you get the documentation form the download page as well. Make sure you get the appropriate x86 or x64 bit version (LAPS supports Server 2003 SP1 and above).
3. Install the software and install ALL the options. (if you apply the defaults it will only install the GPO Extensions), which is what you would want on the ‘controlled machines’ but you want everything on the ‘controlling machine’.
Microsoft LAPS – Step 2 Deploy the software to the machines to be controlled.
1. To be honest this could not be simpler, I just sent the software out as a standard software package via GPO, (watch the video above if you don’t know how to do that). You can script the install and it will also manually install with a /quiet switch to avoid any user interaction. But if you have any amount of machines, GPO is the way to go.
To manually install quietly;
[box]
msiexec /i \\Server\Share\laps.x64.msi /quiet
or simply
msiexec /i c:\laps.x64.msi /quiet
[/box]
2. To check if the client has received the LAPS software, look in Add/Remove programs and you should see it listed (Run > appwiz.cpl {Enter}).
Microsoft LAPS – Step 3 Extend Active Directory Schema
1. It goes without saying that to do this you need to be a member of ‘Schema Admins’. On the management machine run the following two PowerShell commands, to add the two new attributes mentioned above;
[box]
Import-Module AdmPwd.PS
Update-AdmPwdADSchema
[/box]
Microsoft LAPS – Step 4 Check/Set Permissions to Read Local Admin Passwords
1. On my test network below you can see I’ve got a couple of test Windows 8 machines in an OU called ‘Domain Computers’, this is the OU that I will be working with.
2. The first thing I need to do is grant the rights to the computers themselves to be able to update the password in Active Directory. (If you have nested OU’s, simply apply on the top level OU). Change the value in red to suit your own OU/OU’s.
3. To see who has rights to view the passwords in AD (for a given OU), use the following command. Below you can see the default of SYSTEM and Domain Admins is displayed.
4. To grant read password permissions to a particular group, use the following syntax, below I have an AD group called HelpDesk setup and I’m adding them into the ADACL to be able to read local administrator passwords for the Domain Computers OU.
Note: If you have multiple groups you can separate/delimit them with a comma.
Microsoft LAPS – Step 5 – Deploy the GPO Extensions to ‘Controlled’ Machines.
1. On the management machine, create a new GPO object, and link it to the OU containing the computers/servers you want to apply the password settings to.
4. The policy that turns LAPS on is the last one ‘Enable local admin password management’ > Enable it.
5. The actual complexity and age of the password is set in the ‘Password Settings’ policy, > Enable it and accept the defaults.
Note: the other two policies are;
Name of the administrator account to manage: Use if you you have manually created another common admin account on all your machines NOT if you have renamed the local administrator account.
Do not allow password expiration time longer than required by policy: Set to Enabled.
Microsoft LAPS – Step 6 – View the Local Admin Passwords for Controlled Machines.
1. You can do this from PowerShell with the following command;
Seen when trying to connect to the Exchange 2010 Management Console.
Initialization failed.
The following error occurred while searching for the on-premises Exchange server: No Exchange servers are available in any Active Directory sites. You can’t connect to remote Powershell on a computer that only has the Management Tools role installed. It was running the command ‘Discover-ExchangeServer -UseWIA $true -SuppressError $true -CurrentVersion ‘Version 14.1 (Build 218.15)”.
Solution
Even though it looks like it’s something pretty serious, it isn’t. You are simply logged on as a user that does not have the rights to run the management console.
This commonly happens when you logon to the Exchange server as the servers local administrator. You need to be logged on the the Exchange server as a user that is a member of the ‘Organization Management’ group.
Related Articles, References, Credits, or External Links