Geek projects, tidbits and things I'm working on at the moment…

Well, I haven’t written anything in a while so I figured I’d put this into WP. I recently upgraded a couple of my iOS devices to 8.4 and sure enough, I couldn’t send emails. Come to find out, my services at home were using weaker DH encryption and I needed to fix them if I wanted to send email ever again from my iPhone.

First I worked on sendmail. I needed to first create a DH 2048 bit file using openssl:

openssl dhparam -out dh_2048.pem -2 2048

This produced a file in my /etc/pki/tls/certs folder which I can now configure sendmail.mc to use via adding this line:

define(`confDH_PARAMETERS', `/etc/pki/tls/certs/dh_2048.pem')

Next you can do a ‘make -C /etc/mail’ or simply restart sendmail as it will detect the changes and do it for you (did for me at least.) Email was now working as expected and I’m no longer seeing this in my /var/log/maillog folder:

Aug 1 11:01:10 Sauron sendmail[11796]: t71F0eh9011796: 89.sub-70-197-133.myvzw.com [70.197.133.89] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Aug 1 11:01:11 Sauron sendmail[11803]: STARTTLS=server, error: accept failed=0, SSL_error=5, errno=0, retry=-1
Aug 1 11:01:11 Sauron sendmail[11803]: t71F1Ae8011803: 89.sub-70-197-133.myvzw.com [70.197.133.89] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Aug 1 11:01:11 Sauron sendmail[11804]: STARTTLS=server, error: accept failed=0, SSL_error=5, errno=0, retry=-1
Aug 1 11:01:11 Sauron sendmail[11804]: t71F1BBU011804: 89.sub-70-197-133.myvzw.com [70.197.133.89] did not issue MAIL/EXPN/VRFY/ETRN during connection to TLSMTA

Now to take a look at Apache. I’m using an older version, I think 2.2.3-91 w/ CentOS so there’s only so much I can do regarding MITM attacks apparently. But I can explicitly tell Apache to NOT use weaker encryption protocols even though I can’t use the SSLOpenSSLConfCmd DHParameters “{path to dhparams.pem}” option and specify my DH key.

Here’s what I did put in my ssl.conf file:

SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder on

Which will at least help for now.

Here’s a couple of useful links:

https://weakdh.org/sysadmin.html
http://serverfault.com/questions/700655/sendmail-rejecting-some-connections-with-handshake-failure-ssl-alert-number-40
http://weldon.whipple.org/sendmail/wwstarttls.html
http://serverfault.com/questions/693241/how-to-fix-logjam-vulnerability-in-apache-httpd
http://appleinsider.com/articles/15/07/10/how-to-resolve-mail-smtp-errors-in-os-x-10104-and-ios-84

This  is the second part of our Office 365 migration issues in hopes someone will find it helpful. When we were upgraded previously from the 2007 series of software to the 2010 series I had to make some changes to AD groups so they wouldn’t show up in Microsoft’s BPOS admin portal. Back then, they filtered your AD security groups in 3 different ways.

SecurityEnabledGroup objects are filtered if:

• isCriticalSystemObject = TRUE
• mail is present AND DisplayName isn’t present
• Group has more than 15,000 immediate members

So I went about adding bogus email addresses to all of the groups that were showing up (roughly 50 or so.) No biggie, it worked….back then!

Now that I’ve upgraded to Windows Azure Dirsync w/ password sync, all of those groups that I painstakingly modified so they would be filtered out of BPOS now are imported automagically as “MailEnabled Security Groups” YAY! Needless to say, I didn’t want them to appear in the GAL so I had to take some steps to get them out of Office 365.

Now Office 365 filters SecurityEnabledGroups like so…

SecurityEnabledGroup objects are filtered if:

• isCriticalSystemObject = TRUE

And that’s it!

Like I said previously, my big concern was removing them from the GAL so I went back through my AD Groups and removed all of the bogus email addresses and figured I was done. Not so fast! Upon the next sync, all of those groups were still present in the GAL but their email address’s had changed from SomeBogusGroup@example.com to SomeBogus@EXAMPLE.onmicrosoft.com . Because the groups were still considered MailEnabled Security Groups, Office 365 reverts them back to your default domain email address and also changes the first half of the email address, the local part, to match the group name. Example: I gave the AD group “AccountingOnly” an email address of accountonlygroup@example.com. This way I knew I won’t have to worry about duplicate email addresses. When I removed the email address from AD, Office 365 filled it in with accountonly@EXAMPLE.onmicrosoft.com. Bottom line, it was still showing up in the GAL and I wanted it gone. So, I had to do it via PowerShell like so.

Connect-MsolService
Get-MsolGroup -ALL

This showed me all of the groups I had in Office 365. You can see the AD groups Dirsync uploaded as MailEnabledSecurity groups along with other groups that didn’t have an email address which appeared as just Security groups and also Distribution List groups. After scouring the MailEnabledSecurity groups to make sure they were all the ones I wanted gone, I simply did…

Get-MsolGroup -GroupType MailEnabledSecurity | Remove-MsolGroup -Force

This way I wasn’t being prompted to yes/no/suspend the operation for each one.

Once that was done, I changed the registry HKLM\SOFTWARE\Microsoft\MSOLCoExistence key “FullSyncNeeded” to 1 and issued a PS command of Start-OnlineCoexistenceSync which made it do another Dirsync right then. Surprisingly, the AD groups I just removed weren’t showing back up in Office 365 right away. It took another full Dirsync about 24+ hours later for all of the groups that were removed to show back up and this time they showed up as only Security groups not MailEnabled Security groups.

Also, if you’re like me, you’ll want to watch the Dirsync as it’s happening so open up your miisclient.exe which can be found in C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell directory.

Here’s a bunch of links for more info:

http://support.microsoft.com/kb/2256198#How (MS’s website which shows how Azure does its’ filtering. To me, this isn’t accurate any longer.)

http://community.office365.com/en-us/wikis/sso/filter-support-in-the-microsoft-online-services-directory-synchronization-tool.aspx (Office 365 wiki link which shows how it filters now. Here you can clearly see they’ve changed filtering.)

http://community.office365.com/en-us/wikis/sso/default.aspx (Same Office 365 wiki but the main Directory Integration Services area.)

http://community.office365.com/en-us/wikis/sso/office-365-dirsync-content-map.aspx (Main Dirsync content map page.)

http://support.microsoft.com/kb/2508722 (KB page on “Mail-enabled groups that have an email address aren’t synchronized to Office 365” why couldn’t I have THAT problem!)

http://support.microsoft.com/kb/2709902 (KB page on “Object that’s deleted from the on-premises Active Directory isn’t removed from Windows Azure AD after directory synchronization” talks about using PowerShell to remove them from Office 365 manually.)

http://technet.microsoft.com/en-us/library/jj151771.aspx#BKMK_SynchronizeDirectories (Force Dirsync page via PowerShell.)

http://technet.microsoft.com/en-US/library/dn194137.aspx (TechNet page on the Remove-MsolGroup PowerShell command.)

http://www.amdocorp.com/Pages/Removedeletedmailbox.aspx ( Alian’s page which shows using pipes FTW!)

http://technet.microsoft.com/en-us/library/dn194130.aspx (TechNet page on Get-MsolGroup PowerShell command. This command didn’t play nice for some reason when I used it.)

This post is out of sequence but I told myself I’d throw it up while it’s still fresh. About a month ago I redid my entire email server from scratch when I started having some hardware issues. This post is on one of those bug-a-boos of switching from a physical server to a virtual world. TIME. Seems keeping vmguests synchronized with the correct time is an issue and wrecks havoc upon Dovecot (even when vmware tools are installed!) So, one of solutions was to not only install the vmware tools on my vmguest but to also install ntpd. This is good and bad…

  See, ntpd checks the time rather frequently and all it takes is a sync of > 75 seconds and Dovecot kills itself. Thankfully, it left a message in the log file.

dovecot: Time just moved backwards by 109 seconds. This might cause a lot of problems, so I’ll just kill myself now. http://wiki.dovecot.org/TimeMovedBackwards: 1 Time(s)

The URL provided in the error message was very illuminating and gave some recommendations from there. I installed the script that used lsof and was pretty much good to go. I did a couple of tests to ensure it wasn’t just restarting it once per minute then did the old crontab -e command and placed the script in the root’s cron jobs file stored at /var/spool/cron/root. Life is good. I’ve always been a big fan of netstat but lsof also gives some very valuable information on tracking down rogue issues.