If you use Facebook, you might notice a box when you log in that says beginning June 12th, Facebook will allow registration of user names.  If you “click here” to have them send more info, you’ll receive this in your registered email inbox:

Starting on Friday, June 12th, at 9:01pm, you’ll be able to choose a username for your Facebook account to easily direct friends, family, and coworkers to your profile.

To select your username, visit the link below after 9:01pm on June 12th:

http://www.facebook.com/username/

To learn more about usernames, visit the Help Center:

http://www.facebook.com/help.php?page=896

Thanks,

The Facebook Team

 

So what does this mean?  Well, for one thing, it means that if you’ve got a common name – or – if your like me, and you KNOW that there’s someone else on Facebook with the same name (since he and I are actually friends on Facebook), then it means that you want to “claim” your user name as soon as the application opens.

I did seen an interesting article here http://www.huffingtonpost.com/jonathan-handel/trademark-protection-and_b_213756.html about trademark registrations and how Facebook intends to handle squatters.  So don’t bother trying to register facebook.com/McDonalds, you won’t have it for long if you do. 

I like the very last part of that article though.  There is already a recommendation for what to do, if somebody maliciously claims not only your trademark, but also fills out the forms sufficiently such that you (the legitimate owner of the trademark) actually can’t use the automation to claim it back.

Oh how much fun Identity Management can be

Congratulations to all of the MSIT and Product Group members who got us this far (and let’s not forget the users!)

6 months ago – We’re in the process of federating with a new partner, and the link they send us to their federation server looked something like this:  https://federation.foo.com:9031/blah – notice the port 9031?

This seemed a little random, but not completely unusual since people tend to grab an available port when they want to host a test/beta site.

With a bit of troubleshooting, working with our proxy server team, etc… figured out that our proxy servers only allow SSL connectivity out to port 443, so the federation was broken.  A bit of back and forth with the partner, they moved to the standard SSL port, and everything worked great.

4 months ago – We’re in the process of federating with a new partner, and the link they send us to their federation server looked something like this:  https://federation.contoso.com:9031/blah

Us:  Hey, we’ve seen this before – we can only connect to port 443 for SSL sites, can you move your federation server to the standard port?
Reply:  Sure, done – check it now

And there was much rejoicing. yeah.

Rinse and repeat this a half a dozen times over the past few months, and we’re getting pretty good at recognizing the issue.  And since about 60% of our federation partners are using STS’s which are not ADFS/Geneva, this scenario is even more common.

The other day, while dancing this dance yet again, we did notice one thing though – It’s not a random port – it’s ALWAYS port 9031.  Not only that, but looking back, it’s always with partners who are using Ping Federate server.

A quick search for “9031” on the Ping website, finds that a lot of their sample code uses port 9031. 

Ah ha!  Now I get it.  It wasn’t random after all, but rather re-using the sample code to set up services.  Which is a great, so now we know that when we’re federating with a partner that’s using Ping Federate – be on the lookout for port 9031.

Web pages on Microsoft TechNet: http://go.microsoft.com/fwlink/?LinkId=139749

A Microsoft Word (.doc) document on the Microsoft Download Center: http://go.microsoft.com/fwlink/?LinkId=150375

A new whitepaper has been published providing the guidance you need to deploy Active Directory, and specifically RODC’s, in a “Perimeter Network” (the network segment formerly known as DMZ).

I know that a lot of folks have come to me, asking for help/guidance on putting RODC’s into the DMZ rather than putting full DC’s or having a separate forest.  This should provide the information you need to keep safe, secure, and most of all…functional.

Some of the topics include:
•         Security considerations and configurations for RODCs in the DMZ 
•         Network configurations for RODCs
•         Application compatibility with RODCs in the DMZ
•         Step by step instructions and a sample script to help perform domain join using RODCs

http://technet.microsoft.com/en-us/library/dd728034.aspx

Brandon pointed out to me, that the doc is nice, but having a downloadable version would be much nicer.  We fired off a quick mail, and there will be a downloadable version of the document in the download center in the near future.

I have had a few discussions recently at work about ways to make things more convenient.  Either convenient for our users (cloud services), convenient for our customers (single sign on), etc… 

But a one-two punch hit me, when I just had 2 close friends – both of whom have been impacted by the financial mess – have their identity attacked because something that had built in security controls (checks) was made to be more convenient (by phone), and in the process all of the controls were removed so my friends were vulnerable.

Really, I call it fraud, or identity theft, or just plain robbery…  But in both cases, the banks say that there are no laws against this:

My friend lost her job, and fell behind on payments.  She owed $1100 for this months rent, $4400 to a creditor that by this point had gone to a collection agency, and some other bills (credit cards, gas, electricity, etc…).  Through creative budgeting and working with parents, friends, and anyone else, she scraped together $5000 that she could use. 

With the new money available, she came up with the following plan:

   $1100 for rent
      900 for the other bills
      500 to the collection agency
      The rest to be used for the following months rent, payments, etc…

She called the collection agency, and agreed to pay them $500 now, and then set up a payment plan for the rest of the money.  That’s where the first mistake happened:  They wanted the payment as a “check by phone”.  So she voided a check, gave them the info, etc…

The collection agency first attempted to clear the check for the full $4400.  Because the money was in the account, the check cleared – of course, this meant that she couldn’t pay any of the other bills, or her rent, etc…  And she had already tapped out her friends, parents, etc…

You can imagine that the calls to the collection agency were like:  “Sorry, sucks to be you – we’ve got our money now”

The bank was equally useless:  “You gave them a check by phone, the money was in the account, they cleared it…Sucks to be you”

This was just completely ridiculous, but it shows that in the absence of standards or protocols, there is no shortage of people that will offer things for the sake of “convenience” which blow the hell out of “security”.  If you have to write a check and sign it, then you fill in the amount, etc…  modification of that is check fraud.  But those security controls went out the window when banks allowed people to do “checks by phone”, and there is absolutely nothing to prevent unscrupulous people from raping your bank account if you give them the information.

The second case is similar, but with a slight twist

My friend has slowly but surely been paying off debts that were racked up over a period of time, and has been working through one of those debt consolidation management companies.  Since she wasn’t getting the resolution that she needed from the company, she took back the money that was in their escrow account and started working with the collection agency independently.

On the first phone call, she had an $7,000 debt and worked with the agency to negotiate down to where they would accept $4300.  Seems like a good deal, so again, check by phone for $4300.

A couple of days later, she received a notice from the collection agency, indicating that they “Had an agreement for an initial payment of $4300”.  In other words, the deal they made on the phone was a lie, instead of negotiating the total, they just wanted an initial payment and were going to keep going after her for the remaining balance.

Ahhh…but the check by phone hadn’t cleared yet.

So a quick call to the bank, a $28.00 stop payment charge, and there was a stop-payment for that check before it cleared.

Good right?

Not so much.  2 days later, $4300 was withdrawn from the account anyway, by check #1001 (not the check number she gave them).  A long, convoluted, multi-transfer call back with the bank this time, and they could see where the initial check number had attempted to clear, been rejected (the stop payment), and then the company had re-submitted another check by phone with the different check number and got the money.

After several days of arguing, it’s still unclear whether the bank is going to say “Sorry, sux to be you” or if they are actually going to help.  I’m not holding my breath.

So again, the safety features around checks – being numbered, signed, amounts written (twice) – are all placed into the trusting hands of the least trustworthy person (the merchant that wants your money), and there is remarkably little recourse.  I suppose you could go get a lawyer, etc…  But during that time the money is gone, life still needs to be lived, and a lawyer is going to take 30% of whatever you get back anyway (or some amount of payment)…

All for the sake of convenience (to whom?)

There are better ways, one of which I really like.  I’ve had a credit card with CitiBank since college.  And many years ago, they came up with this idea of virtual account numbers for your credit card.  You can go to their website (or they have a downloadable application), and if you want to make a purchase, you can get a one-time use credit card number (with expiration and CVC) for that one purchase.  I haven’t used it in a while, but IIRC you can even specify the amount of the purchase you’re going to make (which is really the protection).  This is great, because the security of a credit card is handing the piece of plastic with the signature on the back to the person behind the register.  With online purchases, you can’t do that, so instead lets take the things which you can control (amount of purchase, usefulness of the number after it’s been used properly) and control those instead.  Reasonable mitigations.

This is the type of control that we’re going to need if we want to protect our resources in a more “convenient” (read: Online) world.

10 years ago, Microsoft’s largest internal domain was upgraded to Windows 2000 becoming the first production Active Directory, and it’s still going strong…

Dn: DC=redmond,DC=corp,DC=microsoft,DC=com
   whenCreated: 4/9/1999 7:49:12 PM Pacific Daylight Time;

At The Experts Conference in Las Vegas this year, Stuart threw out the challenge to the DS MVP’s to come up with their list of changes they would like to see in Active Directory, but put it to the tune of an Elvis song.  After a midnight (mildly inebriated) recording session, and some fancy editing by the Quest Software production staff, here’s the result!

There were many great speakers at TEC 2009 this year (and I was there too!), especially in the Federated Identity track.  One of the things that I was interesting, was during one of the sessions the speaker described many of the current non-federated authentication schemes that SaaS providers can use.  The implementations may have varied slightly, but they often amounted to “Give us your user name and password, and we’ll authenticate you across some out-of-band channel.”  The deployment of this service requires that extra channel for auth, sometimes being a VPN connection, or an LDAP service that the provider can authenticate against…things like that.

A comment was made, something about the security risk that this poses; after all, it IS by definition a “man in the middle attack.”  The next couple of minutes were spent blasting this type of ridiculous design (after all, this was the federation track) and how horrible this was and people would never let this type of set up occur at their company.

Of course, that’s probably not true at all, is it?  After all, every application outsourcing project I’ve worked on includes the “user SSO” line item, but nobody says what that has to be.  And the corporate security risk analysis has to outweigh the hard dollar cost savings that were driving the project to begin with, which is why I suspect that the typical CorpSec risk analysis always ends up somewhere in the Billions of dollars with a picture of the company going down in flames.  Yet even that’s not enough even enough to stop the project from moving forward, because at the end of the day, IT departments are often not empowered to say “No, you can’t do that”…rather…we end up saying, “This sucks, but here’s the best that we can do to make it work.”

And that is why, a man in the middle attack, even one with credential harvesting, is OK if the company is paying someone to do it (and saving real money in the process)

And it’s why now more than ever we need comprehensive federated authentication solutions, so we don’t have to get run over by these hacks.

This looks pretty cool!

http://www.microsoft.com/tag/

Here’s the tag I created, which would bring you back to my blog if you scanned it with a tag reader app on your phone…