BPuhl’s Blog

A little bit of everything without actually being much of anything

Archive for the ‘Active Directory’ Category

Infrastructure Master’s for App Partitions

Posted by BPuhl on September 25, 2008

One of our operations guys sent mail tonight with an error received trying to demote a server prior to rebuilding it with the next Win7 (Server 2008 R2?) milestone build.  The error was:


If you can’t read that, it says that the DCPROMO failed because it barfed trying to move a FSMO role holder for the DC=ForesetDNSZones partition.  His initial troubleshooting didn’t show a whole lot:

C:\Users\v-ntx>netdom query fsmo /domain xcorp.microsoft.com
Schema master               xcorp-dc-10.xcorp.microsoft.com
Domain naming master        xcorp-dc-10.xcorp.microsoft.com
PDC                         XCORP-DC-01.xcorp.microsoft.com
RID pool manager            xcorp-dc-10.xcorp.microsoft.com
Infrastructure master       xcorp-dc-10.xcorp.microsoft.com

The command completed successfully.

The only thing I can think is that xcorp-dc-03 is Win-7 M3escrow and the other servers are WS08 RTMF.

C:\LocalBin>dcchk xcorp
Server            Build  Site        Opt.    Ping     Sysvol   DCQuery   InSync GCQuery
—————   —–  ———   —-   ——-   ——   ——-   —— ——-
XCORP-DC-01       6001   Liberty      GC    Success    True    Success   True Success
XCORP-DC-03       6781   Liberty      GC    Success    True    Success   True Success
XCORP-DC-10       6001   Liberty      GC    Success    True    Success   True Success

The problem of course didn’t have anything to do with any of the other servers, but rather that since this is our pre-deployment lab environment, we crash and burn a lot of servers and normally don’t really worry about demoting them properly.

A quick reminder that application partitions have their own Infrastructure Master roles, and it was pretty easy to see that this is where our problem was:

Dn: CN=Infrastructure,DC=ForestDnsZones,DC=xcorp,DC=microsoft,DC=com
cn: Infrastructure;
distinguishedName: CN=Infrastructure,DC=ForestDnsZones,DC=xcorp,DC=microsoft,DC=com;
dSCorePropagationData: 0×0 = (  );
fSMORoleOwner: CN=NTDS SettingsADEL:41729533-c386-47a3-95bf-61e15b86af6f,CN=XCORP-DC-02ADEL:7b5b8121-bc44-416b-840b-2900689ab877,CN=Servers,CN=Liberty,CN=Sites,CN=Configuration,DC=xcorp,DC=microsoft,DC=com;

This got even easier for me, because rather than needing to type out a long e-mail explaining this whole phenomenon, I remembered that my buddy Ulf had already posted an extensive explanation over on his blog already!  So for your further reading enjoyment, head to http://msmvps.com/blogs/ulfbsimonweidner/archive/2008/07/31/how-many-infrastructure-masters-do-you-have.aspx for the full explanation.

If you just want to get it fixed, then your options are:

Use your favorite editing utility (I’m partial to LDP.EXE), and update the CN=Infrastructure objects fSMORoleOwner attribute with the DN for the NTDS Settings object of the server you want to move the role to.

…or…if you prefer…

Go to http://support.microsoft.com/kb/949257 and copy/paste the fixFSMO.vbs VBScript to your local server, and run it.  It’ll do the same thing automagically for you.

Posted in Active Directory, Identity and Access, Random Tecnical Stuff | 2 Comments »

MSIT Schema Admin Whitepaper

Posted by BPuhl on August 20, 2008

The IT Showcase team just published our updated (actually, rewritten) white paper on how the MSIT identity team manages schema changes in AD.  There is also a webcast done by Joel Silver, talking about our schema change process.

Technical White Paper

IT Pro Webcast

Posted in Active Directory, Digital Identity, Identity and Access | Leave a Comment »

Application behavior with AD

Posted by BPuhl on August 8, 2008

Recently received an e-mail from a rock star co-worker who, for purposes of this blog, we’ll call “Randy” (largely because that’s his name).  His question was based on some questions that he was getting from a large, enterprise customer, and (slightly edited) went something like this:


Is the MSIT AD team burdened with expectations that the DC’s Name and IP address will remain the same, requiring that a new DC maintain the old Name and IP address when it is replaced?

<company’s> AD team is burdened by users that hardcode applications to a DC’s Name or IP address which makes the DC replacements with new hardware or the introduction of new 2008 DCs to replace old 2003 DCs with new HW much more difficult. 

I have said ideally the AD team should be free of such constraints.  (TCO increase, added time delays negatively impacts service availability, and they lose flexibility I want them to have.)

I have said an application that is hardcoded to the DCName or IP is “poorly written” and instead it should do a serverless bind, or understand SRV DNS records, etc.  (Windows can use the Locator, non Windows applications may account for the majority which I think we can address, partly with a registration system where application owners can be notified about Name and IP changes (if accepted by management.)

Their AD team does not have the executive sponsorship and they get blamed when users escalate issues and says the DC’s “broke” their application.

If Microsoft’s AD team does not have this burden or has executive support in other ways you could share?

I have now told the AD team that at a minimum they need to explain that these additional constraints add to the overall costs of AD.  Executives can approve the costs and need to understand they are not following best practices that AD is a service with published (DNS, Locator) location mechanisms.  Also similar constraints can further limit flexibility into the future.

Any comments on any of these statements is eagerly encouraged and appreciated.


Depending on where you work, politics, management support, etc… As you read this, you might think that this type of situation is absolutely ridiculous, or else it’s completely familiar and comforting to know that someone else lives in the same hell that you find yourself in each day at the office.

Here was my response (again, slightly edited):

There are only 7 infrastructure servers (which are not DC’s) which I’m aware of, that have a hard-coded IP address requirement – and those are the 7 stand-alone DNS servers which make up our internal root.

We are incredibly aggressive AGAINST anyone/anything hardcoding an application to either a domain controller name or an IP address.  We have a slight benefit, because with dogfooding, we often have DC’s offline.  So our SLA is that we will “always have capacity to provide services, but will never guarantee that any given DC will be online at any given time”  Which works because we typically have 2-3 DC’s offline for troubleshooting.

The closest thing that we’ve come to an “accommodation”, is the case of legacy NAS devices which had a dependency on the PDC.  After working with this team, we decided to implement a notification script, which will send that team an e-mail within 15 minutes of the PDC role being moved to a new server.  They are then responsible for updating their device configuration.  We do not give prior notice, or anything like that, it’s just a batch script in a schedule task that checks the PDC and send e-mail.

What I’ve said above is our “official” position.  The reality is that operationally, it’s much easier for us to keep the same IP addresses on servers because we have a dependency on them.  Our IPSec policies, and firewall (router ACL) config’s have the DC’s listed by IP address, and getting those updated is operationally a hassle.  In the past 7 years, we’ve renamed every DC at least 3 times that I’m aware of though, so anyone taking a name dependency would have a hard time.  Our network team has also re-IP’d the network at least twice that I know of, and an additional time recently where they re-IP’d a datacenter, so taking an IP dependency would be bad news as well.

I guess in short, is that we have avoided digging ourselves into that hole, so we haven’t really required executive level support to get out of it.  We have just established clear guidelines for consumption of our service, and told the application builders that they can build at their own risk.  It probably also helps that we are so dynamic, that any app which was hardcoded would be down more than it was up.

Hope this helps,


In typical IT organization fashion, we learned a long time ago that we can’t “say no” when the business comes around with a requirement.  But what we’ve found, is that by publishing and evangelizing clear (or at least murky) guidelines, we’ve been able to head off some of these types of problems.

And like I said in my reply, it probably also helps that we keep changing our names and IP’s all the time.  So if they don’t follow our guidance, they are surely going to break at some point.  :)

Posted in Active Directory | 3 Comments »

Computers are people too

Posted by BPuhl on August 7, 2008

I remember hearing (and saying) that “computers are people too” quite a bit during Server 2008 dogfooding.  It was the way that we reminded ourselves that machine accounts are security principles, and in many ways, they are the most vulnerable security principles.  For example, a machine account is an “authorized user”, and can do the whole plethora of things which auth’d users can do, but it lacks the reliability of separate user names and passwords the way traditional users do.  Machine accounts manage their own passwords, but they’ll let any schmuck who can run something in machine context to “use” them.

This has a few implications.  From the AD perspective, when we’ve thought about machine accounts, it’s usually in the context of life cycle management of data in the directory.  You know, find all the machine which haven’t reset their passwords in 45 days – assume that this indicates that they aren’t on the network anymore, so delete the object.  Good housekeeping maneuver.

With Windows Server 2008, and specifically, with Read Only Domain Controllers – machine accounts became a little bit more important.  Do you let them have their passwords replicated into the RODC?  What happens if the users password is cached, but the machine isn’t?  No service ticket, no work-ey… 

In the federated identity world specifically, we branch this thought process out a little bit further – We want to treat the people like people, and the computers like people, but we also treat the applications like people too!  This actually isn’t specific to federated identity, because we all do this all the time anyway – we just use fancy words, like “service accounts”, “application pools”, and “delegation”.  But at the end of the day, what we’re doing is trying to force the application to “authenticate” to that which it is “authorized” to perform some function – huh…sounds just like machines and people…

So I’ll leave this for now, to let you munch on for a bit – just remember that your users aren’t the only users that you have – machines, and in some cases applications, are people too – and when you’re considering things like security policy, you shouldn’t forget it.

Posted in Active Directory, ADFS, Identity and Access, Random Tecnical Stuff | Leave a Comment »

Goldfinger Editions

Posted by BPuhl on August 6, 2008

I received an e-mail from Sanjay a little while ago, pointing me to some of his recently released “editions” of Goldfinger, his security analysis product.  I haven’t had the chance to download or test them yet, but plan to do so when I can finally come up for air at some point. 

If you want to take a look though, they are available here:  http://www.paramountdefenses.com/goldfinger_editions.php

Posted in Active Directory | Leave a Comment »

RODC’s and BitLocker

Posted by BPuhl on July 31, 2008

I’m not entirely sure why this keeps coming up, but I keep getting e-mails asking whether we are using BitLocker drive encryption on our regional domain controllers, specifically on our RODC’s.  The problem isn’t the frequency of the question (about once a week now), nor the answer (no, we aren’t)…no…My issue is that when people keep asking me, and I tell them no, then they want to argue the point.  I keep wondering to myself whether maybe I’m wrong, and we should be?  It happens often (me being wrong)…

So here’s the definitive answer of the moment:  Yes, MSIT is deploying Windows Server 2008 Read Only Domain Controllers to the vast majority of our regional locations.  We are working closely with some other teams, to ultimately host those RODC’s inside of Hyper-V as virtual machines, but for right now, they are dedicated servers.  Many of them are running server core, some of them are not.  And none of them are running BitLocker.

The reason that we’re not running BitLocker is the result of “Brian’s careful analysis”, which looks something like the following:  BitLocker has 4 TPM based modes of operation (not counting the non-TPM mode).  These are:

  1. TPM Only
  2. TPM + USB Key
  3. TPM + PIN
  4. TPM + PIN + USB Key

Operationally, there is some administrative overhead to configuring BitLocker on the server, so at minimum the value that we get out of having it needs to be greater than what we put into it.  Out of these 4 options, TPM by itself doesn’t really give us a whole lot of value, because if our RODC grows legs and walks down to the pub, it’s going to boot up just fine as soon as it get’s some juice.  Options 3 and 4 both require PIN’s, and the absolute last thing that we want to have happen, is for someone to have to remote into the management board to enter a PIN from a thousand miles away, while the users in the site are all going upstream.  That’s why we configure our regional DC’s to automagically reboot after a crash – we want them back online.  Imagine what this would do to all of us who remotely bounce a server using shutdown.exe, and then ping -t until it comes back up….blah…

I was part of a hilarious conversation with some folks on the BitLocker team and the MSIT hardware team (who were pushing for us to use it).  They proposed that for option #2, TPM + USB, that we could leverage the USB ports on the motherboard, so that the USB key was actually inside the case (when the bad guys stole it).

Of course, every time I tell THAT story, the conversation devolves into the type of pyrotechnic ejection sequence which could be initiated when the server is pulled from the rack.  Just imagine undoing the screws, sliding the server out, and POOF – the USB key launches out of the case at high speed, impacting the ceiling, and shattering into a thousand tiny bits.

Telling Laura about this one day recently, she did pose an optimization – after all, the key breaking up on impact with the ceiling isn’t completely reliable – so instead, she was opting for the small trap door container above the server.  The explosive still fires, the USB key still launches, but when it’s in the container in the ceiling, the door slides shut to “catch” the key, and keep it safe from the bad guys (who are walking away with the server).  Does it feel like we’re boarding on the ridiculous?

Like I said above..maybe I’m wrong here…but personally, I’d rather have my servers running after a reboot (without manual intervention), and I’d prefer it if they didn’t come armed with explosives.  Call me crazy.


Oh yeah – and before the marketing, BitLocker, or anyone else jumps down my throat – I’m ONLY talking about not wanting to run BitLocker on my RODC’s.  Both of my laptops have been BitLocker’d since pre-Vista-RTM, and are re-BitLocker’d after each flatten & rebuild.

Posted in Active Directory, Random Tecnical Stuff | 4 Comments »

Trust Attribute CROSS_ORGANIZATION and Selective Auth

Posted by BPuhl on July 30, 2008

Ever used Selective Authentication on a Windows trust?

Ever looked at the trustedDomain object via LDP (or your favorite tool), “just to check”?

Ever blown right past the trustAttributes values, because all it says is: FOREST_TRANSITIVE | CROSS_ORGANIZATION and you’re looking for something which is a little bit more intuitive than that?

Ever spent 30 minutes Live Searching, Googling, MSDN’ing, and everything else trying to figure out where the fark the bit is that gets flipped to make it selective authentication – or alternatively, just verify your sneaky suspicion that the CROSS_ORGANIZATION bit is the one?

Yeah – I hadn’t either until recently.  Turns out to be ridiculously difficult to find someplace that matches up the fact that when you see this:

Dn: CN=mslpa.corp.microsoft.com,CN=System,DC=corp,DC=microsoft,DC=com
cn: mslpa.corp.microsoft.com;
distinguishedName: CN=mslpa.corp.microsoft.com,CN=System,DC=corp,DC=microsoft,DC=com;
dSCorePropagationData: 0×0 = (  );
flatName: MSLPA;
instanceType: 0×4 = ( WRITE );
isCriticalSystemObject: TRUE;
msDS-TrustForestTrustInfo: <ldp: Binary blob 161 bytes>;
name: mslpa.corp.microsoft.com;
objectCategory: CN=Trusted-Domain,CN=Schema,CN=Configuration,DC=corp,DC=microsoft,DC=com;
objectClass (3): top; leaf; trustedDomain;
objectGUID: 211c8b93-b231-4a93-8bc5-e9bd865b1ecf;
securityIdentifier: <ldp: Binary blob 24 bytes>;
showInAdvancedViewOnly: TRUE;
trustDirection: 3 = ( BIDIRECTIONAL );
trustPartner: mslpa.corp.microsoft.com;
trustPosixOffset: 805306368;
trustType: 2 = ( UPLEVEL );

That the CROSS_ORGANIZATION flag (0×10) is the one which corresponds to Selective Authentication being in place for the trust.

Part of this whole exercise was born out of some confusion from people on the way that the UI mistakenly displays inbound and outbound trust information when there is a full trust in one direction, and selective authentication in the other, as detailed in http://support.microsoft.com/default.aspx?scid=kb;en-us;830572

And yes, I’m saying CROSS_ORGANIZATION and SELECTIVE AUTHENTICATION over and over again in my own petty attempt at convincing the search engines to return this post for the next person who comes along, looking to figure out what this CROSS_ORGANIZATION flag means.

Posted in Active Directory, Identity and Access | 3 Comments »

Federation Agreements

Posted by BPuhl on July 20, 2008

For the past couple of years, I’ve been doing presentations at TechEd, ITForum, DEC (now TEC), and the European Identity Conference on how MSIT is using Active Directory Federation Services (ADFS).  Inevitably, somewhere in my talk, I’ll go back to our initial dogfooding deployment of ADFS in Windows Server 2003 R2, back in 2005, and discuss one of the biggest mistakes we made, and the “mind shift” which had to happen for us to succeed with ADFS.  That mistake, was applying “what we knew” to a new concept, rather than thinking about what we “needed” and the things which were really important to us.

I usually describe this experience, by explaining what happens when you first start to look at federation in an environment, when you’ve got nothing else to compare it to.  Typically the thought process for an ADFS deployment goes something like this:

- It’s single sign-on infrastructure, so Mr. Application Owner doesn’t want to support it for everyone, this is “Infrastructure”

- It’s SSO for users, and there is this “claims” thing which is ‘Identity’ data – so this is “Identity Infrastructure”

- We already have identity infrastructure – our directory – so let’s get the directory team engaged.  Oh yeah – and don’t forget, the technology has “Active Directory” in it’s name – and our directory is “Active Directory” – left hand, meet right hand.

What happens?  Your AD team gets tasked with figuring out how to host resources for partners to do single sign-on.  They’ve been hosting the directory that holds those partner accounts anyway, so this make sense.  Of course, at the same time, we’ve been beating this “directory centric” mindset into the security organization for years, and they are participating as well.  The result:

Both the team deploying ADFS, and the Security team making policies – have a directory centric slant on federation

This shouldn’t be bad right?  It’s Just another identity system.  Yes and no.  The problem with federation, is that if you’re hosting the applications (which is the specific scenario I’m talking about here), you need to “trust” the other organizations identity infrastructure.  Ok, well, trust may be a strong word – but it’s just so much easier than saying, “bind with complicated requirements wrapped up in legal framework” 

Ahh – but directory guys don’t trust anyone do they?  In general, we’re trusted, but that rarely (and usually only with a fight) goes in the other direction. 

Let’s assume that you get over this first cultural hurdle, and decide that it’s ok to trust your business partner for authentication, to get to those applications in your Extranet/DMZ – the ones which they already have accounts in your directory for.  What does the legal agreement look like when you let a bunch of directory brainstorm the requirements?  Well – it contains all of the things which are important to directory folks (makes sense).

Here’s the example which actually prompted this post.  2 weeks ago I received a request from a business partner to allow MS users to authenticate via ADFS to this partners Extranet environment.  This request was accompanied by a 9 page “Federation Agreement”.  The first 8 or so pages were boilerplate legaleze which isn’t really relevant.  The important part is copied below, with name changes to protect the innocent and minor formatting for readability:

Exhibit A Security Requirements

I. Password Policy Requirements:
User Account passwords MUST comply with all of the following requirements:
     Be at least 8 characters long;
     Contain upper and/or lower case letters, numbers and non-alphanumeric characters;
     Be changed at least once every 60 days; and,
     <COMPANY> provisioned accounts (Corporate, Partners domain, etc.) and vendor federated accounts for the same
     individual must have different passwords.

User Account passwords MUST NOT:
     Be cached or stored in cleartext human readable form;
     Be able to reuse their previous 10 passwords;
     Be shared with anyone; or,
     Be set such that the password never expires. Passwords must expire in accordance with 1.c above.

II. Password Best Practices:
User Account passwords SHOULD have at least one number, symbol and/or punctuation mark.
User Account passwords SHOULD NOT:
     Include words in any language or dictionary i.e. do not use a word from a dictionary;
     Be changed to words that have the letter(s) “o” changed to the number(s) zero “0” or the letter “i” changed to the pipe(s)
     symbol pipes “|” or the number one “1”, or vice versa;
     Be a family or pet name.

III. Account Policy:
     1. Access to <COMPANY>’s corporate resources MUST be through approved and valid individual account partner accounts.
         Sharing of user accounts is prohibited.

     2. Account partners MUST NOT impersonate anyone else or misrepresent themselves.

IV. Virus Protection
     1. The Company will ensure that all systems used to access the <COMPANY> Extranet have installed an adequate,
         daily updated, commercially available anti-virus scanner.

V. Screen Savers
     1. Any device used to access the <COMPANY> Extranet shall have enabled a screen saver which activates after 15 minutes
         of inactivity and is configured to lock the PC screen, requiring the User to re-enter their Account password in order to
         re-activate the device.

Note that this is the entire list of their security requirements.  The crazy ridiculous part, is that apparently this company had previously had conversations with some of the MSIT team, and based their agreement off of a very early draft of OUR OWN federation agreement!  What kind of monster did we create?!?!

Have you figured out what’s wrong with this yet?  I already said that this is one of the biggest mistakes that MSIT made when we were doing early drafts of our federation agreement.  So what’s the issue?

Like I said earlier – this is a very directory centric view.  When you manage a directory (remember, I’m also one of the directory engineers for MSIT), what kinds of things are important to you?  Password policies, complexity, etc…  Heck – as a community, how long did we fight to get Fine Grained Password Policy (now in Server 2008) into AD?  Passwords!  These are important things!  And they need to be strong! And they need to be unique!  And they need to be used often, like when the screen locks!  All of these are great and wonderful things that we believe in!

Yes, passwords are important, but let’s step back to the things which are more important.  Before we do though, let me share the response I sent to this federation request:

Thanks for sharing your requirements for federating Microsoft employees into your Extranet.  Unfortunately we are not able to complete the federation onboarding request at this time, as we are not able to meet the security requirements in Exhibit A.  Specifically the areas of concern are:

Password Policy:
- Our password policy requires users to change their password every 72 days, which is greater than your required 60
- We can only ensure that users do not synch multiple passwords within our directories.  Without admin access to your directory, we cannot verify that users are setting unique passwords
- There is a population of users whose accounts are set to never expire passwords

Virus Protection:
- We allow users to do federated authentication from any corpnet or Internet based machine.  Therefore we cannot guarantee that the machine the user authenticates from contains any type of virus protection.

Screen Savers:
- We allow users to do federated authentication of their identity from any corporate or Internet based machine.  Therefore we cannot guarantee the settings or integrity of the device from which the user is authenticated from

Let’s get back to the basics now – the things which are important.  What is the whole point of doing federated authentication between business partners?  DEPROVISIONING!  Yes, that’s the “one big thing”.  The major problem with the way that directories do Extranets and DMZ’s today, is that you’re relying on the partner to remember to deprovision one of his users, when that user is terminated.  With federated identities, you are tying access to your environment to the same identity that the partner company ties access to THEIR DATA to.  The one they issued.

From a federation agreement perspective, here are some of the things which I like to see:

  1. Figure out what the “minimum bar” for things like password policy is, not the settings which you would put in your own partner directory. 

    Ask yourself which is better, to have deprovisioning with a less secure password – or a more secure password on an account in your directory which may stick around for weeks after a user is terminated from their parent company?

  2. Determine what your acceptable bar is for deprovisioning user accounts.  Within MSIT, our SLA for deprovisioning a user is to have 90% of accounts disabled within 24 hours of termination, and 98% within 48 hours.
  3. Don’t try to tie things like machine state to identity.  Within the directory, we can say things like “domain joined machines” and “group policy application” and “patching and security requirements”.  Federation isn’t meant to get you a healthy machine.  Federation provides you with assurance of the most credible identity possible.  Our identity is more credible than yours, because we know when the user is still employed with us.

As always, security is about risk management.  Federation Agreements are the legal instantiation of a risk management policy.  Don’t set your risk management bar so high, that you actually end up reducing your security posture by preventing partners from federating.  You may “keep control” of the accounts in your directory – but those aren’t the most credible accounts that could be used to protect your data.

Posted in Active Directory, ADFS, Digital Identity, Identity and Access, Random Tecnical Stuff | 4 Comments »

Ch. 1 – RODC Deployment Guide now available on Technet

Posted by BPuhl on June 6, 2008

From GregoireG (Directory Service Program Manager):

After shipping the RODC compatibility pack for Win2K3 and XP a few weeks ago, we shipped today the 1st chapter of the RODC Guide, which is meant to be the authoritative piece of documentation for our customers to decide if, when and how to use RODCs.

You can find the guide on technet, under the AD DS tree. Here is a link to it (don’t hesitate to share it!): http://go.microsoft.com/fwlink/?LinkId=120840

Some of you may have noticed that I said “1st chapter”; this is because the guide that we’re releasing today is generic to any usage scenario of RODC, and we’ll add in the coming months additional chapters that correspond to more specific scenarios where RODCs are going to be used; the proposed structure is:

Chapter 2: RODC in branch offices

Chapter 3: RODC in segmented networks (DMZ)

Chapter 4: RODC on internet

Posted in Active Directory, Random Tecnical Stuff | 2 Comments »

PowerShell script to automate deployment of Read-only Domain Controllers on Hyper-Visor

Posted by BPuhl on June 6, 2008

Nathan Muggli (Active Directory Program Manager) has posted a set of tools/powershell scripts for automating the deployment of RODC’s using Hyper-Visor.  Great examples of what you can do when you combine powershell, hyper-visor, and Active Directory Domain Services on Server 2008.


Posted in Active Directory, Random Tecnical Stuff | Leave a Comment »


Get every new post delivered to your Inbox.