Tuesday, September 4, 2012

Office 365, PowerShell and passwords

Since, as I know, most of us are familiar with Office 365, and maybe even using it. But most of us never do things than what the Office 365 Management site gives us. But then comes this day when you are assigned to do the things we can't do with the management service, like it happened to me.
Today I was asked to set the user passwords to some of our customers to never expire. Quite simple task in Active Directory if you ask me, but that's not the case in Office 365. You have to do this in PowerShell.
So I'll brick this post in two: The first part will show you how to connect to Exchange online in Office 365 using PowerShell, and the second will show you how to set the passwords to never expire.
I also encourage any system administrators to get more familiar with PowerShell and at least get the basic idea behind it. It will greatly assist you in understanding the principles of today ways of administration.

Instead of letting you dig trough this page at microsoft (link), I'll tell you what you need.
First, install Microsoft Online Services Sign-in Assistant:
32-bit
64-bit

Second, Install the Microsoft Online Services Module for Windows PowerShell:
32-bit
64-bit

Now, find and open Microsoft Online Services Module for Windows PowerShell from the start menu.


Enter this command after:
$LiveCred = Get-Credential
Enter your Office 365 Admin credentials (full email address and password).


This command will create a new PowerShell parameter $LiveCred with the credentials you are going to connect with. After that enter this command:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
This will create a new parameter $Session with the connection parameters.  > 
  Now let's open a new session:
Import-PSSession $Session

And connect to Office 365:
Connect-MsolService -Credential $LiveCred

Finally we're ready to execute the commands to Office 365.

Warning! Be careful with what you type, the below cmdlet's can cause you a lot of trouble!

Let's see our issue with passwords:
Get-MSOLUser | Select UserPrincipalName, PasswordNeverExpires
 
You can see a table with the username and a PasswordNeverExpires state (I have blanked the usernames). Some of them are blank, and some of them are set to false. Both of them means that the password is set to expire. So let's change it to never expire.

You can either make it per user:
Set-MsolUser -UserPrincipalName -PasswordNeverExpires $true
Change to the user name (usually email address).
or all users:
Get-MSOLUser | Set-MsolUser -PasswordNeverExpires $true

change $true to $false if you want to set it to expire again:
One user -
Set-MsolUser -UserPrincipalName -PasswordNeverExpires $false
All users -
Get-MSOLUser | Set-MsolUser -PasswordNeverExpires $false

But we're not done yet!
Yes, we've made our changes, but we must not forget to close the session. As said on this page:
If you close the Windows PowerShell window without disconnecting from the server-side session, your connection will remain open for 15 minutes. Your account can only have three connections to the server-side session at one time.
Here's how we close our session:
Remove-PSSession $Session
$session is the parameter name we set when created the session.

Now we're done.
Hope it helped you guys!

Monday, September 3, 2012

Aboundex bot

It's my first post with some story that may help you. So enjoy!
In the last month or so, I have encountered a lot of bots (around a thousand) scraping a forum I'm admin in. After some digging, I've seen that the most of the bots come from 173.192.x.x segment.
I went to a "whois" site which suggested that the segment is part of softlayer data centers:
NetRange:       173.192.0.0 - 173.193.255.255
CIDR:           173.192.0.0/15
OriginAS:       AS36351
NetName:        SOFTLAYER-4-8
NetHandle:      NET-173-192-0-0-1
Parent:         NET-173-0-0-0-0
NetType:        Direct Allocation
Comment:        SoftLayer provides on-demand IT infrastructure, dedicated servers and cloud resources.
RegDate:        2009-07-21
Updated:        2012-03-09
Ref:            http://whois.arin.net/rest/net/NET-173-192-0-0-1
What the? My site is located in Israel, and it's in Hebrew, so there's no reason for them to scan my site.
But, after googling around I've found this:
The Aboundex Crawler is a bot from Aboundex Search, currently operating out of the Softlayer network with the IP Address 173.192.34.95.
Reports about the Aboundex crawler claim it ignores rules in robots.txt, and is a fast page scraper which may switch IP's when blocked from spidering pages.
According to this, the Aboundex Crawler bot ignores the robots.txt file. So why just not ban them?
Well, I think if some new search engine or whatever want to make a good reputation, then it must follow some simple rules, and of course one of them is the robots.txt. So maybe something is wrong with my site? Let's check out what the Aboundex site suggest.
The site doesn't seem to be working, as it says "under construction" when you try to search something, but there is an about page with this info (the only link on the site):
How do i stop Aboundexbot from indexing my website? If you have a concern about Aboundexbot, we hope you give us a chance to address it via the email below but if you need to block Aboundexbot, the robots.txt file will allow you to accomplish that goal.

To block Aboundexbot from your entire web site you add this to your robots.txt file:

User-agent: Aboundexbot
Disallow: /  
I guess it's a good thing to try it. What you think? I'll update later as I'll add it to the forums.

Hope you enjoyed :)

Ansible and Jinja2: Check if variable is defined and it's True

Jinja2 provides you with a built in test: http://jinja.pocoo.org/docs/2.10/templates/#defined So you can simply use: However, if you...