One requirement for my current Meteor project was that a user must login with their ActiveDirectory account. This means that Meteor must be able to authenticate against LDAP. In atmosphere there are already a few packages available which implement and support LDAP authentication. However, they are either outdated or difficult to configure. This is why I’ve decided to build my own custom login request handler for Meteor.
Make use of the PowerShell ActiveDirectory module always required to install the Remote Server Administration Tools.
That sucks! We want it as simple as executing a script.
The following scripts allows you to compare the group membership of two users.
Based on this Technet article I’ve developed a simple Active Directory backup tool with PowerShell.
What it does:
- Create a full snapshot from Active Directory
- Keep a daily, weekly and monthly snapshot
- Notify me if something failed (requires PowerShell PowerUp)
This post is part of my PowerShell PowerUp project.
The only way to deploy SharePoint default settings for site collections and sites manually is using predefined site templates or an ugly third party tool.
And in case you’ll do that with site templates it’ll cost a lot of the time to update settings which were already set.
However with PowerShell it’s possible to deploy SharePoint default settings automatically and it’s a lot easier than you might think.
Since SharePoint 2013 only supports claim based authentication I discovered that updates in SharePoint Active Directory groups do not take effect immediately.
Thanks to Ryan McIntyre there’s a simple fix for that issue.
By adjusting the lifetime of the claims token you can shorten the time it takes to update the Active Directory group changes.
I’ve tried many ways to assign permissions for an Active Directory group on a Exchange (2010) mailbox, but it’s simply not possible.
Fortunately nothing’s impossible with PowerShell.
The following script can handle this issue by:
It could happen that the directory sync service (DirSync) doesn’t sync the users UserPrincipalName correctly.
I had an issue where the UserPrincipalName from a user in the Office 365 windows azure directory has been made based on the user’s sAMAccountname. This wouldn’t be problem if as long the sAMAccountname is the as same as the UserPrincipalName, but as you can guess this is not everywhere the case.