Archive for the 'Security' Category

“Active Directory” SPECIAL EDITION of the IT-Administrator published

Thursday, November 4th, 2010
ITA-Sonderheft

MVP Florian Frommherz and I wrote a Special Edition of the IT-Administrator: almost 180 pages which provide in-depth information about Active Directory. We are discussing the Evolution of AD, Domain and Forest Strategies, Understanding the Domain/Forest Levels, LDAP Backgrounds and Application Performance testing, AD and DNS, AD Backup and Recovery, Background Information about the AD Recycle Bin, Virtualization of DCs, Replication Across Firewalls, RODCs, Delegation and MSAs, Fine Grained Password Policies and many more.
We are very happy with the result: a huge amount of in-depth information for any AD Admin or Consultant.

Sorry – just in German for now. But an interesting read.

If you got it, feel free to provide feedback!

 

Ulf

Exchange 2010 RC touches AdminSDHolder

Wednesday, September 9th, 2009

I was just pointed to the blog of David Loder who’s pointing out that the Release Candidate of Exchange 2010 is changing the permissions enforced by AdminSDHolder to critical groups to allow Exchange Organizational Admins to change the group memberships of Enterprise Admins, Schema Admins, Domain Admins a.s.o.

OK, one of Microsoft Program Managers already responded, and I do agree that this is not a released product and pre-release versions are there for finding those bugs.

I’d just like to say:

@Ross: This is not that hard to fix:

  • for existing OUs stamp it on their ACE (preferably top-level – if inheritance is blocked on lower levels check and point to an KB
  • for new OUs change the defaultNtSecurityDescriptor of the OU-Class in the schema
  • don’t touch adminSdHolder 😉

The first one will make sure that existing OUs allow Exchange Admins to control Group memberships (actually I’d even like to discuss if this is necessary – usually group membership administration is not done in the same instance where groups are mail enabled – the first one would be a generic help-desk task, the second a Exchange-Admin task).

I’d also prefer – if OUs are touched – that if the organization decided to block security inheritance at one point that a new version of some software shouldn’t go beyond that point but respect the design but warn them about the consequences.

The second suggestion makes sure that new OUs will get the permissions by default when creating the OU.

The third suggestion makes me think about two things:

  • is there no process for infrastructure critical changes as changing the adminSdHolder (I’d think that the Active Directory Product Group should be involved if something as this is happening, how should they ensure security if other groups are mangling around with their mechanisms)?
  • why is this coming up in RC? If a product is at Release Candidate Level, it’s mostly finished and usually there are not this many changes approved afterwards (unless they are critical). I hope that this will be fixed!

Thanks David for finding this one, very interesting, and I hope it’ll be fixed!

See Davids Blog for his post

See my blog-post about AdminSdHolder

 

And since I wanted to mention this: if you are in Europe (or want to come), The Experts Conference (TEC) is in Berlin next week and it is THE place for Active Directory and Exchange.

Why Clients don’t (need to) understand the concept of Read-Only Domain Controllers (RODC)

Monday, June 16th, 2008

Hi There,

 

just back from TechEd, it’s time for some technical posts. So one of the questions I got very often is what you need in your infrastructure to deploy read-only Domain Controllers. Along with that question goes what Client-Version of the Operating System is needed that they are able to authenticate with an RODC.


What is a RODC?
The Read-Only Domain Controller is a new concept in Windows Server 2008. While a regular Domain Controller allows updates to the domain contents on each DC, an RODC is only receiving updates from Full DCs. He will not take any write requests. He is further not replicating any password or cached secrets. This distinguishes him from a NT4 Backup Domain Controller (BDC), who had all passwords stored locally. Also he is – in every other means – a full domain controller and LDAP-Server, also stores all GPOs in Sysvol. To allow offline operations (when the WAN to the RODC-Site is failing) Administrators are able to configure if certain users passwords are allowed to be cached, by putting them in a group which is in the allow list. There is also a group whos passwords are denied to be cached, even if they are in the allow list. List group contains by default certain administrative accounts, such as domain administrators, enterprise administrators, the operators groups a.s.o.
The RODC is built for the unsecured Branch-Office or for the DMZ/perimeter network, where you are either unable to ensure the physical security of a DC or where the environment is untrusted.


So the first thing you need is to prepare your existing infrastructure. The RODC is a Domain Controller, so you need to update the schema. Further the RODC needs some assistance from a Full-DC, so you need to deploy enough Full-DCs to allow replication to the RODCs. For most environments one Full DC should be sufficient (RODCs only replicate inbound, not outbound, which also increases performance and decreases replication traffic), however I’d always prefer a second one to allow redundancy. To prepare the schema you need to perform the forestprep and domainprep operations (adprep /forestprep and adprep /domainprep), if you want to deploy RODCs you also need to perform a adprep /rodcprep in every domain of the forest to allow a Global Catalog on the RODC. However you do not need a Windows Server 2008 DC in Domains where you don’t want to deploy RODCs. However two: there are other reasons why you should deploy Windows Server 2008 [;)].

But how do RODCs perform certain functions? They can take the role of a Global Catalog server and of a DNS-Server. If a client (member-servers might also be clients to Active Directory, even the domain controller itself – his OS – might be a client to AD) tries to write against an RODC the RODC is using LDAP write referrals to tell the Client that he is supposed to write to a different DC (a Full Windows Server 2008 DC). LDAP referrals have been defined e.g. in RFC 2551 back in 1997, so LDAP-applications should be able to follow them.

And how is a logon performed against the RODC? The user is actually performing the logon against the RODC. The RODC is looking in his local AD to verify whether or not he’s able to verify the users password. If he has no cached copy of the password he is forwarding the request to a full DC. Further he is requesting the full DC to replicate the password down to him, the full DC checks the allow- and deny-lists and decides whether or not to replicate the password down. The full DC further issues a kerberos ticket for the client. The RODC is informed that the client may log on, and the RODC is issuing his own kerberos ticket for the client. All other things of the logon process, such as compiling the token with group membership information and pulling down group policies is done against the RODC. If the user logs on another time, and the password is cached on the RODC, the RODC does not need to contact the full DC and is able to process the logon-request even if the WAN is offline.

The other thing are DNS updates. Clients in the Branch Office (or Remote Office how we prefer to call it nowadays) are supposed to use the local DNS-Server. However they might update their DNS-Records, which is totally acceptable. But if the RODC is not writeable, and DNS is stored in AD, and actually the DNS-Zones on a RODC are not writeable too, how are those updates performed. This answer is actually quite simple. We Windows Admins got spoiled over time, since our DNS-Servers – when the zone is stored in AD – allow updates on any DNS-Server which is also a DC and holds a copy of the AD-integrated Zone. However think back to the concepts of DNS. We always had a single primary DNS-Server who was able to write updates, and multiple secondaries who were just able to answer to queries. Clients who want to write in DNS had to request a SOA (start of authority) Record for the zone they want to write into. Full DCs who are DNS-Servers with an AD-integrated replica of the Zone were always answering with themselves as SOA (the SOA-Record only allows one Server, and there is only one SOA per Zone, as opposed to Nameserver (NS) Records where are multiple per DNS-Zone). RODCs don’t have an SOA for themselves, they hold a SOA which is stating the Name of a Full DC. So that is simple, Clients who want to write into DNS are still (same technology as in the 80th) querying the zone for it’s SOA, and then they are contacting the Server which is stated in the SOA to write the update. But RODCs provide some intelligence as well – if a client was contacting them for the SOA they wait for a moment to allow the client to update his record, then they are requesting a single-object-replication from the Full DC for the Clients DNS-Record so that the DNS-Information at the clients site is updated as soon as possible, while any other site will receive it with the regular replication.

So Clients / Memberservers and other machines should be able to run against RODCs. However, there are certain things which might affect this statement:

  • The Read-only partitial attribute set (RO-PAS): It is possible to define in the schema that certain attributes should not be replicated to RODCs. However the application needs to be aware of this, since those requests are not referred to a full DC.
  • Replication latencies: if an application is performing a write request it will be redirected to a full DC. If the application tries to read that data again before replication occurs, the RODC will still return the old data. If you want to make sure that your applications write against RODCs be aware of this issue, and look for a writeable DC when you perform write/readback-operations or make sure that you are not using write/readback (but stick against the RODC if you only perform read operations, otherwise you will slow down your application since it’s always crossing the WAN).
  • Firewalls: especially in DMZ-Scenarios your clients might not have a connectivity to a full DC, so write referrals will fail. Make sure that you don’t need write requests in those scenarios.
  • WAN-Offline: write operations will also fail in this scenario

I hope I was able to get some lights behind RODCs, theres a lot of more information available online, e.g. look at the following page: Application Compatibility with RODCs

 

Ulf

Congrats Microsoft: Windows Server 2008 is RTM

Tuesday, February 5th, 2008

I cannot state it any better: the best Windows Server release ever has been released to manufacturing – Windows Server 2008 is finished.

Windows Server 2008 is very stable and very well-done for production use. As I wrote before we at Computacenter are using it since October 2007 in Production, and I have a customer where we already run a full shop only on Vista and 2k8 since September (on Beta 3).

And we’ve also done a lot of things, to quickly recap just what we’ve done with customers was a 10-city Roadshow in Germany (half-day sessions on WS2k8, last one will be in Berlin next week), countless presentations at customer or trade shows / events, countless sessions to make sure our staff is ready to sell and deliver WS2k8-Solutions, one press-release in October, and a couple references which will be published shortly.We will be with many people at the German Launchevent, are partner there with a booth, and I’ll deliver 3 sessions plus a interactive one, created many flyers and solutions around the product, … just being ready to deliver.

I’m very excited about the new product – let’s start deploying more of it!

And here are the blogs which will give you a feeling how it was at Microsoft in the last couple hours:

Windows Server 2008 – RTM!!!

Windows Server 2008 – A time to sit back, remember and party!

Security-Boundary: Forest vs. Domain

Saturday, August 25th, 2007

About time for a somewhat technical post:

In some Newsgroup we recently discussed if it’s considered Best-Practice to deploy a lot of single-domain forests as opposed to a single multi-domain forest. The major reason herefore was that in the early Windows 2000 days, somebody said that the domain is the security boundary. After they’ve figured out that you can elevate yourself as domain admins for a inner-forest trusted domain, they revised this statement and said that the only security boundary is the forest, not the domain.

Since this attack is not that likely, I prefer to state this differentelly:

  • The forest is the security boundary against malicious attacks (the attack is being done on purpose)
  • The domain is the security boundary against (domain) administrative mistakes

So for many things the domain might be enough of a security boundary. If you don’t trust admins of a different domain enough that you think they might perform an attack (= elevate their rights in an area where they don’t belong) on purpose, either fire them, fire them, don’t give them administrative rights, fire them or put them into a separate forest.

Ressource-Forests (yeah – back to the NT days) are sometimes a good idea too, especially if separate companies want to share ressources, however keep in mind that they are a bit harder to manage and it depends on the application how well it integrates. You are also better of to use some solution like the Microsoft Identity Integration Server (or the Identity Integration Feature Pack) which is now part of Identity Lifecycle Manager to synchronize accounts into the ressource forest, however make sure to protect them well enough and to trust the admins of the resource forest from all parties. MIIS/IIFP allows you to sync the passwords of the users in question (by using a password filter on all DCs to notify MIIS, who’s changing the passwords in the connected directories) to allow a better integration via single sign on / single credentials [1]. Don’t forget to design processes for the changes in the ressource forest which are signed off by all participating companies.

OK – back to the subject – don’t take any recommendations to deploy many single-domain forests only or to put everything in the same forest – think about it if it’s really necessary and valuable to deploy multiple forests/domains. At one point there was a recommendation: If you are designing your active directory, and you think you need to add a different domain, rethink that decision. Not true in all scenarios, however think about your design.

One reason for multiple domains have been different password policies – and as I posted before this reason is vanishing in Windows Server 2008.

There are multiple opinions on this, so don’t hold back on feedback / your thoughts.

P.S.: I do respect statements like the one “to recommend multiple single-domain forests” – they are a bit extreme however deliver the message. For example a friend of mine was at one of the top security sessions at TechEd US (where they showed a real-world-unlikely attack), and afterwards in the bathroom he heard attendees who just phoned back their companies to instruct them patching their Servers. So even after the attack was not to likely to happen in a real company, it delivered the message to keep your systems secure.

[1] Single Sign-On: The user is logging in once to his workstation, and getting access to other ressources automatically without re-authenticating
Single Credentials: I made this up a couple years ago – I think more valuable in the beginning are single credentials (combinations of username/password). Users in enterprises are sick of multiple accounts, because they have to remember different usernames and/or passwords, which is leading to weak passwords. If you are able to synchronize the password for the user more easily than providing him with single sign-on this is still valualbe, since the users don’t have to remember multiple passwords. I wouldn’t mind entering the same password to access multiple applications, however I do mind remembering different credentials.

Windows Server "Longhorn" – Active Directory Attribute Editor and LDP

Tuesday, March 20th, 2007

Another Article of Jorge mentions the new “Attribute Editor” in Active Directory-Users and -Computers (ADUC) and Active Directory-Sites and -Settings (ADSS). Basically you have the Property-Page of ADSIEdit now in ADUC and ADSS and you are able to configure all attributes of the selected Object in a more generic view. I love this “feature” (*) – you’ll see it as soon as you have selected “Advanced View” in ADUS or ADSS and open a property page of a object.

Also I’d like to mention another great “feature” (*) of the property page – it shows you some of the data more human readable than it was in ADSIEdit. They are converting numbers now – e.g. to time-values a.s.o.

Another thing which has improved in ADUC is that if you select a domain controller you are able to access the NTDS-Settings-Object underneath it. For example you are able to configure the DC to be a Global Catalog (or not) on this dialogbox. This was providing a lot of confusion in the past where you either were able to see the DCs Properties in ADUC or to select whether it’s a GC or not in Active Directory-Sites and Settings – so well done Microsoft for deciding to show it in Active Directory-Users and Computers as well.

Jorge is also covering LDP in his post, and how much it has improved. What I really love in LDP is the Advanced Security Dialog which displays a Security Descriptor with it’s DACL, SACL and ACEs in the GUI or via a Text Dump. Just select Browse -> Security -> Security Descriptor out of the menu in ldp.exe and select the object and if you prefer a Text Dump or the “friendly view”.

Read Jorge’s article on Windows Server “Longhorn” – Management tooling to get more information about the possibilities in Active Directory-Users and -Computers and Active Directory-Sites and -Services.

(*) In Windows Server “Longhorn” we have Roles which we install, such as DNS-Server, Active Directory Domain Services, File Server, … and Features which are minor things to install such as Bitlocker, Telnet, Windows Backup, … so what do we call something which is a new thing but is not a Role or a Feature in the Product? In the past we’ve called it feature, but now we are without a wording for it.

TechEd EU 2006 in Barcelona

Sunday, January 21st, 2007

So … TechEd was just great – I can not describe it in other words.

As I wrote in a prior post I had some sessions to take care of at TechEd. So after we arrived in Barcelona we first had a dinner with the MCT-Community which we really enjoyed. There are so many MCTs out there who are so dedicated to their “passion” (and job) that it’s always a pleasure to meet everyone and enjoy geek-talking. After the conference started I still wanted to adjust the demos of my session to show some new stuff. Unfortunately I made a small mistake (if you have dual-boot with Vista RC2 and XP try to avoid hibernating – especially if you have a laptop vendor which does provide very bad drivers) so I had some harddisk corruption on my Laptop. Did I mention that the PPTs and the demos were all supposed to run from my laptop (the XP-Part)? So I had some joy in fixing my Laptop on the road without the CDs, however I managed to get it up and running again (before it went right into a bluescreen after the bootmanager) – some files in XP were still corrupt (and they are currently still corrupt – didn’t had the time to reinstall and I’m only using the Vista-Installation anyways). Learned it the hard way – do not hibernate with shared disks.

So after I was sure that at least Powerpoint and VPC are back and running I was adjusting my demos. The rest of the time of the first days (there wasn’t much as you can assume) I spent in the Ask-the-Experts-Area and answered questions in the Longhorn Booth. This is one of my favorite things at those conferences – you get so much insight of many issues within multiple companies, and how attendees (mis)understand the products. This also gives me ideas which points we have to outline in talks and blogs, apart from enjoying to helping the attendees.

On Wednesday I had the first of two Chalk-&-Talks with Karmal Janardhan (Group Program Manager in the Active Directory Program Group). The concept of Chalk-&-Talks is a mixture between Ask-the-Experts and Breakout Sessions. You have many attendees in a session room, you are not supposed to use Powerpoint (a few slides to help the discussion getting started or outlining examples are accepted) and you are discussing technologies with the attendees. We did a Chalk-&-Talk on “Active Directory and DNS in Longhorn”. It was just great. Kamal is so deep into the planning and features of the technology, and I was able to contribute with my practical experience. We both enjoyed the session, and according to the discussion and feedback afterwards the attendees enjoyed it as well. I don’t think there was another session where you could get a better knowledge topic. OK – maybe Kamals Breakout Session which covered the same topic – but I even think we were able to explain it better in the Chalk-&-Talk due to the discussion format of the session. We had the last session-slot of the day and the room was crowded. There were people leaving because there was no more space. Afterwards in the Hotels Lounge some other speaker was complaining that the last session of the day was empty in many sessions and the attendees were supposedly already off partying, but I know where they were [;)].

On Thursday afternoon I had my own session: “A Directory Services Geek’s View on Access Control Entries (ACE)”. Since I just had a few minutes between the session prior to me I decided to use a longer break before to connect my laptop to   power at the speakers desk and get it up and running, so that the session before allows the power ma"A Directory Services Geeks View on Access Control Entries (ACE)" at TechEd EUnagement-drivers to “adjust”. Otherwise the time to start up as well as the performance would be questionable. This was a good decision – I didn’t had any issues with performance, the session and demos went very well (OK – I was a bit nervous because I still didn’t trust my recovered laptop). I love this session, since I was always missing Geek-Level content at TechEds, so I was happy to present it. There were a lot of interested attendees, feedback was great (e.g. “You can improve the conference by doing more sessions like this.”, and “excellent session – best one I have been to so far” on a Thursday afternoon). There were many interesting questions right after the session, but at some point we got bounced so that the next session was able to start. However I went right back into the Ask-the-Expert-Area and had some lengthy discussion about the topic with some attendees. Very interesting talks – so we continued until we were told that the exhibition area is closing and we are to leave.

On Friday Kamal and I repeated our Chalk-&-Talk about “Active Directory and DNS in Longhorn” right in the morning. We had slightly less attendees (probably partying the night before, or everyone was in our first session) but the discussion was still very good. Kamal is impressive – at her own session she got a comment like “how comes a little girl tells all geek’s in here how technology really works” [;)]. After the Chalk-&-Talk we went to the Ask-the-Experts-Area, and I didn’t leave until the conference was over. There were so many interesting questions. Actually some attendees were coming up to me with their “List of Questions” they made up during the week, so I was answering .. answering .. answering … (I call it the “streaming answering mode” now [;)]). 

However – what a great week – everytime again!