Group Won’t Accept Mail From ‘Outside’

KB ID 0001771

Problem

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.

Allow External Senders Office/Microsoft 365 (Exchange Online)

Classic Exchange Admin Center

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

NA

Exchange 2000 / 2003 – Exporting Mail to .pst files with ExMerge

KB ID 0000091

Problem

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).

2. Use Outlook 2007 (or greater) to export the mailbox to .pst files individually.

Related Articles, References, Credits, or External Links

Download ExMerge 

Exchange 2010 Bulk Import .pst Files

Exchange 2007 – Export Mailbox’s to PST files

Adding Duo 2FA to Microsoft ADFS

KB ID 0001656

Problem

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;

Duo: ADSync and Enroll Users via SMS

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;

[box]

$bytes = new-object "System.Byte[]" 30
(new-object System.Security.Cryptography.RNGCryptoServiceProvider).GetBytes($bytes)
[Convert]::ToBase64String($bytes)

[/box]

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.

[box]

HKEY_LOCAL_MACHINE\SOFTWARE\Duo Security\DuoAdfs\AKey

[/box]

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).

[box]

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self'; frame-src api-xxxxxxxx.duosecurity.com"

[/box]

Launch the ADFS Management Console > Authentication Methods > Additional Authentication Methods > Edit.

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

NA

Unable to Connect to the Synchronisation Service

KB ID 0001649

Problem

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

NA

Cisco FirePOWER Management Center Appliance – Allowing Domain Authentication

KB ID 0001117 

Problem

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

Original Article Written 18/12/15

SQL Install Error “SQL Server Browser Service Group Does Not Exist”

KB ID 0000689 

Problem

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.

2. Create two Windows security groups called;

[box]

SQLServer2008SQLBrowserUser${ServerName}
SQLServer2005SQLBrowserUser${ServerName}

[/box]

3. Retry the install.

Related Articles, References, Credits, or External Links

NA

Windows Server – Secure RDP Access with Certificates

KB ID 0000944

Problem

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.

4. Extensions tab > Application Policies > Edit > Add.

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.

11. Edit that policy and navigate to;

[box]

Computer Configuration> Policies >Administrative Templates > Windows > Components > Remote Desktop Services >Remote Desktop Session Host > Security.

[/box]

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;

[box]

Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices

[/box]

Related Articles, References, Credits, or External Links

NA

Windows Server 2008 R2 – Configure RADIUS for Cisco ASA 5500 Authentication

KB ID 0000688

Problem

Last week I was configuring some 2008 R2 RADIUS authentication, for authenticating remote VPN clients to a Cisco ASA Firewall.

I will say that Kerberos Authentication is a LOT easier to configure, so you might want to check that first.

Solution

Step 1 Configure the ASA for AAA RADIUS Authentication

1. Connect to your ASDM, > Configuration > Remote Access VPN. > AAA Local Users > AAA Server Groups.

2. In the Server group section > Add.

3. Give the group a name and accept the defaults > OK.

4. Now (with the group selected) > In the bottom (Server) section > Add.

5. Specify the IP address, and a shared secret that the ASA will use with the 2008 R2 Server performing RADIUS > OK.

6. Apply.

Configure AAA RADIUS from command line;

[box]

aaa-server PNL-RADIUS protocol radius
aaa-server PNL-RADIUS (inside) host 172.16.254.223
  key 123456
  radius-common-pw 123456
  exit

[/box]

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 PAP SPAP” > 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

Windows Server 2003 – Configure RADIUS for Cisco ASA 5500 Authentication

Windows Server 2012 – Configure RADIUS for Cisco ASA 5500 Authentication

Microsoft LAPS – Deployment and Configuration

KB ID 0001059 

Problem

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 AD ACL. 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.

[box]Set-AdmPwdComputerSelfPermission -OrgUnit ‘Domain Computers‘[/box]

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.

[box]Find-AdmPwdExtendedRights -Identity ‘Domain Computers‘[/box]

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 AD ACL to be able to read local administrator passwords for the Domain Computers OU.

[box]Set-AdmPwdReadPasswordPermission -Orgunit ‘Domain Computers‘ -AllowedPrincipals PeteNetLiveHelpDesk[/box]

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.

2. Edit the GPO.

3. Navigate to;

[box]Computer Configuration > Policies > Administrative Templates > LAPS[/box]

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;

[box]Get-AdmPwdPassword -ComputerName hostname[/box]

2. Or if you have installed the Fat client, you can launch that from; [box]C:\Program Files\LAPS\AdmPwdUI.exe[/box]

3. Or as it’s an AD object attribute, you can view it on the Computers AD object.

Related Articles, References, Credits, or External Links

NA

Exchange 2010 – No Exchange servers are available in any Active Directory sites

KB ID 0000658 

Problem

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

Cannot Access Exchange 2010 Management Console