Predica loves tech community!

Did you know about this? :) That’s true. Most of all people form Predica are engaged with technical community. We share knowledge on forums, conferences, blogs, etc. Instead of that, our Board support conferences organized by community. Below list where we speaking and support for the coming weeks:

  • Global Windows Azure Bootcamp 2014 Poland – 29th od Match, 2014 – Warsaw, Poland – Predica is main sponsor of the conference – pizzas, gadgets, first prize in the lottery, etc :) Tomek & Domnik will speaking about Windows Azure stuff! Darek is main organizer of the event and MC 😉
  • Cloud OS MVP Roadshow – 16th of April, 2014 – Warsaw, Poland – Predica is main sponsor of the conference – gadgets, first prize in the lottery, etc :) Darek is main organizer of the event and will be speaking about virtualization stuff in hybrid cloud context. Tomek, will speaking about how to federate identity between private and public cloud.
  • Cloud OS MVP Roadshow – 18th of April, 2014 – Gdańsk, Poland – Tomek, will be speaking about how to federate identity between private and public cloud.

See you on the conferences! Feel free to contact us :)

Directory Sync and Password Sync Cookbook – part 7 – Important FAQ

Hi, Andrzej (KAZM) again 😉 … with 7th part of Directory Sync and Password Sync – YES, that is the final! 😀

  1. Directory Sync and Password Sync Cookbook – part 1 – Overview and SSO Decisions
  2. Directory Sync and Password Sync Cookbook – part 2 – Preparation
  3. Directory Sync and Password Sync Cookbook – part 3 – UPN Sync Scenarios
  4. Directory Sync and Password Sync Cookbook – part 4 – Installation
  5. Directory Sync and Password Sync Cookbook – part 5 – Configuration and Operations
  6. Directory Sync and Password Sync Cookbook – part 6 – Troubleshooting
  7. Directory Sync and Password Sync Cookbook – part 7 – Important FAQ
  • In this article you use commands like “Set-MsolUserPrincipalName -UserPrincipalName oldUPN PrinciaplName newUPN” but it is not working for me. What is wrong?
    • To be able to run this and similar commands you need to connect to Windows Azure Active Directory through PowerShell:
      • Run PowerShell
      • Execute Import-Module MSOnline ,
      • $AdminCredentials = Get-Credential,
      • Type in your O365 Admininistrator credentials,
      • Run Connect-MsolService –Credential $cred,
      • And now you can run required command.
  • How can I add Alternative UPN Suffixes to my AD?
  • Is there any way I can install DirSync using my own SQL servers (I have high availability for databases, less SQL limitations and other cool features)?
  • Which users will be synchronized with DirSync?
    • DirSync does not synchronize accounts with User must change password at next logon option enabled,
    • DirSync will not sync passwords for users that are federated entities (have their UPN as public domain which is added and verified in O365 and converted to federated). Users can only be either SSO-enabled or Password Sync,
    • DirSync will sync all users from domain (unless OU/attribitues filtering is configured).
  • What is MSOL_AD_SYNC account?
    • This account has read and synchronization permissions to the Active Directory and is used for noticing password changes in your domain.
    • You should not change the password of that MSOL_AD_SYNC service account.
    • Important! If you force password changes (for example with a GPO) and MSOL_AD_SYNC account gets its password changed, you must run the Directory Sync Configuration Wizard again.
  • I have a different Password Complexity Policies in AD than in O365. Which one will be used?
    • Active Directory Password Complexity policy will override O365 password complexity policy.
  • After implementing DirSync what happens to current users that had been already created directly in the cloud?
    • Users created and managed in the cloud remain with cloud (not synchronized) password and are under subjected to cloud password complexity policy and will not be synchronized.
  • What is the default time of synchronization?
    • DirSync synchronizes users every 3 hours, Password Sync synchronizes password hashes every 3 minutes.
  • After 90 days users stopped synchronizing. What happened?
    • Your Office 365 Global Administrator account password, you used for configuring DirSync tool, has expired. Please refer to Preparation and then Troubleshooting part of this article on how to fix this.
  • Start-OnlineCoexistenceSync command doesn’t return anything in the Powershell session. Is that normal, is my synchronization working?
    • Yes, this is normal. If you see no errors, then probably everything is fine and miisclient starts running Management Agents.
  • What happens if the user is blocked or deleted in AD?
    • When the user is blocked or deleted in AD, after DirSync sync he/she is also blocked or deleted in O365.
  • Users with expired passwords in AD may be able to still login to O365 with old (expired) password. Why is this happening?
    • After account is synced to O365, its password is set to “never expire” and is synchronized only when the user changes password in AD. So if password expires in AD, but user doesn’t change it, it is still valid in O365.
  • Can I change passwords manually for users in Office 365? How?
    • If the user/administrator changes his/hers password in the cloud it will NOT get override after next Password Sync sync (3 minutes). Password will get changed only after you run manual full password sync (Set-FullPasswordSync command and FIM Synchronization Service restart) or after user changes password.
    • To change password in Office 365 manually run PowerShell command Set-MsolUserPassword -userPrincipalName user@yourdomain.onmicrosoft.com –ForceChangePassword $false -NewPassword “NewSecurePasswordHere”.
  • Is there any changelog or version realeas history for DirSync?
  • Is there any information on what attributes are synced by DirSync?

I hope you have enjoyed my cookbook :)

Best regards,

Andrzej (KAZM)

Directory Sync and Password Sync Cookbook – part 6 – Troubleshooting

Hi, Andrzej (KAZM) again 😉 … with 6th part of Directory Sync and Password Sync.

  1. Directory Sync and Password Sync Cookbook – part 1 – Overview and SSO Decisions
  2. Directory Sync and Password Sync Cookbook – part 2 – Preparation
  3. Directory Sync and Password Sync Cookbook – part 3 – UPN Sync Scenarios
  4. Directory Sync and Password Sync Cookbook – part 4 – Installation
  5. Directory Sync and Password Sync Cookbook – part 5 – Configuration and Operations
  6. Directory Sync and Password Sync Cookbook – part 6 – Troubleshooting
  7. Directory Sync and Password Sync Cookbook – part 7 – Important FAQ
  • General advices
  • IDfIX
    • Wen you run the IdFix, “Format” is displayed in the Error column for many objects. Solution: This issue occurs if the email address of the object is not a valid, publicly routed email address. If you are not planning to change AD suffixes, you can ignore it.
  • DirSync/Password Sync
    • During installation
      • Exception has been thrown by the target of an invocation”. Solution: add indicated in Event Viewer MSOL_AD_SYNC domain account to the local Administrators group of DirSync server and retry.
    • During synchronization
      • Missing-partition-for-run-step” when used filtering OUs for DirSync. Solution: if you have many child domains in your forest and you don’t want to synchronize from some of them so you just uncheck those domains, you will get this error. At least one OU in each domain must be checked for sync, so to avoid this error just create empty OU in each domain and then in filtering options select this OU only (no users will be synced),
      • Stopped-extension-dll-exception” during Windows Azure Active Directory Connector, Delta Import Delta Sync step in miisclient.exe. Solution: You have to change password of Office365 account that was used to configure DirSync (it has expired). After changing that password in Office365, set this account to have never expiring password (please refer to Preparation part of my article), Run Directory Sync Configuration Wizard on the desktop of DirSync server and provide new credentials of Administrator account and then restart FIM Sync Service. Also with this error you can get following entries in Event Viewer:
        • Event ID 0. The user name or password is incorrect. Verify your user name, and then type your password again GetAuthState() failed with -214718668 state. HResult:0. C(0x80048821)
        • Event ID 109. Failure while importing entries from Windows Azure Active Directory. Exception: Microsoft.oOnline.Coexistence.ProvisionException: The user name or password is incorrect. Verify your user name, and then type your password again.
        • Event ID 6803. The management agent “Windows Azure Active Directory Connector” failed on run profile “Delta Import Delta Sync” because the server encountered errors.

Directory Sync and Password Sync Cookbook – part 5 – Configuration and Operations

Hi, Andrzej (KAZM) again 😉 … with 5th part of Directory Sync and Password Sync.

  1. Directory Sync and Password Sync Cookbook – part 1 – Overview and SSO Decisions
  2. Directory Sync and Password Sync Cookbook – part 2 – Preparation
  3. Directory Sync and Password Sync Cookbook – part 3 – UPN Sync Scenarios
  4. Directory Sync and Password Sync Cookbook – part 4 – Installation
  5. Directory Sync and Password Sync Cookbook – part 5 – Configuration and Operations
  6. Directory Sync and Password Sync Cookbook – part 6 – Troubleshooting
  7. Directory Sync and Password Sync Cookbook – part 7 – Important FAQ

This part of DirSync and Password Sync articles describes most common operations you may be doing for DirSync and Password Sync implementation.

  1. Change default 3 hours DirSync scheduled run
    1. Navigate to C:\Program Files\Windows Azure Active Directory Sync\ ,
    2. Edit Microsoft.Online.DirSync.Scheduler.exe.config file,
    3. Change “3:0:0” in the key <add key=”SyncTimeInterval” value=”3:0:0″ /> in hh:mm:ss convention for scheduling next sync.
  2. Change UPN in O365
    1. When UPN is not publicly resolved, users with UPN @yourcompany.onmicrosoft.com suffix will be created in Office 365,
    2. Important! O365 Administrators can change @yourcompany.onmicrosoft.com UPNs in O365, but only to the newUPNs of the domains that are already added and verified in O365. Use PowerShell command Set-MsolUserPrincipalName -UserPrincipalName oldUPN PrinciaplName newUPN ,
    3. Users will use newUPN to sign in to the domain,
    4. Future DirSync synchronizations will not override manually set newUPN. However, if you have local UPN in AD and change UPN in O365 to newUPN and then you set AD UPN from local to public and then from public to local, the newUPN in O365 will get set to @yourcompany.onmicrosoft.com (because in AD it will be local and DirSync will detect changes after manual modification of newUPN).
  3. Manually run DirSync
    1. Run PowerShell console as Administrator,
    2. Change folder to C:\Program Files\Windows Azure Active Directory Sync\,
    3. Run .\DirSyncConfigShell.psc1 ,
    4. In new window, that is opened, execute Start-OnlineCoexistenceSync command,
    5. Verify synchronization is started
      1. Run C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe and view Operations tab
      2. Run Event Viewer and look for Event ID 0 with following details
        1. MA: Active Directory Connector Profile: Delta Import Delta Sync Result: success,
        2. MA: Windows Azure Active Directory Connector Profile: Delta Import Delta Sync Result: success,
        3. MA: Windows Azure Active Directory Connector Profile: Export Result: success.
      3. Run MOP and confirm that users have been synced.
  4. Manually run Password Sync
    1. Run PowerShell console as Administrator,
    2. Change folder to C:\Program Files\Windows Azure Active Directory Sync\,
    3. Run .\DirSyncConfigShell.psc1 ,
    4. Execute Set-FullPassword Sync command,
    5. Run services.msc and restart the FIM Synchronization Service on your DirSync server,
    6. In Event viewer you should see
      1. Event ID 656 (Password Sync Requests),
      2. Event ID 657 (Password Sync Results).
  5. Deactivate DirSync
    1. You can use Office 365 Portal (MOP) to deactivate DirSync,
    2. You can use Powershell command Set-MsolDirSyncEnabled –EnableDirSync $false.
  6. 6. Deactivate Password Sync
    1. To disable password sync just re-run the configuration wizard and uncheck the option Enable Password Sync.
  1. Directory Sync and Password Sync Cookbook – part 1 – Overview and SSO Decisions
  2. Directory Sync and Password Sync Cookbook – part 2 – Preparation
  3. Directory Sync and Password Sync Cookbook – part 3 – UPN Sync Scenarios
  4. Directory Sync and Password Sync Cookbook – part 4 – Installation
  5. Directory Sync and Password Sync Cookbook – part 5 – Configuration and Operations
  6. Directory Sync and Password Sync Cookbook – part 6 – Troubleshooting
  7. Directory Sync and Password Sync Cookbook – part 7 – Important FAQ

Directory Sync and Password Sync Cookbook – part 4 – Installation

Hi, Andrzej (KAZM) again 😉 … with 4th part of Directory Sync and Password Sync.

  1. Directory Sync and Password Sync Cookbook – part 1 – Overview and SSO Decisions
  2. Directory Sync and Password Sync Cookbook – part 2 – Preparation
  3. Directory Sync and Password Sync Cookbook – part 3 – UPN Sync Scenarios
  4. Directory Sync and Password Sync Cookbook – part 4 – Installation
  5. Directory Sync and Password Sync Cookbook – part 5 – Configuration and Operations
  6. Directory Sync and Password Sync Cookbook – part 6 – Troubleshooting
  7. Directory Sync and Password Sync Cookbook – part 7 – Important FAQ
  1. Download the latest version of DirSync
    1. From O365 portal
      1. Login to O365 as Administrator,
      2. Go to Users and groups,
      3. Click Setup next to the Active Directory Synchronization,
      4. You should see DirSync download button.
    2. Directly from here.
  2. Run installation
    1. Run installation file as AD Enterprise Admin (make sure to click run as administrator),
    2. During installation you will be asked to provide credentials
      1. Windows Azure Active Directory Administrator Credentials – which means Global Administrator in Office 365. Here you should enter credentials of the Office 365 Synchronization Service account which you created in Preparation part of my article,
      2. Windows Active Directory Enterprise Administrator Credentials – which means exactly what is says.
    3. Installation can take up to 15 minutes because Microsoft SQL Express 2012 SP1 will be installed locally on the server as a default database engine,
    4. Important! If you want to use your own SQL server, please refer to Important FAQ part of my article,
    5. If you encounter any problems, please see Troubleshooting part of my article.
  3. After DirSync is installed log on and log off from DirSync server so that new security token will be granted for your admin account.
  4. Run configuration wizard
    1. Make sure you select the Enable Password Synchronization option,
    2. Do not select Enable Hybrid Deployment on the Hybrid Deployment page, unless you want to sync some changes back from O365 to your Active Directory,
    3. Important! Do not select “Synchronize directories now” on the Finished page. We need to create some OU filtering, unless you want to synchronize all OUs in your forest,
    4. Some of common installation issues and errors are described in Troubleshooting part of my article.
  5. Configure users filtering based on
    1. OU filtering – described in Microsoft TechNet “Configure filtering for directory synchronization“. In short:
      1. Run C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe ,
      2. Click Management Agents,
      3. Double click Active Directory Connector,
      4. Click Configure Directory Partitions and on the right pane click Containers,
      5. Log in using Enterprise admin credentials (Enterprise, not Domain admin because this user can view the entire forest and perform the filtering within any domain within the forest),
      6. Select OUs you want to synchronize, click OK.
      7. If you have multi child domain forest, please refer to Troubleshooting part of my article,
      8. Important! You need to do Full Import and Full Sync, so right click on the Active Directory Connector, select Run and choose Full Import Full Sync, and then click OK.
    2. UPN domain suffixes
      1. If you want to set a filter based on UPN domain suffixes, please follow “DirSync filtering and UPN domain suffixes” article by Loryan Strant on how to achieve this.
  6. Run DirSync manually. Please refer to Configuration and Operations part of my article on how to do that.
  7. After configuration Password Sync performs automatic Full Sync of all users (actually, those who are in scope of DirSync filter).When users are synced, assign required licenses in O365.

Directory Sync and Password Sync Cookbook – part 3 – UPN Sync Scenarios

Hi, Andrzej (KAZM) again 😉 … with 3rd part of Directory Sync and Password Sync.

  1. Directory Sync and Password Sync Cookbook – part 1 – Overview and SSO Decisions
  2. Directory Sync and Password Sync Cookbook – part 2 – Preparation
  3. Directory Sync and Password Sync Cookbook – part 3 – UPN Sync Scenarios
  4. Directory Sync and Password Sync Cookbook – part 4 – Installation
  5. Directory Sync and Password Sync Cookbook – part 5 – Configuration and Operations
  6. Directory Sync and Password Sync Cookbook – part 6 – Troubleshooting
  7. Directory Sync and Password Sync Cookbook – part 7 – Important FAQ

Since users and passwords are synced to O365, users can easily login to O365 portal using their AD credentials. But do they?

Here is an outcome of the test I conducted with different UPN and E-mail attributes in Active Directory. In Office 365 I have fabrikam.com.pl domain added and verified.

Table below shows what would be O365 UPN (login for O365 user) depending on AD UPN and E-mail attributes:

No. AD UPN AD EMAIL O365 UPN
1 Andrzej
@local.domain
None Andrzej
@yourcompany.onmicrosoft.com
2 Andrzej
@local.domain
Andrzej.Kazmierczak
@local.domain
Andrzej.Kazmierczak
@yourcompany.onmicrosoft.com
3 Andrzej
@local.domain
Username
@gmail.com
Username
@yourcompany.onmicrosoft.com
4 Andrzej
@local.domain
Andrzej.Kazmierczak
@fabrikam.com.pl
Andrzej.Kazmierczak
@yourcompany.onmicrosoft.com
5 Andrzej
@fabrikam.com.pl
None Andrzej
@fabrikam.com.pl
6 Andrzej
@fabrikam.com.pl
Andrzej.Kazmierczak
@local.domain
Andrzej
@fabrikam.com.pl
7 Andrzej
@fabrikam.com.pl
Andrzej.Kazmierczak
@fabrikam.com.pl
Andrzej
@fabrikam.com.pl
8 Andrzej
@fabrikam.com.pl
Username
@gmail.com
Andrzej
@fabrikam.com.pl

Hmm, interesting. So what happens if we don’t have public UPN suffix (f.e.@local.domain) in AD and we have 2 users with different UPNs but the same email prefix name? See table below:

No. AD UPN AD EMAIL O365 UPN
1 Andrzej
@local.domain
Username
@gmail.com
Username
@yourcompany.onmicrosoft.com
2 Andrzej2
@local.domain
Username
@outlook.com
Not synced Error / Email from unhealthy Sync
3 Andrzej3
@local.domain
Username
@yahoo.com
Not synced Error / Email from unhealthy Sync

What will happen is that first user will get synchronized, but all the other users with same email prefix (Username in example above) name will not be synced and error will be recorded in Event Viewer as well Office 365 Global Administrators will receive emails with unhealthy sync information.

Based on above, ask yourself wouldn’t it be better for your company to change AD UPN suffixes to public ones?

Directory Sync and Password Sync Cookbook – part 2 – Preparation

Hi, Andrzej (KAZM) again 😉 … with 2nd part of Directory Sync and Password Sync.

  1. Directory Sync and Password Sync Cookbook – part 1 – Overview and SSO Decisions
  2. Directory Sync and Password Sync Cookbook – part 2 – Preparation
  3. Directory Sync and Password Sync Cookbook – part 3 – UPN Sync Scenarios
  4. Directory Sync and Password Sync Cookbook – part 4 – Installation
  5. Directory Sync and Password Sync Cookbook – part 5 – Configuration and Operations
  6. Directory Sync and Password Sync Cookbook – part 6 – Troubleshooting
  7. Directory Sync and Password Sync Cookbook – part 7 – Important FAQ

If you decided to go for DirSync with Password Sync option, then you need to do some preparations:

  1. Check and verify your environment
    1. AD Forest: Windows Server 2003 forest functional level or higher,
    2. Domain controller: 32-bit or 64-bit Windows Server 2003 Standard Edition or Enterprise Edition with Service Pack 1 (SP1) or higher,
    3. Important! If you have multi child domains forest please refer to Troubleshooting part of this article.
    4. Important! DirSync doesn’t support AD forest trust between different forests. It is a Microsoft Forefront Identity Manager (FIM) scenario. So, one DirSync per one forest.
  2. DirSync Server
    1. Windows Server 2008 R2 SP1 or higher. Recommended Windows Server 2012 R2 for the time of writing this article,
    2. Domain joined,
    3. Installed .NET 3.5 SP1 and .NET 4.0,
    4. Microsoft recommended that you cannot install DirSync on a Domain Controller. But since the version 6553.0002 release of DirSync it is possible.
    5. Important! You must be running version 6382.0000 or greater of the Directory Sync tool in order to enable the Password Sync feature.
  3. Add Alternative UPN suffixes to the domain (depends if your organization can do that in terms of different business policies)
    1. UPN suffix for users in AD, as current recommendation, should be set to public (publicly resolvable) and should be the same suffix as you have your public domain verified in Office 365 (f.e. user@fabrikam.com.pl),
    2. Important! If UPNs don’t have public suffix, users will be created in Office 365 with @yourcompany.onmicrosoft.com UPN suffix. Please read UPN Sync Scenarios part of this article to better understand this situation,
    3. Please refer to Important FAQ part of this article to see how to set alternative UPN Suffixes in AD.
  4. Prepare O365 service account that will be used for synchronization
    1. Login to Microsoft Office 365 Portal (MOP) as administrator,
    2. Create new user (f.e. DirSyncSvcAcct) and do not assign any Office 365 license to that account,
    3. Assign Global Administrator rights to that DirSyncSvcAcct account,
    4. Login to MOP using that account with temporary password that was generated,
    5. Change the password using new, strong password,
    6. Log off and log on making sure that new password is working,
    7. Set NeverExpire attribute to that account
      1. Run PowerShell and connect to Office 365 (howto described in Important FAQ part of this article),
      2. Execute command Set-MsolUser -UserPrincipalName DirSyncSvcAcct@yourdomain.onmicrosoft.com -PasswordNeverExpires $true,
      3. Execute command Get-MsolUser -UserPrincipalName DirSyncSvcAcct@yourdomain.onmicrosoft.com | fl ,
      4. Make sure that this account has attribute PasswordNeverExpires set to True.
  5. You need to know credentials for
    1. Active Directory Enterprise Administrator,
    2. Office 365 service account with Global Administrator permissions – the one, you have created in previous steps.
  6. If your O365 domain is already federated and is using ADFS SSO, you need to switch it back to standard domain
    1. Important! Be careful with that. Plan some downtime carefully, because users will get converted and will get new passwords generated automatically, which means they cannot login until Password Sync syncs passwords for the first time.
    2. Use “AAD Sync: How To Switch From Single Sign-On To Password Sync” Microsoft TechNet article.
      1. In short: execute Convert-MSOLDomainToStandard DomainName &lt;federated domain name&gt; -SkipUserConversion $false -PasswordFile c:\user_passwords.txt command.
    3. If you run on any problems, try re-runnig above command. Alternatively you can use “Sample script to manually convert all users in a domain” from “AAD Sync: How To Switch From Single Sign-On To Password Sync” site to manually convert users.
  7. Use AD remediation tool called IdFix that will simulate DirSync sync process and will display errors requiring remediation within your AD
    1. Use “IdFix DirSync Error Remediation Tool” site for System Requirements and Download,
    2. Use Office 365 – IdFix DirSync Error Remediation Tool” artictle by Benoit HAMET on how to Install and use IdFix,
    3. If you find issues please refer to Troubleshooting part of my article.
  8. Activate Directory synchronization in Office 365 through
    1. Web
      1. Login to O365 as Administrator,
      2. Go to Users and groups,
      3. Click Setup next to the Active Directory Synchronization,
      4. Under Activate Active Directory Synchronization click Activate,
      5. Once again click Activate in popup window,
      6. It should be activated in matter of few minutes – check status on the Office365 portal (Users and Groups).
    2. PowerShell
      1. Execute Set-MsolDirSyncEnabled -EnableDirSync $true command.

Directory Sync and Password Sync Cookbook – part 1 – Overview and SSO Decisions

Hi, Andrzej (KAZM) here with some stuff about Directory Sync and Password Sync – enjoy 😉

  1. Directory Sync and Password Sync Cookbook – part 1 – Overview and SSO Decisions
  2. Directory Sync and Password Sync Cookbook – part 2 – Preparation
  3. Directory Sync and Password Sync Cookbook – part 3 – UPN Sync Scenarios
  4. Directory Sync and Password Sync Cookbook – part 4 – Installation
  5. Directory Sync and Password Sync Cookbook – part 5 – Configuration and Operations
  6. Directory Sync and Password Sync Cookbook – part 6 – Troubleshooting
  7. Directory Sync and Password Sync Cookbook – part 7 – Important FAQ

Password Sync is an alternate solution to ADFS SSO (Active Directory Federated Services Single Sign On). With ADFS SSO, only Windows Azure Active Directory (WAAD) Synchronization tool called Directory Synchronization (DirSync) is used to synchronize users to Microsoft Office 365 (O365). Having federated domain in the cloud, users are authenticating through ADFS servers directly to Active Directory where their accounts and passwords are kept.

Password Sync is a feature of DirSync tool and does not need ADFS infrastructure to be running – it synchronizes both users’ accounts along with users’ passwords to O365. That means that authentication takes place in the cloud (not in AD) and users are not redirected to Active Directory (as they do when ADFS’s in place). For better understanding, please take a quick look on Microsoft Directory Sync with Password Sync Scenario TechNet site.

So in short, Password Sync does password synchronization. Well, not exactly passwords, but passwords hashes are synced, so passwords are never sent in a plain text (reversed form) nor known to Microsoft. Actually, you can read more about How Secure is DirSync with Password Synchronization? by Alan Byrne.

One can recognize some pros and cons of having ADFS over Password Sync. Just quick bullets about questions you can think of to be asked to you/your client:

  1. Review your requirements and business plans for the next year (are you going to migrate entirely to Office365?, etc.).
  2. Think and compare DirSync with Password Sync vs. ADFS over your requirements. Some advantages and disadvantages of ADFS and Password Sync are presented below
    1. ADFS
      1. Requires additional infrastructure, efforts to implement and preparation, f.e.:
        1. Load Balanced ADFS Servers (in case one of them crashes, you lose access to your federated assets, so they’d better be load-balanced),
        2. Load Balanced ADFS Proxy (In Windows Server 2012 R2 called Web Application Proxy) Servers (those are required to be standing in DMZ and act as a proxy to/from ADFS servers),
        3. Public SSL certificate (Thawte, GoDaddy, VeriSign, Entrust, etc.) needs to be bought for ADFS communication certificate. SAN certificate in case you want to use Device Registration Service in W2K12 R2. Wildcard is also fine.
      2. Infrastructure is another point of failure and needs to be managed (administrative overhead),
      3. Can give you better experience for SSO (users logged in on premise domain in corporate network are not asked to re-enter their passwords). Visit ADFS/SSO versus Password Sync End User Experience for Office 365 page for more information,
      4. Can be used to implement more federation-dependent tools and features, f.e.:
        1. Usage of Workplace Join feature,
        2. You can federate with Microsoft Access Control Service (free Microsoft service) and login using Facebook, Windows LiveID (sorry, Microsoft Account – Your Windows Live ID is your Microsoft account), Google or Yahoo.
      5. Can control client access filtering based on Active Directory attributes sent in security tokens,
      6. Has better support for Multi Factor Authentication (MFA).
    2. Password Sync
      1. Good option to choose when migrating entirely to the cloud – just leave no physical servers on premise behind you,
      2. Authentication takes place in O365, users are not redirected to login in AD through ADFS servers,
      3. Costs you less effort to implement,
      4. Once set, should not cause big problems in future,
      5. Users have to change their passwords in Active Directory and cannot change them online,
      6. Supports single forest scenarios only (as for now – December 2013).

Approach to security hardening the Microsoft Server Stack

So you just deployed your brand new Microsoft infrastructure hosting your critical application, be it in the Public Cloud, leased infrastructure or in your own datacenter. You configured all your servers and application and are ready to publish it for external access (either authenticated or anonymous).

Microsoft Server products are established in the corporate, intranet networks, but still relatively less existent in the internet/extranet space.

How do you approach hardening of the Microsoft Server stack? What process do you follow? What tools do you use? How do you test and validate your setup?

This blog post aims to give you a few general hints and guidelines how you can with a few simple steps, increase your Windows Server security.

General approach

The approach we have used with success with many of our customers boils down to 3 main things:

  • Holistic (‘360’) approach to security. Examples: even if you have top notch security configuration on your servers, but the servers are not physically secure, any person can crack the password/encryption given enough time with the machine. Security must be implemented at all layers
  • Technology is one thing, but you also need to take care of the people (their knowledge, skills, team work) and process (procedures in place that ‘shape’ the proper people behaviour)
  • Verify/test! Even if you plan and execute the most security plan, you need to verify by running extensive tests (e.g. penetration/attack surface analysis) – ideally before and after applying your security plan

Technical details

Below I provide several points which are worth taking into account when building your security plan.

For hardware security ensure:

For Windows Server stack security hardening do not forget:

  • Up-to-date kernel (ensure responsive patching procedure)
  • Enable ONLY required roles and services
  • Once this is done, disable unused services – e.g. for a standalone (or domain-joined) web server we were able to disable 42 base windows services w/o any impact on the functionality of the webserver
  • Unbind unnecessary protocols from the network interfaces – most often you will only TCPIP (v4 or v6) and (if you need it) file and printer sharing
  • Disable netbios on your TCPIP properties of network connection
  • Change the default RDP port (http://support.microsoft.com/kb/306759) and enforce Network Level Authentication (NLA)
  • Enable and configure Windows Firewall – you can disable most out-of-the box enabled rules (except RDP – if you use it, and not some other remote connectivity tool) and your application traffic
  • Optimize your security via local or domain group policy (follow links below for guidance on recommended settings, esp. CIS) – definitely focus on enforcing NTLMv2, password/account policies, user rights assignment and audit policies
  • Enable UAC
  • Enable IE Enhanced Security Configuration, or even disable IE and other programs via Software Restriction Policies in GPO
  • Ensure only 2-3 people (with dedicated accounts) are members of local administrators
  • Rename the default administrator account and create a decoy administrator account (http://technet.microsoft.com/en-us/library/cc700835.aspx)
  • Ensure you are able to get the most out of your auditing, with tools like Dell/Quest ChangeAuditor (http://www.quest.com/changeauditor/)
  • Harden your TCPIP stack – disable automatic admin shares (e.g. C$), disable SSLv2, you might want to decrease default TTL, Disable ICMP redirect. The TCPIP stack since WS2008 is much more secure by default than 2003, but you still can make a few tweaks
  • And much more… Contact us if you are interested in securing your Microsoft-based business applications :)

In the area of network, take into account:

Tools and links

These are the tools I found quite useful:

FIM 2010 authorization workflow fails with EventID 3

If there is software, there have to be a bug. FIM 2010 as nice platform for identity management projects is not free from bugs of course, we have to live with them, wait for fixes to come and sometimes get to know how to handle them. This one is the latter case.

Story …

One of nice features of FIM is possibility to use approval activity to construct approval processes for user actions in FIM service. As every consultant working with FIM I can easily come with few things I would improve in approval activity, but this doesn’t change the fact, that this is easy to use and fast way to build approval workflows. If you will combine it with a little of custom activities it can be used even in a cases as dynamically calculated approvers based on conditions or conditional approval based on result some condition check (just two examples how we use it).

While working on rather simple case of approval for user actions I came across a problem that my approval activity stopped to work and on every instance of request I’ve got “Access Denied” because my workflow failed with exception “Object reference not set to an instance of an object“.

On FIM Service in Event Log I’ve found Event ID 3 which was caused by this exception, but with not a lot more details.

(…)

Error message from Event ID 3:

Microsoft.ResourceManagement.Service: System.NullReferenceException: Object reference not set to an instance of an object.

at Microsoft.ResourceManagement.Workflow.Hosting.HostActivator.ActivateHost(ResourceManagementWorkflowDefinition workflowDefinition, Boolean suspendWorkflowStartupAndTimerOperations)

at Microsoft.ResourceManagement.Workflow.Hosting.WorkflowManager.StartWorkflowInstance(Guid workflowInstanceIdentifier, KeyValuePair`2[] additionalParameters)

(…)

Getting to the source …

Troubleshooting of built-in activities is a bit troublesome, if not say that there is no option for that. Custom activities are rather easy to troubleshoot with debugger however here out options are limited. Only option was to try to narrow down possible causes for this error.

This particular workflow has used mix of custom and built-in activities, as first step for troubleshooting I’ve started to troubleshoot and finally remove from workflow custom activities to exclude possible bug in my code.

Troubleshooting Tip Of the Day

It is generally good idea to start to narrow down the area you are troubleshooting if you are experiencing problem in your solution, code, network. Removing elements of a solution and then adding them again will greatly improve ability to find element which is causing a problem. This might be custom activity, network load balancer or load balancing in general etc.

Quickly I’ve found out that this workflow is failing even with only single, built-in activity. So my code was OK. What was wrong then?

At Predica we are using scripts to deploy our FIM solution and this was not a different case. This solution was deployed from the script including this workflow definition. However as this was development environment, later I was testing some change introduced manually to this workflow. And this was it. After re-deploying this workflow from the script and later editing workflow definition in FIM portal problem occurred again.

Quick XOML comparison showed a problem – there was single difference between original versions:

(…)

xmlns:ns1=”clr-namespace:System.Workflow.Activities;Assembly=System.WorkflowServices, Version=3.5.0.0

(…)

And version altered in FIM portal:

(…)

xmlns:ns1=”clr-namespace:System.Workflow.Activities;Assembly=System.WorkflowServices, Version=4.0.0.0,

(…)

It looks like this behaviour happens only when FIM portal is deployed together with Sharepoint 2013

And now … workaround.

Workaround for this behaviour is simple but not very convinient to use if you want to do this through portal. In order to fix this situation you need to edit XOML definition of workflow (XOML is actually description of your workflow) and  find following piece of definition:

(…)

xmlns:ns1=”clr-namespace:System.Workflow.Activities;Assembly=System.WorkflowServices, Version=4.0.0.0,

(…)

Now you have to replace version of .NET in this reference to 3.5.0.0

(…)

xmlns:ns1=”clr-namespace:System.Workflow.Activities;Assembly=System.WorkflowServices, Version=3.5.0.0

(…)

In order to get to XOML you can open your workflow definition and click “Advanced view” button. XOML workflow definition can be found on “Extended attributes” page. You can safely copy it out of there to your text editor of choice (try SublimeText – my editor of choice for such things).

What is less fortunate is that you will have to do this every time your authorization workflow will be edited through FIM portal. One more reason why to script all configuration tasks in FIM – PowerShell really helps with this task.