Tomek's DS World

Where to put SSL certificate for LDAP …

tomek — Wed, 17 Jun 2009 21:06:00 GMT

Protecting LDAP traffic with SSL is a good idea, especially if in network environment some applications are (ab)using LDAP as authentication protocol.

Some explanation of abusing word – LDAP never was designed as authentication protocol (like Kerberos is). Its name states it clear “DIRECTORY ACCESS PROTOCOL”. However because it is simple to use and effective it is often used as such. Because it wasn’t designed to be an authentication protocol it lacks features which would protect credentials etc. which might expose authentication data for different threats which are common for every important information sent in a clear text over a network. To say it in simple word – when you are doing simple LDAP bind over non secure connection you are just exposing your credentials to others. For proof see see screenshot from network trace below:

So I think this screenshot itself should be enough to start to think about securing LDAP traffic with SSL (convincing developers to use different protocol or to enforce SSL connection in an app might be on the other hand tough task).

Getting back to the topic – good news is that Active Directory infrastructure makes it pretty easy to enable SSL on LDAP protocol. Just give DC proper certificate and it will start to accept LDAP over SSL connections. “Proper” means that it has to meet some criteria, one of them is that its purpose statement should contain Server Authentication (1.3.6.1.5.5.7.3.1) OID on a list.

Deploying certificates in environment with Enterprise CA based on Windows Server integrated with AD is also easy – you can take advantage of auto enrollment feature and DCs will request and install certificates on their own. It is also possible to use third party certificates. Procedure for requesting and installing such certificates on DCs in described in KB321051. In both cases (auto enrollment and KB manual procedure) certificate is being installed in Personal store of local system.

This store has this disadvantage that it might contain many different certs installed by other services and applications if required. If it will contain many certificates meeting requirements for DC to use this cert to protect LDAP traffic it will just pick one. We don’t have real control which one.

Since Windows 2008 there is a way to have more control on this behavior and select certificate which will be used to protect LDAP traffic. If certificate will be put in NTDSA\Personal store instead of default Local system store it will be picked up by directory service in first place and used for LDAP traffic protection.

If there will not be any of certificates in NTDSA\Personal store DC will fall back to old behavior and search for certificate in Local system store

Looks easy … one problem I have with this solution is that I can’t find a way to use auto enrollment mechanism to enroll certificate for DC and put it directly in NTDSA store. If there is anyone who have idea how to do this … comments are open :).

OU layout and LDAP queries

tomek — Sun, 31 May 2009 21:36:00 GMT

From time to time people are asking me questions about AD and related topics. I don’t know why but they think I might now the answer. Sometimes this is not true ;) but I try to do my best (I’ve just learned today that there is “Geek network” so probably those persons can answer all the questions I can’t ;) . Some time ago through such “question channel” I received following question:

What will be better from LDAP queries performance stand point:

single OU with 20k of objects

OU tree with 20 OUs and 1k of objects in each.

(this is my rough translation from Polish).

Well, I thought that maybe others might have such dilemma as well so maybe it is good topic for blog entry.

(cc) magic mudpuddle

Disclaimer: of course this is based on my knowledge, so maybe somebody with more ESE deep knowledge will have some more input on possible implications ;).

So short answer to this question is that OU layout will not matter from LDAP queries performance. Now lets check it a bit.

Let’s run some queries in lab environment.

Lab setup …

To perform this test I’ve created two OU structures. Single OU with 20k of users in it and nested OU structure with 20 OUs and 1k of users in each of them.

Little digression – for pure fun I’ve created first set using admod.exe and second set using Powershell AD cmdlets from Windows 2008 R2. It was almost same experience with preparation of queries from usability standpoint, admod command was bit shorter. PoSH script was about 4 lines. Next time I will gather execution time for comparison.

Short exercise which was performed on these data was to execute a query which will lookup single user using samaccount name using ADFIND with following query:

adfind -b <OU> -s subtree -f "(samaccountname=<nazwa użytkownika>)" -stats+only

-statst+only switch was used as I was not really interested in results but only in LDAP query statistics and this is nifty feature of ADFIND that it can show You this information (for SQL guys … it is something like execution plan ;) ).

Case #1 – search in single OU with 20k of users

Statistics
=================================
Elapsed Time: 47 (ms)
Returned 1 entries of 1 visited - (100.00%)

Used Filter:
(sAMAccountName=1038_testusr)

Used Indices:
idx_sAMAccountName:1:N

Pages Referenced : 31
Pages Read From Disk : 1
Pages Pre-read From Disk: 0

Analysis
---------------------------------
Hit Rate of 100.00% is Efficient

Indices used:

Index Name : idx_sAMAccountName
Record Count: 1 (estimate)
Index Type : Normal Attribute Index

Case #2 – search in OU structure with 20 OUs, 1k in each

Statistics
=================================
Elapsed Time: 0 (ms)
Returned 1 entries of 1 visited - (100.00%)

Used Filter:
(sAMAccountName=11520_user)

Used Indices:
idx_sAMAccountName:1:N

Pages Referenced : 33
Pages Read From Disk : 0
Pages Pre-read From Disk: 0

Analysis
---------------------------------
Hit Rate of 100.00% is Efficient

Indices used:

Index Name : idx_sAMAccountName
Record Count: 1 (estimate)
Index Type : Normal Attribute Index

So at first glance both results look similar in terms of efficiency, indexes used etc. In first case however you may notice that query time was much longer – it took 47ms to complete query. But was it related to the fact that this was query performed on single OU with 20k object? No. If you will look at entire statistics data you will spot that in this query case not all data were available in memory cache and one page was read from disk

Pages Read From Disk : 1

When data was cached we can re-run this query and see if results will changee:

Statistics
=================================
Elapsed Time: 0 (ms)
Returned 1 entries of 1 visited - (100.00%)

Used Filter:
(sAMAccountName=1038_testusr)

Used Indices:
idx_sAMAccountName:1:N

Pages Referenced : 27
Pages Read From Disk : 0
Pages Pre-read From Disk: 0

Analysis
---------------------------------
Hit Rate of 100.00% is Efficient

Indices used:

Index Name : idx_sAMAccountName
Record Count: 1 (estimate)
Index Type : Normal Attribute Index

So as you can see when data were cached in memory results are the same, which also proves that data read from the disk is expensive operation (which was obvious ;) ).

Just a side note – ability to see number of pages read from the disk is AFAIR introduced in Windows 2008. Thanks to courtesy of joe ADFIND takes advantage of this and shows this information, which might be handy. .

Conclusions …

Of course this was very simple exercise and if we want really test ESE database engine behavior in different scenarios we should run many queries in different setup, using indexes or not. But I doubt that results will show any dependencies as ESE which is under the hood of AD is just database and object hierarchy is just information in this database.

So if you will consider how your query is constructed in terms of scope and filter, is it efficient or not, is it using indexes it will ensure that it will run efficient on AD without any problems caused by this particular directory logical OU structure.

So conclusions at this point are:

Always analyze your queries in terms of being efficient in terms of scope, filter, indexes etc. Of course if this is one time query maybe you can run it even if it is not the best one you can build, but if this is application or script which will be used more often remember to check its statistics and efficiency.
Try to avoid extensive data read from disk, which translated to domain controller world can be expressed as “try to get as much memory as you can to fit your DIT data in your cache”. If your DIT size is getting closer to 3GB time to think about switching to x64 architecture (with W2008R2 it is time to switch anyway).

And with this I will end this post as it it much longer than it should on this topic ;).

PS. If somebody with greater experience has something to add especially in terms of building efficient AD queries etc … comments are here for You :).

Geneva Beta 2

tomek — Sun, 31 May 2009 17:08:00 GMT

A bit late news but during TechEd which took place some time ago a new release, Beta 2 of Geneva family was announced. For those who are not familiar with Geneva it is code name for new family of products around federation and identity management.

(cc) loops

Geneva product family id build from three components (in very simple words):

Geneva Framework, which gives developer easy to use in .NET framework which will help them develop claims aware applications which may work with STS and CardSpace. Geneva Framework will make development of “identity aware” applications easier.
Geneva Server, which delivers next version of federation services on Windows Server platform. Geneva Server also delivers Security Token Service (STS) which can issue claims based on different data source (AD, AD LDS, SQL as a source is built into this beta). Geneva Server will also support federation between corporation world and cloud services.
Geneva CardSpace, which is new version of CardSpace client included in Windows as a client component. This version includes UI improvements and supports Geneva product line. More on this topic can be found in video posted on ID Element.

Geneva solutions can be downloaded through MSDN pages.

With Geneva Beta 2 release some additional materials was published which allows knowledge about Geneva to be expanded a bit. Those materials are:

Identity Developer Training Kit, which is self study material for developers how to enable applications with claims and how to work with Geneva. More about IDT can be found on Vittorio’s blog.
Complete set of VMS and step by step lab materials which allows quick start to play with Geneva in few common scenarios.
Geneva Interop Whitepapers, describing interoperability configuration between Geneva and Sun and Novell solutions.

To make this list complete ID Element released few new video materials related to Geneva and its new release. A lot of information for those who want to gain some new knowledge.

Well … real men don’t mind son as well

tomek — Tue, 12 May 2009 21:33:00 GMT

Sander wrote few days ago that “Real man have a daughters”. I even don’t know what real man definition is but I would say that if I fit into this definition I don’t mind to have son and I’m really happy and proud that our family has new member.

Wojtek was born on 6’th of May and this also was beautiful day to be born :).

Today is Sunday (still) so new download info arrives

tomek — Sun, 26 Apr 2009 21:07:57 GMT

Sunday evening is a good time (after busy day and week) to scan through feeds and other things in my news inbox. I found two things which I want to share with you.

(cc) bobafred

First is a new version of Microsoft Product Support Reports. If you’ve worked with PSS there is good chance that you are familiar with those tools. If not – well MPS is just a bunch of scripts which gathers diagnostic information on a given machine. What is nice about it, is that they can gather this information in a context of given service. What is important for AD troubleshooting might not be so important for SQL. Worth to check and keep in toolbox.

Second link is long awaited “Active Directory Domain Services in the Perimeter Network (Windows Server 2008)”, which simply can be described as document which explains how to deploy RODC in perimeter network. It enhances concepts from RODC deployment guide published some time ago with perimeter network deployments. Have a fun.

NYT wrote “about me”

tomek — Sun, 26 Apr 2009 20:47:51 GMT

Huh, I wish to know how many of readers really thought that NYT had used some of its Internet space to write about my little person. I’m not that famous .. yet ;). So if this is not really about “Tomek” what it is about?

How many of You know persons who are committing their time to help others on various forums \ web pages \newsgroups? I have to admit that I’m one of such persons on my own and as it is harder and harder to find time for such activities I still can’t find a strength to remove this position from my daily activities ;). Probably You know many as DirTeam.org origins from MVP community so probably you are familiar with MVPs.

(cc) 7-how-7

NYT wrote about such persons in a bit more commercial context, how big companies are starting to see value in such communities and are trying to boost existing or build a new one around their products \ companies. It might seems obvious that they can benefit from such move, but I observer that more and more companies are following this trend.

So it is no surprise that Sean (Big Hello ;) , man who had run MVP program at Microsoft for long time is working in this space on his own (Good luck).

I enjoyed to read it so maybe you will enjoy it as well.

We are chasing time … or time is chasing us

tomek — Fri, 24 Apr 2009 21:31:46 GMT

“Virtualization is a bless” I wrote not so long ago (or lets just say that close to that – maybe different wording) and I didn’t thought that I will get back to virtualization topic so quickly. This time it was triggered by article wrote by one of Polish sys admins who had a rather non pleasant adventure (link if for those of You who can read Polish) with DCs and virtualization. After rebooting his VMWare ESX server with DC (playing also a role of PDC Emulator and time source) caused by some patches being applied to ESX he found out that time on his DC was set back to 1970-01-01 (what a pretty date … isn’t it :). This is short version of his adventure as I assume that most readers on this blog are not very skilled in Polish ;) .

(cc) badboy69

Problems with time synchronization in virtualized environments are well known and are not limited to single virtualization provider. That is a tradeoff of using it … but better know what we are dealing with.

Time as we know is playing important role in AD infrastructure. Most of us will recognize time as important factor in Kerberos authentication process. But unexpected and uncontrolled time drifts might have some other, not necessary desired consequences.

So we have our DCs virtualized and everything works fine … until one day … surprise … like in example I mentioned earlier our time drifts back to some date like 1970-01-01. Or it might drift into the future to lets say 2011 ? Do we really know what will happen or do we have a plan what to do?

It just came to my mind that this is another topic which probably should find its place in companies DR and BCP plans related to AD. But this is just a side note.

For example when time will drift ahead into a future, further than tombstone lifetime what consequences it will have:

tombstones will get removed
all existing backups will be invalidated.

Let’s just hope that this won’t happen when important OU will get deleted and we were just about to go through recovery process.

So is DC virtualization that BAD!!! Are we really against IT!!!?

If You will ask me I would say – YES, go for it and virtualize your DCs but do this with prober planning and knowledge. Get to know what are the pros and drawbacks, things specific to virtualized environment and possible consequences and plan for it. There is plenty information about this topic so just use it.

First off all I want to point You to recommendation (and this is recommendation not hard requirement, but it is really worth to consider) from Technet documentation:

You should retain one or two physical domain controllers per domain in your Active Directory infrastructure. An issue that is specific to virtualization software or the hardware on which it runs can interrupt services on every domain controller in the domain, or even in the forest. If possible, diversify the hardware that you use to host domain controllers so that a single hardware issue cannot interrupt your Active Directory services.

My personal opinion is that this should be considered as really vital recommendation and if it is possible one should stick to it. Of course if we have such physical machine acting as DC (getting back to our main topic – TIME) we can think about making it an authoritative time source in our domain infrastructure. Why not … if we have it anyway.

But if we want to go and put all of our DCs on virtualized hosts it is worth to read some documents and plan time synchronization in align with these information. In particular if we are talking about VMWare environments it is worth to read:

What I can recommend is that such important AD infrastructure element as time synchronization should not be carried out and handled by a guest OS which synchronizes its time with virtualization host (as well we should not relay on routers or other pieces of network infrastructure). If host-to-guest time synchronization is enabled for a DC OS we should disable this option (and this is also recommended in VMWare document mentioned above). In regards to VMWare documentation – they are not consequent in their recommendations as in other document (VMware Time Sync and Windows Time Service) enabling host-to-guest time synchronization is recommended to be enabled.

But if we really want to give a go to virtualization and virtualize our DCs one of things which should be taken care of in service design document is time synchronization.

If this is an option time should be synchronized with external, trusted sources and it should not rely as NTP server or device which will synchronize it with some atomic clock. I’m not real VMware expert, but even in such environment NTP server can be enabled on ESX server and used to synchronize time among virtual hosts … so we can use it also for quests. This will be much better option then just relaying on a server hardware and virtualization layer.

So to get to the point of this already too long post … keeping to current trends and using virtualization for our DCs can give us some benefit. To not ruin those benefits with unexpected outages it is better to do some planning upfront and be sure that our infrastructure is resilient for incidents like clock reset on single host. With little planning this can be avoided. Lets just try to remember that hypervisors are just another piece of software (nice one but still) and as such it might have a problems … .

P.S #1 If we are on virtualization topic – just a friendly reminder – using snapshot as backup method is EVIL ;)

P.S. #2 Jorge has put together links to few documents which touches DC and virtualization topic. Worth checking.

P.S. #3 It is a long one …. sorry ;)

Default Account Operators permissions on DC object

tomek — Thu, 23 Apr 2009 20:40:00 GMT

Active Directory Documentation Team has put on the web interesting post about default permissions of Account Operators (AO) group which might be present on DC object as a result of ACLs placed earlier on computer object.

(cc) ph0t0 {loves you too}

In short words:

AO are being granted permissions to manage many objects in a domain, among others also computer objects
By default AO are being granted with Full control permissions on computer object.
If such computer will be promoted later to DC role these permissions last on this object

Effectively giving AO Full control right on this object.

It applies to objects created in Windows 2003 and Windows 2008 R2 based directories
It doesn’t apply to directory created from the scratch with Windows 2008
Remedy is simple:
- Just edit object’s ACLs and correct AO permissions to meet your organization standards.

In general I don’t like to repeat other posts but I thought that this one is interesting.

Air, fire, water, earth … identity

tomek — Mon, 20 Apr 2009 19:40:00 GMT

People used to believe in four elements, but it showed up that in our times and Internet era there might be one more – Identity element. Donovan and Vittorio started new series of videos on Chanel 9 with this name:

So far there is only introduction to a series and video interview with Stuart Kwan about Geneva Server but knowing both gentleman it might be pretty good source of information what is going on in Id world from MSFT side.

How to cover un-covered – the case of missing subnet

tomek — Wed, 08 Apr 2009 18:36:36 GMT

Few days ago my colleague at work pointed me out that I had not created a follow-up to my article about site location which was requested by some users in comments on my Polish blog. When one started this whole blogging thing one has to deal with consequences … time to write something few simples things which will allow to put more control on the process of DC location.

(cc) Martin Deutsch

Let’s start with some problem statement background. It all started with a thread on Polish Windows User Group portal where discussion was around how client is locating DC and how this process will behave in a little messy environment where not all subnets are reflected in Active Directory objects which are assigned to proper subnet. As some sort of solution a supernet subnet object was created and assigned to hub localization with intent that all workstations in subnets which are not assigned to any site should use hub for authentication.

As it might look at the first glance that this idea is reasonable it is not and it might cause few problems which were actually touched in my previous post.

Network design …

For start we should take a look at network and AD objects configuration. Lets assume that we have in our network three subnets and two sites created in our directory:

Default-First-Site (IP subnet: 192.168.1.0/24), DC –> LHFDC01
DMZ (IP subnet: 192.168.2.0/24), DC –> LHFDC02

This left us with third subnet which is 192.168.3.0/24, which is full of workstations (as C class subnet can be :) ) and is not reflected in subnet object at directory level thus it is not configured to use DC from any of our sites. Somebody has missed this detail … it happens.

So our problem is how we can control domain controller location process for clients working in this 3’rd subnet.

Some reading …

Just to give us some sort of quick start into this topic I will point everybody to series of great articles created by Jorge on how DC is being located by a workstations: here are parts 1, 2 and 3.

Now with this knowledge we can go to configuration part. Key to be able to control domain controller location process in such situation is to understand what roles DNS is playing in it and how we can use DNS records registration to take a control of it. Each DC by default is registering services DNS records (SRV) of two types (or purposes):

domain wide, which allows this DC to be located by every client in a domain
site specific which purpose is to identify particular DC as serving services in particular site.

Every client will try to determine DC which is closest to him, in particular in its site. However if client is not able to determine such DC or not able to determine its site it will query for all DCs which have registered appropriate SRV records for entire domain and will use it (this is very short description of entire process with some shortcuts :) ). In case of our abandoned subnet client is not able to determine its site (bad Admin, bad) and will query for domain wide SRV records. It will be returned with two DCs:

LHFDC01
LHFDC02

will pick one and use it. It will work but maybe not exactly as we would want to.

Configuration part …

Lets try to fix it. Fortunately we are in control of DNS records registration process and we can use it for our purpose. In fact, in our configuration we want to prevent LHFDC02 from registering domain wide records.

What we can do is to create a new OU and put our branch office DCs there (creating OU is one of way how to achieve this – the goal is to apply GPO on DCs, so it might be site GPO as well). Then we will create new GPO object and assign it to this OU. Within this GPO an option “DC locator DNS records not registered by the DCs” has to be enabled and populated with following values “LdapIpAddress Ldap Gc GcIPAddress Kdc Dc DcByGuid Rfc1510Kdc Rfc1510Kpwd Rfc1510UdpKdc Rfc1510UdpKpwd GenericGc”.

Now when LHFDC02 will apply this policy and will re-register its DNS records it will register only records specific to its site. For workstation working in 192.168.3.0/24 subnet it will have an effect that when this workstation will query for domain wide DC records it will be returned only with one record – LHFDC01 (In real configuration maybe we want to have more than one DC here) and it will use it.

And in this way we have solved our problem of missing subnets without causing any other problems which are being introduced by this supernet object and overlapped subnets.

What we can still think about (besides many other aspects) is SYSVOL location process … but this is topic for another post..

Little appendix …

In this post I described how we can address problem of clients working in subnets without site being assigned through configuration of DC location process. However in more proactive way one might monitor DC event log and netlogon log to identify workstations which can’t be assigned to any site, analyze this information and put correct site & subnets configuration in place. Even in some automated way … at least when it comes to identification process. Just food for thoughts … :).

Who needs another DC?

tomek — Thu, 19 Mar 2009 21:41:08 GMT

Active Directory as network service has (at least IMO) one great advantage (some problems can be pointed as well ) – relative simplicity of building service which will be fault tolerant service. With proper design and maintenance it takes some efforts to break AD as a service. It provides:

multiple directory replica with multi-master replication
DC location mechanisms which can be used by client to find other DC in case of single machine failure

So question is why some people chooses to resign from it and not deploy at least one additional DC in their environment.
(cc) sea turtle

I started to think about it after at least few post on different forums (yes I still waste my time on helping others :) ) where some people asked about how to proceed with AD disaster recovery in case of DC failure. What was common was that they were planning for DC failure in environment with ONLY ONE DC. Different approaches were taken, mostly incorporating some virtualization solutions but simplest solution, to add additional DC was often omitted. Why?

So lets do simple exercise and think how simplest recovery procedure will look like in case we have only single DC(1). Big day comes …

our one and only DC fails and we are starting to experiencing problems and outages in our network
If this isn’t hardware failure or we have similar hardware we are restoring backup or installing OS from the scratch

If we don’t have spare hardware we waste some time to find one and install or restore OS

We are restoring our directory from backup, going through all necessary procedures and after 2-3 hours we are back in business.

During those hours:

Our users are experiencing problems with accessing network resources
If our mail system is integrated with directory we might be cut off from mail system
If our internet access is based on AD authorization (proxy) even internet newspapers are out of options:

Minesweeper still is a solution :)

Of course these points are not including that:

we have to start to deal with failure right away because it is affecting our business
<put some name or title here> is standing above our head and is demanding to bring business back on-line
we are assuming that we are perfectly calm and panic is not something which clouds our action :).

In best case single DC failure is causing few hours outage for entire organization. If this organization would have additional DC what would it change to this scenario? When one DC will fail:

probably nobody will notice it as another DC(s) in the network should take care about handling client requests

Developers: please don’t hard code DC addresses or names in apps.

Responsible administrator has a time to finish his coffee and sandwich and read DR procedures (of course if there is one) to decide which procedure should be applied in this particular case.
Selected DR procedure is applied i environment and everything gets back to normal operations.

Main difference here is that we don’t have to react to something which disrupts out business but we are dealing only with single infrastructure element failure. Of course additional advantage is that <put some name or title here> is not standing behind us all the time (however we should incorporate procedure to inform him in our DR procedure).

So .. these things are obvious however what I see, especially from people from small and medium organizations is that simplest approach in this case is often abandoned and some fancy and complex solutions which incorporates virtualization, snapshots etc are considered as a solution. With all clustering for SQL data, load balancing for web apps etc often crucial element which is directory service is being treated lightly.

And this might be all but …

… yeah .. VIRTUALIZATION. It is common buzz word of current time for all IT guys. Often I see that virtualization is being abused as some kind of golden solution to every problem. Of course we can use virtualization for DCs, however I don’t see that this is a perfect strategy for DR:

DC recovery from snapshots is not supported, not recommended and if You want to use it You have to know how to deal with it.
With single DC, even virtualized we still will experience outages, what might be achieved is that recovery time might be shorter.

So virtualization … yes … but not for all DCs (still keep some DCs for each domain on metal box) and do not treat virtualization as main disaster recovery strategy, especially if you want to relay on snapshots or some similar technology.

What do You think about it?

(1) Of course I’m not pretending to describe entire scenario and this isn’t only scenario which should be covered in our DR plan for DS. I just used this very simplified scenario description as an example.

Reverse engineering attribute flows from server export

tomek — Thu, 19 Mar 2009 20:54:00 GMT

ILM (MIIS) allows management agent configuration to be exported in two ways:

Management Agent export
Server configuration export.

Both options produces XML files, however in first case one will get single file which will contain only configuration for single MA. In second case series of XML files will be created, one for each MA and MV.XML file which will contain metaverse configuration.

(cc) scottpargettphotography

Few days ago I had to recover at customer ILM server one agent to previous configuration to restore some flows (I still would like to see option to disable attribute flow without deleting it). As we wanted to restore some flows without touching current configuration I had to analyze previous configuration and see what have to be restored.

With Management Agent export file it is relatively easy. It contains section for import and export flows and reviewing it, while not very handy is relatively easy. But in this case MA export was not available, we had only server export.

This makes this task a bit more tricky because:

respective XML file for management agent configuration contains only export flow sections defined for given MA
each MA is identified through GUID identifier
MV.XML file contains information about all metaverse attributes.

MV.XML for each metaverse attribute contains section, which identifies all import flows for given attribute (per attribute sections) from all MAs. So to recover information about attribute flows for given MA from server export configuration follow this path:

identify XML file for your MA, note GUID identifier and analyze all export flows defined in this MA
open MV.XML, navigate to import attribute… section, for each attribute look for flow defined with Your MA GUID.

Probably if I will have to do again I will write a script to do this :).

BTW – one thing to remember when dealing with server configuration import. If You are performing this operation and it will fail at any step .. DO IT AGAIN FROM THE BEGINNIGN. If this process will be stopped at some stage it will leave your configuration in some “incomplete” state. Now when I analyzed how it is stored in server configuration files I think I know why …

… I don’t know if this will be helpful to a lot of people … but I decided to post it in case it will help at least one person ;).

On a display …

tomek — Thu, 19 Mar 2009 20:34:00 GMT

Back in my high school days I used to play in a punk rock band (if we can call it band :) ). A lot of fun and adventures, few local gigs. Everything ended-up when we started our studies on universities. But it is not my punk rock band which put my name on a display …

Last weekend I was speaking at local community event (C2C 2009) in Poland and when I’ve arrived at place first thing which spotted was this:

I had a good laugh when I saw this poster and I couldn’t resist to take a picture with my mobile. At the same time a felt a bit flattered that someone decided to advertise this event with my name :).

Event itself was great. It was organized only by people from communities who had gathered sponsors and managed to organize event for few hundred of people with 3 separate tracks, 6 sessions each.

Because Windows 7 and Windows 2008 was covered already I decided to make a little experiment and do a talk abut something which is not widely known which is Identity Lifecycle Manager 2. I don’t think that there is a point to explain ILM2 guts to people who are seeing this product for a first time to I decided to do this as a case study demo, to show what can be done with RC0 without any code being written. Demo Gods decided to make it even more experimental and decided to crash my virtual machine a day before :) … it is their weird sense of humor :).

Well … I haven’t got any official statistic or results but in overall I have to say that I feel good about how this session went. Not everything went smoothly and few things from demo didn’t work but it was OK Few people was really interested in product and its usage scenarios and we have some discussions afterwards which I think is some success if You are talking about something which was completely unknown to audience (3 from about 60 persons on a session heard about ILM at all).

Session itself was recorded but as it was in Polish probably it won’t be very useful for You here.

But bottom line is … if somebody in your area is organizing such event … and you feel you have something interesting to say … don’t hesitate and get displayed :). It is really worth to invest your time to support local tech communities. Best way to get MVP if You want it :).

Me and TEC 2009 - update

tomek — Sun, 08 Mar 2009 22:16:00 GMT

Some time ago I wrote that I had been lucky to be selected as a speaker for upcoming TEC 2009 conference. Sometimes one have to change his plans and because of some latest development related to my work I had to cancel my TEC 2009 attendance in Vegas.

I have to admit that I was waiting to go there and I will really miss all this TEC crowd networking and talking through those days. I know that there will be a lot of good technical content but what even more important face – to face meetings and if You are going there try to get best out of it.

As Quest had sustained their invitation (Thank You and sorry for this change) I still plan to attend TEC in Berlin this fall and deliver my sessions.

For all my friends who will make it to Vegas I dedicate this Wulffmorghentaler comic strip :).

P.S. If You like this kind of humor Wulff just rocks :).

And you will keep your password updated …

tomek — Wed, 04 Mar 2009 21:52:00 GMT

Implementing effective password policy was always a hard task. Especially when additional accounts like:

workstation local administrator account
services account (look for W2008R2 new features)
name whatever you want account …

comes into equation and you have to make sure that all of them are in compliance with password policy of your company. Not always an easy task.

(cc) F8th

For domain controllers additional password has to be maintained which is Directory Service Restoration Mode (DSRM) user password. This password is stored locally on each DC and if it has to be changed it has to be changed locally on each DC. So far we had some options like:

using setpwd.exe tool which can be used to reset this password. Dean (now MSFT) Wells wrote script which depends on this tool but allows this operation to be performed on every DC in a domain.
using ntdsutil.exe, which to be honest isn’t most handy tool to perform this task.

Well … it looks like feedback was heard and as result of this feedback we have new KB 961320 article which describes new feature self explained by this KB title: “A feature is available for Windows Server 2008 that lets you synchronize the DSRM Administrator password with a domain user account”.

I have to admit that my first thought was … great, now we can:

Define new account
Define new password policy object (we are at W2008 so we can leverage FGPP) and bind it to this object
Create operational procedure to ensure that password of this account will get changed every X days.

Sounds nice, DSRM password management problem is solved. But life isn’t perfect. My colleagues who read that article a bit faster than me pointed me to this section:

This command synchronizes the DSRM Administrator password one time. If you want to perform another synchronization, you must run this command again.

So, our previous implementation plan has to be extended with something like:

On each DC create scheduled task which will execute ntdsutil command every X days or execute it remotely on each DC every X days.

Overall solution looks somewhat better than using script every X days to set this password however it isn’t perfect. I have this impression that development of this feature stopped at some point in time but I’m sure we will get updates to it later (or at least I hope) which will extend its functionality (like reset password when password will be changed on given user object).

But this feature is there as a hotfix and if You think that your network operations can benefit from it – grab it and use it.