My quest to bring Best Practices to Identity Management especially with Microsoft FIM / ILM

Monday, June 29, 2009

The attributes behind Message Delivery Restrictions

Do you know what attributes are used to control who can and can't send to a Distribution List in Exchange 2003 and Exchange 2007? or Does it use a DACL?

Knowing such things is key if you are going to automate distribution list management through .NET programs, or MIIS/ILM/FIM, Quest ARS or any other tool that is talking to LDAP attributes. For Powershell you need a separate list since the names are different.

Seeing as how a picture is worth a thousand words I'll include some after a brief explanation:

At first I was afraid that it used the SendTo permission on DACLs but fortunately that is not what the Exchange GUI tools change. This is fortunate since ILM does not have an out of the box MA that modifies DACLs on AD objects, it is also fortunate since programming against DACLs is somewhat complicated. I must give thanks to my friend Joe Kaplan and his co-author Ryan Dunn for the helps in their book (see page 302 listing 8.2 listing the DACL) and their forum http://directoryprogramming.net/default.aspx

The .NET Developer's Guide to Directory Services Programming

With the help from their book I was able to eliminate DACLs since the darn things never changed. FC never lies.

Open the Exchange Console, navigate to the Distribution lists open their properties and go to Mail Flow Settings click on Message Delivery Restrictions and then click on the Blue check mark next to Properties:

image

So what I found was five attributes that control the fate of who can and who can't send to a particular recipient (in this case a distribution list)

authOrig, unauthOrig, and msExchRequireAuthToSendTo,

Attribute Name Name in GUI Explanation Powershell (Set-DistributionGroup) 
Just as an FYI
authOrig Accept messages from
Only senders in the following list:
If this attribute and dLMemSubmitPerms are both empty then that is the equivalent of All Senders. If populated only those recipients and the members of Distribution Lists enumerated in dLMemSubmitPerms can sends listed can send items to this distribution list minus anyone listed in unauthOrig and anyone that is a member of distribution lists enumerated in dLMemRejectPerms -AcceptMessagesOnlyFrom
dLMemSubmitPerms same as above see above -AcceptMessagesOnlyFromDLMembers
unauthOrig Reject messages from
Senders in the following list:
Prevents recipients listed here from sending to this Distribution list

-RejectMessagesFrom

dLMemRejectPerms same as above Prevents recipients who are members of the Distribution lists mentioned from sending email to this Distribution list

-RejectMessagesFromDLMembers

msExchRequireAuthToSendTo Require that all senders are authenticated When set to True only authenticated users (no external users) can send mail to this Distribution list

-RequireAllSendersAreAuthenticated

For more info on attribute to Powershell attribute name conversions see

http://blogs.technet.com/evand/archive/2007/02/19/filterable-properties-in-exchange-2007-rtm.aspx

For more on the Powershell commands with some examples see

http://technet.microsoft.com/en-us/library/bb397214.aspx

What would be really nice would be if FIM 2010 already had the schema and OVC extended for this. Since this is the very next thing people at a big company ask for after finding out they can automate distribution list maintenance.

As promised some pretty pictures to help explain (on the left you see the screenshot from ADSI edit and on the right the snapshot of the Exchange Console

authOrig

dLMemSubmitPerms

On this one I reverse the order

unauthOrig

By now you get the idea, that if you select a distribution listt in the Senders in the following list they get put here:

dLMemRejectPerms

So we see that the Exchange Console clever sorts the DLs from the individuals and puts them into their separate attributes.

Labels: , , ,

Wednesday, August 20, 2008

MIIS/ILM Error: System.BadImageFormatException

So I had MIIS 2003 SP 1 reporting to me that the format of my GalSync-Extension.dll is invalid. So I tried recompiling it -- no luck. Same error. The only MSDN article on this indicated that unmanaged code is being passed to the load method.

Through trial and error we found the solution: stop and start the MicrosoftIdentityIntegrationService. If that doesn't work try a reboot.

BadImageFormatException_screenshot

Labels: ,

Wednesday, May 7, 2008

The Grand Unified Demo of Identity Management

As I was architecting and assembling the Identity All Up workshop (part of the 2008 Directory Experts Conference see the review by Felix Gaehtgens, an analyst for Kuppinger Cole) designed to expose the attendees (or delegates) to all facets of the Microsoft Identity Access Platform, Lori Craw, from Microsoft referred to this as the "Grand Unified Demo". I chuckled, instantly catching the reference to the still undiscovered Grand Unified Field theory that eluded Einstein and even today's theoretical physicists.

In creating and delivering this workshop, I have reinforced, my earlier belief that the Active Directory (AD) is the medium through which most of these interactions happen that allow for interactions between these components of the platform, and Identity Lifecycle Manager (ILM) is the driving force.

Allow me to explain -- In order to manage the lifecycle of smart cards through Certificate Lifecycle Manager (CLM) you must belong to groups in AD that have been assigned permissions to the CLM Service Connection Point, the CLM Profile Template, the CLM Certificate Template, and a group that contains the user upon whom you will act. How do you get into these groups? Through Identity Lifecycle Manager! So AD is the medium and ILM the driver.

In the case of CLM, ILM also has a more direct connection through the Certificate Lifecycle Management agent through which ILM can provision, enroll requests, termination requests, suspend requests, renewal requests, and unblock requests.

Let's take a look at Active Directory Rights Management Services (RMS). With RMS permissions as with most other permissions, they are assigned to Groups in AD. Once more -- AD is the medium and ILM is the driver.

Now please turn your attention to Active Directory Federated Services (AD FS). Users get access to resources at the resource partner by virtue of having claim that gives them access, most of the time this claim will be a group claim. Once more -- ILM is driving through the medium of AD.

Even more, look at AD RMS integration with AD FS. Now we can extend Rights Management protection to documents while sharing them with partners without the unrealistic expectation for the partner to have their own AD RMS infrastructure (the requirement for RMS prior to Windows Server 2008). Once more, access for partners is through being member of a group that establishes an outgoing claim to the resource partner that is then consumed by RMS, and once more the best way to get users into groups is through ILM.

Expand your horizons, once more, now using a smart card (provisioned through an ILM request to CLM), we can authenticate to the Directory build the list of groups to which we belong (managed by ILM), we can access an RMS protected document at a Partner's SharePoint site, and have the appropriate restrictions apply to us.

Wait, what about AD Lightweight Directory Services (AD LDS -- formerly known as ADAM), and Windows Cardspace? Where do they fit in?

AD LDS can be used as another repository for storing identities usually for your extranet, for partners that aren't federation ready (either because of lack of size, technology, or policy). AD FS can use AD LDS as one of its account stores! Hence the same protection of RMS documents can be extended once more to non-federation partners without the need for another RMS infrastructure -- in fact vendors could offer RMS as a service using ADFS and AD LDS to cover the authentication needs.

What about Card Space? Card Space, can also be incorporated, but that is a topic for another day.

I want to give special thanks to Chris Calderon for his tireless efforts in helping me setup the virtual machines and hammering out the AD RMS AD FS integration with Sharepoint. Thanks also to David Wozny (pronounced Wahznee) for improving and delivering the deepdive into CLM. Thanks to Craig Martin for assisting David Wozny in improving the ILM deepdive. Additional thanks to Bob Tucker for helping with the VM setup. Thanks to Hugh Simpson-Wells and James Cowling for editing the labs. Thanks to James Booth for listening and improving while I dreamed up the scenarios used in the labs.

Labels: , , , , , ,