Category Archives: Technology Concept

Microsoft Managment Summit Begins! #mms2013

Posted by Robert on April 8, 2013 No comments

MMS is an event that happens annually and is a place like no other for Systems Managment people. Figure at least half the systems Managment professionals in the word are going to be here in Vegas this week. I will share what I see as time goes on over the week.

Sadly, these won’t be the normal thought out posts I have. No, instead these will be more in the reporting concept. My apologies for this temporary change.

Keynote thoughts:

There are two many systems management products targeting to many separate technologies. Need to simplify. This is a valid issue that is seen everyday. The Microsoft idea is that this needs to stop. Their offering is System Center to do it all. In all reality, this is a real issue that needs to be looked at.

BYOD [Bring Your Own Device] is going to be the norm and no longer the exception. This is something Microsoft is pushing, but unlike some I think they are just trying to be ahead of the curve.

Can some of your demos… the keynote was killed because Mandalay Bay lost internet access. In this case, Microsoft didn’t and this is turning into a small disaster over it. However, in the end you can try doing a massive presentation with just a cell phone hot spot.

Odd facts stated at the keynote:

Skype does 2 million minutes a day.

20% of all enterprises use Office 365. (Wow! I had no idea.)

50% of workers in their twenties view BYOD as a right, not a privilege.

Stay tuned!

Quick Comment: Active Directory 2012 USN Rollback Protection. Finally safe virtualization?

Posted by Robert on October 19, 2012 20 comments

So something that doesn’t seem to be getting much press is that Windows Server 2012 brings safe virtualization and protection from USN rollbacks. Yes, it does. All the docs say it, but Hyper-V 3.0 and PowerShell V3 get all the press.

Windows Server tried to detect USN rollbacks, but this error… which can kill a domain was really a real danger: and regularly occurred. The more common ways a USN rollback might not be detected are: a virtual hard disk may be selected on more than one machine or more commonly, a snapshot of a VM is restored and it has an USN that has increased past the last USN that the other domain controller has received.

So while the first scenario might lead to domain controllers not replicating changes… and make things unstable and unpredictable, and kill your forest; the second can be really bad. Lets just say bad. Best case is an Event ID 1988 in Event Viewer for a lingering object. Sometimes though you have corrupt data and wipe out the domain.

So, what mas my mantra again? Oh yeah. Let’s make the new modeus operendi: just say no to “blowing up” your Active Directory. So give Windows Server 2012 a spin and let’s hear some attempts to kill it.

An excerpt from Microsoft discusses the new feature. Don’t forget to follow the link and read the whole thing.

Excerpt from http://technet.microsoft.com/en-us/library/hh831734.aspx

“Virtual environments present unique challenges to distributed workloads that depend upon a logical clock-based replication scheme. AD DS replication, for example, uses a monotonically increasing value (known as a USN or Update Sequence Number) assigned to transactions on each domain controller. Each domain controller’s database instance is also given an identity, known as an InvocationID. The InvocationID of a domain controller and its USN together serve as a unique identifier associated with every write-transaction performed on each domain controller and must be unique within the forest.

AD DS replication uses InvocationID and USNs on each domain controller to determine what changes need to be replicated to other domain controllers. If a domain controller is rolled back in time outside of the domain controller’s awareness and a USN is reused for an entirely different transaction, replication will not converge because other domain controllers will believe they have already received the updates associated with the re-used USN under the context of that InvocationID.

For example, the following illustration shows the sequence of events that occurs in Windows Server 2008 R2 and earlier operating systems when USN rollback is detected on VDC2, the destination domain controller that is running on a virtual machine. In this illustration, the detection of USN rollback occurs on VDC2 when a replication partner detects that VDC2 has sent an up-to-dateness USN value that was seen previously by the replication partner, which indicates that VDC2’s database has rolled back in time improperly.

A virtual machine (VM) makes it easy for hypervisor administrators to roll back a domain controller’s USNs (its logical clock) by, for example, applying a snapshot outside of the domain controller’s awareness. For more information about USN and USN rollback, including another illustration to demonstrate undetected instances of USN rollback, see USN and USN Rollback.

Beginning with Windows Server 2012, AD DS virtual domain controllers hosted on hypervisor platforms that expose an identifier called VM-Generation ID can detect and employ necessary safety measures to protect the AD DS environment if the virtual machine is rolled back in time by the application of a VM snapshot. The VM-GenerationID design uses a hypervisor-vendor independent mechanism to expose this identifier in the address space of the guest virtual machine, so the safe virtualization experience is consistently available of any hypervisor that supports VM-GenerationID. This identifier can be sampled by services and applications running inside the virtual machine to detect if a virtual machine has been rolled back in time.”

Technology Concept: Do you have a broken glass account?

Posted by Robert on October 5, 2012 5 comments

Do you have a broken glass account? Are you ready for your environment to survive if you are not there anymore? Do you consider the hit by a bus concept to be a joke?

So I am sure you all have heard of the old “hit by a bus” concept. This is the idea that in case something happens, there is documentation on running the network somewhere. This somewhere is known by the company’s management… and normally more than one member of that management.

Okay, so you knew the concept, but it is kind of joked about in the industry yes? Yes it is, by people who have never been there. My first example of needing this in my day to day work was when a Domino Administrator went hosteling in the nineties. He left, and the company had problems. And of all the security had been done just to him, not to a group… so no one else had access. Back then we could use a brute force hacking program and get in. We still can if you don’t do your job on passwords. But if you do… how do you get in to support? This last year I have ran across two clients who primary network people really did die. Some of the documentation was there… some wasn’t. Happily, a “broken glass account” was not needed.

So what is a “broken glass account”? The name comes from the old fashioned breaking of the glass to pull a fire alarm. What it means in information technology is a little different. It refers to an account that is documented with user name and password, and normally kept on paper in a safe that allows a person who does not have access privileges to gain those access privileges when necessary.

This allows you to keep auditing clean by not leaving active users passwords written down, and at the same time allow access at need. Auditing should never be endangered by sharing accounts. This just leads to suspected troubles later down the way. This is also partly the reason that designated “broken glass accounts” exist. If the engineer or administrator writes down their credentials, then forever more you cannot guarantee that only that person has access to that account. Instead you have guaranteed that is not the case.

This leads to one requirement to always put on “broken glass accounts”. You should require all “broken glass accounts” to have a requirement to change passwords on use if they are domain accounts. This updates the object in Active Directory and therefore begins an audit trail. And after any disaster there is likely to be a review, so bright and clear audit trails are important.

Now traditionally there is a twist to keep things a little more organized. You can keep tiers of accounts. Would I keep all that I list? No, but these are reasonable. I would keep two or three at most. I always start with Enterprise Administrator. Some reasonable tiers are:

Enterprise Administrator
Systems Management / System Center Infrastructure Engineer
Server Operator
Desktop Administrator

The broken glass account is part of a broader solution of business continuity and disaster recovery, but it is simply basing pre–staged emergency user accounts in secured location that will allow management to access them at need, while not breaking the audit trails. Just remember to keep this solution simple. If you do it will always be effective and reliable if something happens.

The RepAdmin Active Directory Blog

Check out our Identity Managment, Systems Management and Certification spotlights.

Category Archives: Technology Concept

Microsoft Managment Summit Begins! #mms2013

Quick Comment: Active Directory 2012 USN Rollback Protection. Finally safe virtualization?

Random Posts

Search by Tags!

Archives

Links

Meta