Tomek's DS World

... You want to have Your own blog with fresh content ... on different topics ... just steel this post like Deepak Gupta is doing.

Lately he wrote about maximum limits in AD, just like I did. He wrote also about Hyper-V new features, exactly as Natasha did on her blog.

Maybe I should be flattered that I'm writing something interresting but probably he is just copying entire DirTeam site.  My friend Andrzej some time ago also had a problem with person who was stealing his posts. This is starting to be some kind of new plague affecting Internet.

I hope that this post will also get stolen by Deepak and will make him more happy as a content author. I hope it will also hit his front page and I really hope that it will pop-up from time to time in search results for somebody who will look for his name.

Sorry for all who are reading this blog for its technical (and maybe not only technical) content. This post is for Deepak ... I hope he will steal this post as well and will display it on his front page.

Have you ever wondered how many objects You can create in Your DIT (actually this was showed some time ago by ~Eric) ? Or how many DC is to many in a domain? 

For some time now on one of MS internal distribution groups group of folks were discussing document which describes such limits related to AD (BTW - possibility to be a part of such discussion is one of greatest things related to be an insider). This document is now published. It is short but provides all information, check it out - Active Directory Maximum Limits.

BTW - if this just happens that you are a customer who is near of such limit or had actually crossed it (if this is related to number of objects - call PSS :) ) I would be happy to hear about it either through comments or through e-mail. So far I worked with one particular customer who has actually crossed one of such limits - this was about number of DCs in single domain. But this isn't hard limit - is it more like recommendation and if You know how to handle this You can live with it.

So ... another interesting reading.

Handling time is somehow challenging task. It can;t be stopped so far so we have to live with schedules and clocks. But this won't be about time physics but more mundane thing.

One of my friends has asked me question how to translate pwdLastSet attribute value to some more readable value. My first answer was - what a suprise - adfind.exe. Adfind handles such things pretty well:

C:\Temp>adfind -b "CN=Administrator,CN=Users,DC=w2k,DC=pl" -s base pwdlastset -tdc

AdFind V01.37.00cpp Joe Richards (joe@joeware.net) June 2007

Using server: W03DC1.w2k.pl:389
Directory: Windows Server 2003

dn:CN=Administrator,CN=Users,DC=w2k,DC=pl
>pwdLastSet: 12/22/2005-17:18:55 Central European Daylight Time

Hmmm ... but his answer to this was:

'adfind.exe' is not recognized as an internal or external command,
operable program or batch file.

Well .. if You are getting similar message it is time to change it - get adfind as soon as you can. It will make your AD-life easier. But we are still with a problem - how to translate pwdLastSet attribute value stored as  Interval to readable content using system tools or tools delivered by Microsoft (in some environment using third party tools is not something which You can do) 

So let's start with some AD pick lock which is LDP.EXE. IN version delivered with Windows 2003 and later it does this magic for us:

CN=Administrators,CN=Builtin,DC=w2k,DC=pl;
    1> pwdLastSet: 12/22/2005 16:18:55 Central European Standard

Next tool we can use us well known repadmin.exe with /showtime switch. What we will have to to is remove from this value 7 rightmost digits and pass it to the tool:

C:\Temp>repadmin /showtime  12779738335
12779738335 = 0x2f9bb54df = 05-12-22 15:18.55 UTC = 2005-12-22 16:18:55 local

 

And last tool I will mention is finally something which is at least related to time,  w32tm.exe with /ntte swithc:

C:\Temp>w32tm /ntte  127797383352618256
147913 15:18:55.2618256 - 12/22/2005 5:18:55 PM (local time)

So as You can see our toolbox for this task is pretty rich ... but still, if you can grab a copy of adfind and use it. It is really great tool

Last weekend I was attending (or better to say I was just passing by as it was short visit) conference organized by some .NET developers and SQL users groups called Community to Community 2008. If You ask me this was really cool event if You think that it was organized only by people from communities and free to attend for all. Hope we will get more of these in Poland soon.

But this isn't my main topic here. I had time to attend only one technical session which was delivered by Marcin Szeliga - Polish SQL MVP. He was talking about SQL 2008 and changes in this product related to security. I'm not really SQL type of guy but I managed to understand most of it :) but he really got my attention when he started to talk about changes in authentication and Kerberos support.

What have attracted my attention was statement that "SQL 2008 doesn't require Service Principal Names to make Kerberos to work anymore, instead of this You can specify SPN in connection string". Hmmm ... I've confirmed what he had said with him after the session and I've said that I will check it ... so here I am with conclusions.

BTW - are SPNs really such problem?  I know that it tends to be a problem when it comes to application deployment \ configuration. This is first thing which is likely to be forgotten or which will cause a problem to be configured. It often requires to get to domain admin who has rights to write to servicePrincipalName - I don't know why they are not delegating this for service account which is being used during deployment.

OK - so getting back on track. So during this session I've heard that SPNs are not necessary to be registered and can be specified in connection string. I dug a bit and as often is showed that as often there is a piece of truth in this statement.  SQL 2008 has some improvements in Kerberos support and when it comes to SPNs:

• Yes, You can specify SPN as a part of connection string and this is optional
• Yes, You still require SPNs to be registered for SQL service if:
• You will not provide SPN in connection string
• You will provide SPN in MSSQLSVC/FQDN:<port|instancename>
• In case You will provide SPN as a part of connection string service itself will not try to construct SPN and will use the one provided
• so make sure that You have double checked Your configuration settings :)
• You don't have to register SPNs for SQL service as long as you will always provide SPN as a part of connection string and You will use one of following formats for it:
• serviceacount@domain - which basically is UPN for service account
• domain\serviceaccount - which points to specific logon name in domain
• machine$@domain - I haven't checked SQL documentation but this probably is valid only when SQL works on one of system built-in accounts
• host\FQDN - with same note as above.

So this fits better to what I know about this stuff :).

So good to know about such changes. I'm afraid that it will cause a bit of mess in deployments of applications as right now nobody will talk with directory admins when application with get deployed and then this admin will be the one who will have to solve authentication related problems ... which might be incorrect SPN in connection string.

So just FYI ...

Wave of information has started to spread across the Internet that RSAT has been finally released for download. So here are links for RSAT download:

• 32-bit
• 64-bit.

All of you who have deployed Windows Server 2008, especially as Core version should like this information.

This isn't something which is in line with my day to day work, however this is something which may affect many organizations so I've decided to add my blog to list of sties which will duplicate this information.

Secunia has reported critical vulnerability in MIT Kerberos implementation which can result in remote code execution, DoS or information exposure. I will not cover details as it is all described in Secunia advisory. CERT has also covered this in their bulletin.

As far as I know Microsoft Windows Server Kerberos implementation is not based on MIT and isn't affected. I think that this will be reflected in CERT information soon.

However MIT Kerberos is widely used in various Linux \ Unix systems, Mac OS X and products like Centrify so maybe You want to check if one of Your systems is not affected by this.

When we are in Kerberos neighborhood - when I was reading through Jackson Shaw's blog I found information about establishing MIT Kerberos consortium. Microsoft has also joined this organization. We will see in feature if this will bring something to us as Kerberos users. Hopefully we will see something ...

In case somebody missed it - Microsoft has published lately technical specification for its products. Result of some trials before European Union Committee (I still don't like this institution). 

Among other documents you can find there Active Directory Technical Specification. And now everything is clear about AD ... isn't it :).

Time to find some nice place and retire :).

My post about confidential attributes is one of most popular on this blog. So far it had 2950 views. By the way, most popular posts are about drink attribute in AD (4118 views, taking under consideration subject of this post it is not surprising ) and my notes about extending schema in AD (5523 views).

So it looks like most or readers of this blog are extending the schema, then drinking something (is it related to results of schema extension operation ?? :) ) and when they are under influence of some liquid substances they are trying to cover something in AD. Pretty nice combination ... :).

Because of that I've decided to give this topic some update with respect to new things in Windows 2008. Nothing very new in schema extension or drink attribute so it has to be something related to confidential attributes :)

OK, there is nothing really new with confidential attribute itself in Windows 2008. It is being managed and configured in exactly the same way as it was previously so You can still use information from my previous coverage of this topic. However we have in Windows 2008 two new elements which are affecting way in which You want to use this feature. These are:

• Read Only Domain Controller (RODC)
• Auditing of attribute changes.

Read Only Domain Controller

RODC is a DC which is holding read only replica of directory data and is configured in such way as we are considering this host as *unsafe* for some reason. Maybe it is in un-secure location or is deployed in DMZ. The point is that we might not necessary want to replicate sensitive data to such DC.

RODC provides You with such capability through Filtered Attribute Set (FAS). FAS is set of attributes which are not being replicated to RODCs. In addition attributes from these set are being stripped from IFM media created for RODCs promotion.

Attribute assignment to FAS is being controlled through searchFlags attribute value on this attribute schema definition in schema. Using example from previous post and attribute lbUserPesel. It is marked as confidential, not indexed so it search flags has value 64 (0x40):

C:\Temp>adfind -b CN=lb-UserPesel,CN=Schema,CN=Configuration,DC=w2k,DC=pl
-s base -flagdc searchFlags

AdFind V01.37.00cpp Joe Richards (joe@joeware.net) June 2007

Using server: LHFDC1.w2k.pl:389
Directory: Windows Longhorn

dn:CN=lb-UserPesel,CN=Schema,CN=Configuration,DC=w2k,DC=pl
>searchFlags: 128 [CONFIDENTIAL(128)]

Membership in FAS is being controlled by bit in this value ( hex 0x200 or decimal 512). So to make our attribute confidential and member of FAS we have to set searchFlags to 0x280 in hex or 640 in decimal.

C:\Temp>adfind -b CN=lb-UserPesel,CN=Schema,CN=Configuration,DC=w2k,DC=pl
-s base -flagdc searchFlags

AdFind V01.37.00cpp Joe Richards (joe@joeware.net) June 2007

Using server: LHFDC1.w2k.pl:389
Directory: Windows Longhorn

dn:CN=lb-UserPesel,CN=Schema,CN=Configuration,DC=w2k,DC=pl
>searchFlags: 640 [CONFIDENTIAL(128);EXCL_RODC_PAS(512)]

(In this result FAS is still mentioned as PAS - this was changed in RTM).

After such change our confidential attribute will not be replicated to RODCs. If it was already replicated it will be removed from RODCs database after replication.

One advice which was expressed by Jorge during his session on last DEC. If You are planning RODC deployment in environment it is nice to think about what to include in FAS before actual RODC deployment. This will prevent these attributes from replication during promotion of DC and later it will not require removal of these values from RODC database.

Auditing of attribute value changes

Windows 2008 introduces new auditing capabilities which stores in auditing data information about values of attributes being changed in event log. For each attribute we will see in event log information about old and new value of attribute, related to each other with correlation ID value. This might expose confidential data to persons who has access to Security log. Let see what we will see in Event log when we will change confidential attribute using ADMOD.EXE:

admod -b "CN=Joe Doe,OU=SensitiveDataUsers,DC=w2k,DC=pl" lbUserPesel::123456789

In Security log we will see three new entries:

In entries with ID 5136 we will see following information (I've stripped some information to make it more readable):

(...)
Object:
    DN:    CN=Joe Doe,OU=SensitiveDataUsers,DC=w2k,DC=pl
    GUID:    CN=Joe Doe,OU=SensitiveDataUsers,DC=w2k,DC=pl
    Class:    user
Attribute:
    LDAP Display Name:    lbUserPesel
    Syntax (OID):    2.5.5.4
    Value:    123456789
Operation:
    Type:    Value Deleted
    Correlation ID:    {baa43f87-336d-4d83-a4fb-5aa397bc23b9}
(...)
==========================================================
Object:
    DN:    CN=Joe Doe,OU=SensitiveDataUsers,DC=w2k,DC=pl
    GUID:    CN=Joe Doe,OU=SensitiveDataUsers,DC=w2k,DC=pl
    Class:    user
Attribute:
    LDAP Display Name:    lbUserPesel
    Syntax (OID):    2.5.5.4
    Value:    1234567890
Operation:
    Type:    Value Added
    Correlation ID:    {baa43f87-336d-4d83-a4fb-5aa397bc23b9}
(...)

So as you can see our confidential attribute values were stored in event log entry and are now accessible to anyone who has access to these data or event log entries gathered in some management system.

In Windows 2008 we have a way to hide attribute for being audited, also through searchFlags attribute bit - this time it is Hex 0x100 or 256 decimal. So to make our attribute confidential, FAS member and excluded from auditing we have to set its searchFlags value to 896 or 0x380 in hex:

adfind -b CN=lb-UserPesel,CN=Schema,CN=Configuration,DC=w2k,DC=pl -s base -flagdc searchFlags

AdFind V01.37.00cpp Joe Richards (joe@joeware.net) June 2007

Using server: LHFDC1.w2k.pl:389
Directory: Windows Longhorn

dn:CN=lb-UserPesel,CN=Schema,CN=Configuration,DC=w2k,DC=pl
>searchFlags: 896 [CONFIDENTIAL(128);EXCL_RODC_PAS(512);UNKNOWN_FLAGS(256)]

When now we will make a change to our attribute we will see only event with ID 4662 and any of these 5136 events.

Our confidential attribute will not be stored right now in auditing data.

And that basically it about how to protect our confidential attributes when Windows 2008 will be deployed in our network with all new things like RODC and new auditing.

Today through one of Polish blogs related to gaming (yes, I own Xbox 360 and I use it from time to time to play ... and yes ... I think that Halo 3 s..ks ... just adding it here as I know that it rises some controversy when I said sitting in the bar at DEC. Mostly because I'm MS employee :) ) I came across this post. 

It describes how old classic Donkey Kong was developed and how games development looked like in these times. Worth to read ...

I was attending DEC 2008 this week. Few words about conference will show up later on this blog, right now I just want to share two links with You which was presented during Markus Vilcinskas session on DEC.

First one, Implementing a Lightweight Metaverse Search, is about searching metaverse data through some additional configuration and application. If You look for a way to create search interface for Your ILM implementation this might be a way to do this.

Second one, Correcting Incorrect Joins, describes how You can approach problem of correcting in automated way joins, which are initially done wrong (for example same ID assigned to two different users in two systems. This one, and presentation about it I found particularly interesting, as I've deployed exactly this method almost two years ago as a part of customer implementation. Now I know that this is something which is recommended :).

For those who are interested both documents are available as a part of getting started documentation on Microsoft Downloads.

Just quick download information drop - new documents from getting started series has been published on a Web (at least I found them now :) ). Looking on a topics coverage this might be useful series for any starting ILM newbie. Shame to admit but I haven't seen these documents before or I don't remember this fact.

It is a bit quiet here right now - mostly because I've spent a lot of time lately developing presentation for internal TechReady Microsoft's conference. This will be my first time doing session in English so it might be a bit of fun (especially that we are doing live demos during this session, and live sometimes are not so live :)). Anyway - if You are MS employee and You are on TR6 please find my name in session schedule on Friday morning.

To readers of my Polish blog (if any here) - because of little disaster my blog is off-line now. Because I'm in States I can't fix it now :(.

ILM 2007 delivers ExchangeUtils class which can be used to provision new Exchange enabled objects into Active Directory environment. This is nice and easy to use API, however it has one disadvantage - it will not allow to provision mailbox for existing Active Directory account.

As this isn't preferred way to do this sometimes You have to provision users first and then mailboxes. If you have to do it in Exchange 2003 environment You can use information provided in old KB 275636 article, which discuss how to provision mailboxes with MMS. Just build Your attribute flow to populate these attributes and RUS will take care about the rest.

What is not mentioned in this article and what You may want to do is to set additional attribute mDBUseDefaults which when set to True will indicate that store quota setting should be used for this mailbox. This isn't mentioned in this article but will probably be required  by Exchange administrator You will work with on such implementation.

And remember - test it first in the lab :).

For all interested - quietly SAP MA for ILM 2007 has been updated and published on Microsoft Downloads.

From what I know this update contains minor bug fixes made after initial SAP MA publish date back in May 2007. If You have this solution deployed in production remember to test this update first in test lab (You have test lab, do You? )

MIIS newbie was a bit quiet on a blog for some time but he is still around. Actually I think that right now it is ILM newbie as product name was changed.

In this tale I want to gather few comments on a best practices around building ILM extensions. What I mean by best practices?  Sometimes it is very tempting to do something in ILM extension code or somebody starting adventure with ILM is looking for some ideas how to solve problem and plan attribute flow etc.  In many cases people are coming to similar, but not necessary good conclusions which are leading to not stable or not predictable ILM implementations.

I saw examples of such in few cases and I saw even more questions regarding such cases so I think this is some kind of pattern which has its roots in scripting approach, experience with other systems etc. Most of such problems can be easily avoided if one will stick to few simple rules in ILM extensions approach. This is what I will refer in this note as "best practices".

Maybe this will not be something deep technical but I can see questions from user here and there which are around this so ... lets our list begin.

1/ Call to external data sources from within the extension

We are building our solution, we have to plan provisioning \ deprovisioning logic, attributes flows, precedence etc. And all of this has to be based on content of connector space and metaverse. This might be a little tough and frustrating at the beginning and I will not be surprised if thought similar to this will came to somebody's mind:  Dood .. this is so limited - maybe I will just make a call to external database or AD and I will check if this account or attribute exists. This will make my logic easier and I will not have to trouble with this whole CS and MV stuff.

At a first view this isn't something which looks bad. Call to some data source from .NET is fairly easy in most cases and I admit that it can make ILM design easier. For example if You want to determine unique CN for an AD object getting data from AD is simpler than building such based on metaverse data only. However this approach brakes  IMO most basic rules of ILM design:

• synchronization should be independent from data sources. ILM introduces concept of connector space, which is vie on a data source, and whole synchronization logic should be built around data available in connector space and metaverse. If You miss these data ... go and figure out how to get them there.

No to say that this might affect performance of whole solution. Calls to external data sources and in most cases establishing new connection to this data source is something which might be considered as a bit expensive operation which might affect whole synchronization process performance in a great way (I know about a case in which calling to AD controllers spread on the world caused that synchronization process took few days to accomplish). 

Conclusion: Avoid doing external data source calls from Your MA and MV extensions. If You need data for Your logic - go and configure MA or build one, get these data into connector space and then into metaverse attribute. This is how it should be done.

2/ Attribute flow and MA execution order dependencies

Another thing which I can observer in peoples questions and some code examples is building synchronization logic with assumption regarding which attribute will be present and which MA import attribute flow will be triggered first during synchronization cycle.

This is completely wrong as Your synchronization logic should not rely on things like:

• attribute flow order: flow configuration in GUI does not mean that these flows will be executed in this order. You can't rely on this. I was involved into MIIS implementation troubleshooting in which I was not able to reproduce error and it still showed up from time to time. MA extension code analysis showed that there was assumption made in extension design phase which attribute will flow first and it was used in code. I wasn't lucky enough to catch the case in which it failed in tests, however it was failing from time to time in production.
• MA execution order: You can't assume and build Your design \ extensions with particular MA run profiles execution order and expect it to be error prone in this way. Somebody might change script and put MA run profiles calls in other order - what then? Build your logic based on attributes and fact if attribute is present or not.
• object export order: You can't rely in your design on particular object export order. For example you can't expect that if you will provision in single synchronization step both OU and user which resides in this OU You can't expect that OU will be exported to AD always before user will be exported there. If you want to have such kind of logic You have to build it on Your own in Your design.
• values order in multi valued attributes: last thing to mention here ... if You want to have multi valued attribute values in particular order .. sort it on your own.

If You need to rely on some flow order for example there are technical possibilities in ILM which allows You to do this in controlled way:

• transaction properties: allows you to pass information within single synchronization process between different components and through flow (IAF -> MV -> EAF) elements. I'm not a big fan of using transaction property but this is something which can be used.
• contribution MA and contribution time: allows you to check which MA and when has contributed to this particular attribute.

If You have to do this, do this in controlled and smart way - don't make assumptions.

Conclusion: don't rely on events \ flows etc order, think about your design as about something which has to execute properly in all circumstances. No matter if somebody will run SQL MA or AD MA run profile first. Handle errors, check for attributes, check if something happened before You will proceed with 2'nd step. 

3/ Full and delta synchronization assumptions in code

This one is simple - if Your attribute flow is being executed properly in full synchronization run profile it should also execute properly in delta synchronization run profile. Whole process and logic should be build in the way in which it will be independent from all environmental elements like MA execution order or type of synchronization.

Conclusion:if your run has for the same flow different results in different run profiles go and check if You haven't done some assumptions (see (2) ) which causes such behavior.

Personally I think that this list might be extended with few more points ... but maybe in next post from this series.

ILM newbie over and out (for now).

No .. this will not be about changes in management @ Microsoft - if some changes will happen I will leave comments to it to mini. We have our new CEO in a little smaller company called Our home.

He has black fur and he's British. Photo from his business profile is presented below.

For now he has some advices how I should use my notebook's keyboard and removed two keys from it. He also shows some interest in electricity, especially with cabling. I have to do something about it before he will hurt himself.

Anyway ... more pictures probably will show up here in the future