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:

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

On this one I reverse the order

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

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

H30, Geneva Cola, Sitrus and Orange Fizz

Back in business school I was a connoisseur of fine commercials.  Recently I watched a commercial for Lipton Ice Tea (note I am a teetotaler who doesn't drink tea) and I have to admire their cleverness in coming up with names for competitor products (see the title) in their "Lipton Tea, I think I love you" commercial. (Lyrics here)

Really the names are clever although the best is the H30 -- I just love it, a chemical compound that as far as I can tell can't exist, but we all know they are making fun of flavored water. Of course I also love ordering water by requesting Di-Hydrogen-Oxide.

OK they didn't actually have Geneva Cola it was really Milan Cola, but since I really wanted to blog about Geneva and how "I think I love [it]" well I couldn't resist the name substitution.

Now before I pester you with anymore puns let me tell you why I love Geneva, Microsoft's next evolutionary leap with Federation and SSO.

Of late there has been a lot of buzz about Cloud computing. But there are obstacles, when you host applications in the cloud or use SaS type applications you wind up creating new identity stores.

With Geneva your identities will be almost ubiquitous, in that you can use it anywhere and your applications built using the Geneva framework will be able to accept and use identities from anywhere that you decide to trust.  It won't matter anymore where your applications, are in Microsoft's cloud, your cloud, or your partner's cloud.

In short if Cloud Computing will transform the industry then Geneva is the way to get there. It certainly lowers some of the barriers

Additionally, we can use Geneva to provide SSO for apps within an organization.

Now to tie in the commercial, since Geneva also supports the SAML 2.0 protocol it even inter-operates with Hot Ball of GAS SSO, and "Fiction Books Access Manager"

Best Practices ILM 2007 Coding Conventions and Habits

In response to question in the MMSUG yahoo group I thought I would post the following:

Naming conventions for MV objects and attributes.

Most CS objects and attributes come to us with names -- the exception being when we are writing our own views in SQL or Oracle

There are many object types and attributes pre-defined in the metaverse if you use those no need to rename most of them seem to come from the required and suggested  attributes for either an X.500 Directory or LDAP Directory.

For new objects it depends on how you want to process things. If you need to take some code based actions that are identical for similar but different object types then using a prefix or suffix can help. I have seen some very complex GALSync scenarios implemented that way, div-Person, div2-Person, div3-Person, div-DL, Div2-DL, Div3-DL, div-Contact, div2-Contact, div3-Contact.  Then in provisioning code you can match on patterns to make decisions.

For Attributes some like to create them with a prefix with the client name. I generally like to match my attributes to the names from LDAP.

Naming conventions for coded attribute flows (AF).

In the 2731 class the instructions have you replacing the generated name User.samAccountName -> Person.sAMAccountName with something more like SamAccountName.

The benefit of the generated names is that they are pretty much unique and human readable although they are long. These days I tend to leave the default names.

Ways to make extensions for AF more adjustable without re-coding.

I have seen one developer use the flow rule names as a language to processor module to handle 90% of his string manipulation. That certainly cut down on the need for re-coding.

That may have been an extreme example but it shows you what is possible.

Another tactic is to preprocess Attribute flow by performing the transformations in a SQL view -- it is much faster, but you can only use information available from that database. If you need to change it you won't need to change the MA Extension code. This is my preferred approach.

Ways to make provisioning code more adjustable without re-coding.

Make use of XML config files to store things like Exchange Mailbox stores to use, and then read them in during the initialize method (called once when the dll is loaded, since the dll's stay in cache for 5 min after use this won't necessarily be every run) of the Provisioning dll, and then make use of them during the provision method (called once per connected cs object being synchronized). Don't load an xml config file in the provisioning method unless you are looking for a way to slow down performance.

Favorite ways to make the status for any particular object easy to understand for people who don't know ILM/AD, etc.

We like to use reports and give the reports and their columns good descriptive names like ILM Disconnectors. Uh I mean AD Objects (Users, Groups OUs etc) that don't have matches in the other systems (like HR).

In the reports on connected objects using the binary functions in SQL to translate

For info on reports see Brad Turner's blog on the community reporting pack that he created (I helped but only on one report).

Desert Code Camp -- SQL, XPath and FIM

I just presented 3 sessions at the 2009 Desert Code Camp on Saturday June 13, 2009  at Devry University

Thanks to Devry for hosting it and thanks to Lorin Thwaits of KB Alertz for being the Code Camp Director and to all other volunteers.

Title (and link to Desert Code Camp site)	Abstract	Presentation Link	Comments
I dream in SQL (writing queries)	Learn how to write SQL queries: SELECT statements, JOIN clauses, group by with Practical examples from the realm of Identity Management	I_Dream_in_SQL	Audience: 36 The room was packed. Despite the odd hum in the background due to feedback from the projectors, things went fairly well. I had created the session, slides and examples for a group that was brand new to SQL or pretty shaky but most that showed up had plenty of experience writing queries but wanted to formalize their knowledge learn some of the terms, best practices and gain understanding of why they write queries that way. I tweaked the slides to include some of the topics I added on the fly in response to questions and the audience's deeper than novice experience. I received lots of great questions.
Query Performance Tuning	Learn how to optimize your SQL 2008 queries, learn how to use Query Plans and Statistics to measure performance -- find the weak points and then what can be done to speed your queries, learn when to avoid cursors (usually) and how to replace them.	Optimizing SQL Queries	Audience: 37 About half the class from the 1st hour followed me to this one. It was a another packed session SRO! I wish I had more time to delve in. Showed people the different ways to analyze queries and some basics about query tuning with a focus on dumping cursors. I have also revamped these slides somewhat.
XPath Queries (tastes just like SQL)	On more and more fronts XPath queries are available to us, learn how to take your existing SQL query skills and translate them to XPath. See practical examples of XPath queries against a WCF based Web service (Forefront Identity Manager).	XPath Queries (tasted just like SQL)	Audience: 17 Joe Zamora co-presented this one with me so that we could show off his FIM query tool as an example to others that write against XML SOAP WCF web services. After the crowd did agree XPATH does taste like SQL!

To PKI or not to PKI?

When should one implement a Public Key Infrastructure and when should one not? Obviously we implement a PKI to solve a problem, usually around security, enabling secure communications with a web server, multi-factor authentication, encryption. A PKI solution can be very versatile, but it comes at a price in setup and maintenance. But what alternatives do we have? Let's examine each problem in turn

 

Problem	PKI difficulties	Alternatives	Benefits for Alternatives
Enable Secure web transactions (SSL)	certs expire without warning anyone	none
Secure network communications (IPSEC)	Need to issue certificates to all client computers (can use AutoEnroll GPO)	none
Multi-factor authentication for Wireless networks using 802.1X	Need to issue certificates to all client computers or smart cards to all users	Radius -- One Time Password Tokens	With Quest Defender issuing and maintaining of OTP is very easy. Defender is much easier than standing up a PKI and issuing smart cards to everyone
Multi-factor authentication (certificates, smart cards)	Need to issue smart cards to all users (can be time consuming) Need special hardware	One Time Password Tokens	With Quest Defender issuing and maintaining of OTP is very easy. Defender is much easier than standing up a PKI and issuing smart cards to everyone. Can work even on computers without the smart card reader.
Encryption of files (EFS)	Need to issue smart cards to all users (can be time consuming)	AD Rights Management Services	Enrollment of users is transparent -- new users can be given permissions by adding them to groups without having to re-encrypt the files. No need to renew certificates. Restrictions are enforced after file is opened. It allows you to assign rights and permissions to other people to documents (open, saving, edit, print, cut and paste) and emails (forward, cut and paste)
Enabling users (internal and/or external) to use your code without getting scary warning (Signing Code Modules, Macros, ActiveX controls etc)	Need to issue/buy certificates for developers	none
Signing emails	Need to issue certificates (whether on smart cards or not) to all users	PGP (web of trust)
Encrypting emails	Need to issue certificates (whether on smart cards or not) to all users	AD Rights Management Services or PGP (web of trust)	AD RMS Enrollment of users is transparent. Restrictions are enforced after file is opened. It allows you to assign rights and permissions to other people to documents (open, saving, edit, print, cut and paste) and emails (forward, cut and paste)

In short you need certificates for SSL, IPSEC, code signing and signing emails. Whether you build your own PKI or get certificates for them is another question. For SSL and code signing you can get away with buying your certs and should if your web site and/or code is for the public (although if you have enough you may want to look at setting up a subordinate CA with a Public CA that way you control the certs but they are issued through a trusted root CA and your customer don't get those confidence inspiring messages asking them whether to trust you or not) . For IPSEC and signing emails you should implement your own PKI in order to save the cost of buying so many certs.

If you need to implement signing of emails along with multi-factor authentication then it makes sense to take advantage of the versatility of certificates on smart cards. Then it makes sense to implement the Certificate Management component (CLM) of ILM 2007 to ease many of the challenges with issuing and managing smart cards.

However, if multi-factor authentication and encryption are your main goals you may want to take a look at one time password tokens with Defender and Microsoft's AD Rights Management Services (AD RMS) respectively. Both present easier and perhaps cheaper alternatives, that also add capabilities. Defender adds the capability to use multi-factor authentication on machines without smart card readers, and AD RMS adds the capability to restrict what users can do with content even after they decrypt it.