| Author | Messages | |
Thomas Vuylsteke
Posts:207
 | | 05/30/2010 8:19 PM |
| I've been playing around a bit in .NET to get a rules extension for a FIM MA.
In the extension I do a LDAP search against Active Directory to find out whether a given AccountName is already in use. Now I was wondering if anyone knows whether the following lines of code are "AD sites&services" - aware. Meaning it will locate a DC to use in the same site as the code is being ran from.
Dim objDeSearchRoot As New DirectoryEntry()
è Should take the domain of the server where the code is being ran
è How will it locate a DC? Will it bluntly use the current logon server? What if that one is unavailable, will it use search another one?
Dim objDeSearchRoot As New DirectoryEntry("LDAP://contoso.com")
è Same question as above, how will it locate a DC? Will it use DNS to lookup an IP for "contoso.com" and hence use some round roubin and 0 site-awareness
Dim objDeSearchRoot As New DirectoryEntry("LDAP://DC01.contoso.com")
è Well can't see how this makes sense, DC down is no more lookups
The following MSDN site explains the different options for binding, but not really how the DC location process works.
http://msdn.microsoft.com/en-us/library/ms815618
P.S. either way I'm not hardcoding strings in the DLL, I'm using a XML besides it.
| | | |
| bdesmond
Posts:977
| | 05/30/2010 8:25 PM |
| Yeah all that uses ADSI which will ultimately invoke DC Locator. You want the second option with "LDAP://DC=constoso,DC=com". The syntax for the third option is "LDAP://dc01.contoso.com/dc=contoso,dc=com". I don't know if Option 1 is even a permitted constructor.
As a side note my understanding is that it's not really best practice to make calls out from provisioning code/rules extensions like this. I've been advised in the past to import all samaccountname values in AD into a custom object type/attribute and then search the MV.
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Thomas Vuylsteke
Sent: Sunday, May 30, 2010 2:18 PM
To: activedir@mail.activedir.org
Subject: [ActiveDir] System.DirectoryServices namespace in .NET: site awareness
I've been playing around a bit in .NET to get a rules extension for a FIM MA.
In the extension I do a LDAP search against Active Directory to find out whether a given AccountName is already in use. Now I was wondering if anyone knows whether the following lines of code are "AD sites&services" - aware. Meaning it will locate a DC to use in the same site as the code is being ran from.
Dim objDeSearchRoot As New DirectoryEntry()
è Should take the domain of the server where the code is being ran
è How will it locate a DC? Will it bluntly use the current logon server? What if that one is unavailable, will it use search another one?
Dim objDeSearchRoot As New DirectoryEntry("LDAP://contoso.com")
è Same question as above, how will it locate a DC? Will it use DNS to lookup an IP for "contoso.com" and hence use some round roubin and 0 site-awareness
Dim objDeSearchRoot As New DirectoryEntry("LDAP://DC01.contoso.com")
è Well can't see how this makes sense, DC down is no more lookups
The following MSDN site explains the different options for binding, but not really how the DC location process works.
http://msdn.microsoft.com/en-us/library/ms815618
P.S. either way I'm not hardcoding strings in the DLL, I'm using a XML besides it.
| | | |
| ZJORZ
Posts:363
| | 05/31/2010 6:47 PM |
| >>> As a side note my understanding is that its not really best practice to
make calls out from provisioning code/rules extensions like this. Ive been
advised in the past to import all samaccountname values in AD into >>>>a
custom object type/attribute and then search the MV.
Correct. You should avoid connecting to external (from the Sync Engines
perspective) data sources when possible.
GOAL: You need to generate a sAMAccountName and check uniqueness and make
sure it is available right away to check uniqueness against. The latter case
is important when you provision more than one person for which the
sAMAccountName will end up the same (people with the same name)
When taking about uniqueness in terms of AD I think like (making some
assumptions): 1x MA = 1x AD forest. Although sAMAccountName only needs to be
unique within an AD domain, I want it to be unique within the AD forest.
Same applies to userPrincipalName, CN (RDN) and mailnickName. I want all to
be unique within the AD forest. Makes life a lot easier
Two possible scenarios:
1. The complete AD forest is in scope of being managed by the Sync
Engine
2. Only part of the AD forest is in scope of being managed by the Sync
Engine
Ώ] Just use the default PERSON object as all sAMAccountNames in AD are in
the Sync Engine
ΐ] Use the PERSON object for the objects you manage and create a custom
object (e.g. ADuserObject) representing all the users in AD that only hold
certain attributes for which you need to check uniqueness against
Whatever the case, you could go for solution ΐ] even in the scenario as
mentioned in Ώ], so that why Im only going to explain option ΐ]
· Create a custom object in the Sync Engine called e.g. ADuserObject.
Put just the attributes on that object for which you need to check
uniqueness for AND also add DisplayName so that it is easier to identify an
object in the Sync Engine
· Create an AD MA called e.g. ADForest1UniquenessCheck and configure
accordingly (Inbound Attribute Flows only, Join and Projection criteria,
etc)
· Create an AD MA called e.g. ADForest1 and configure accordingly
(Inbound and Outbound Attribute Flows, Join and Projection criteria, etc)
Now WHEN to generate a unique name for a certain attribute?
I prefer to do that during the Inbound Attribute Flow after projection to
the MV in the MA that connects to the authoritative data source (thus NOT
during provisioning or outbound attribute flow in the AD MA). In that case
you can use the following à Utils.FindMVEntries(<attribute to check
against>, <attributevalue to check>, 1)
So, if the PERSON object and the ADuserObject have an attribute called
sAMAccountName, the function Utils.FindMVEntries(sAMAccountName, JORGE,
1) will search ALL objects to see if any has a value JORGE in the attribute
SAMACCOUNTNAME.
If no value is found, then the proposed value (JORGE) is unique and it
should be flowed to the MV during the Inbound Attribute Flow. If the next
object also proposes a value JORGE for the attribute SAMACCOUNTNAME, it will
find a PERSON object with such a value and the recalculation should kick in
and propose a new value (e.g. JORGE1). After the value is flowed to AD, it
will be imported by the Sync Engine into the ADuserObject objectType
Met vriendelijke groeten / Kind regards,
Jorge de Almeida Pinto
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Brian Desmond
Sent: Sunday, May 30, 2010 21:23
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] System.DirectoryServices namespace in .NET: site
awareness
Yeah all that uses ADSI which will ultimately invoke DC Locator. You want
the second option with LDAP://DC=constoso,DC=com. The syntax for the third
option is LDAP://dc01.contoso.com/dc=contoso,dc=com. I dont know if
Option 1 is even a permitted constructor.
As a side note my understanding is that its not really best practice to
make calls out from provisioning code/rules extensions like this. Ive been
advised in the past to import all samaccountname values in AD into a custom
object type/attribute and then search the MV.
Thanks,
Brian Desmond
brian@briandesmond.com
c 312.731.3132
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Thomas Vuylsteke
Sent: Sunday, May 30, 2010 2:18 PM
To: activedir@mail.activedir.org
Subject: [ActiveDir] System.DirectoryServices namespace in .NET: site
awareness
Ive been playing around a bit in .NET to get a rules extension for a FIM
MA.
In the extension I do a LDAP search against Active Directory to find out
whether a given AccountName is already in use. Now I was wondering if anyone
knows whether the following lines of code are AD sites&services aware.
Meaning it will locate a DC to use in the same site as the code is being ran
from.
Dim objDeSearchRoot As New DirectoryEntry()
è Should take the domain of the server where the code is being ran
è How will it locate a DC? Will it bluntly use the current logon server?
What if that one is unavailable, will it use search another one?
Dim objDeSearchRoot As New DirectoryEntry(LDAP://contoso.com)
è Same question as above, how will it locate a DC? Will it use DNS to lookup
an IP for contoso.com and hence use some round roubin and 0 site-awareness
Dim objDeSearchRoot As New DirectoryEntry(LDAP://DC01.contoso.com)
è Well cant see how this makes sense, DC down is no more lookups
The following MSDN site explains the different options for binding, but not
really how the DC location process works.
http://msdn.microsoft.com/en-us/library/ms815618
P.S. either way Im not hardcoding strings in the DLL, Im using a XML
besides it.
| | | |
| ZJORZ
Posts:363
| | 05/31/2010 9:15 PM |
| I myself can also create a Rules Extension for the Sync Engine, but Im not
able to create a WF activity. For the latter you need to understand Windows
Workflow Foundation and because of that I would ask a colleague with lots
more coding experience to do the WF activity coding.
Where to do stuff
.
ILM is about doing stuff in the Sync Engine
FIM should be about doing stuff in the FIM portal and ONLY go to the Sync
Engine for the stuff that can only be done in the Sync Engine
Met vriendelijke groeten / Kind regards,
Jorge de Almeida Pinto
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Thomas Vuylsteke
Sent: Monday, May 31, 2010 21:54
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] System.DirectoryServices namespace in .NET: site
awareness
Sensitivity: Confidential
I spent half a day trying to start a custom workflow activity based on the
ensynch guide for the RC0 edition of FIM. I didnt got that far. Not that
I expect to be a workflow activity specialist over a day, but I simply have
no clue where to start. And how to connect the dots.
I know Henrik Nillson also has a unique-accountname workflow, but that one
is also RC0 and is not compatible with FIM RTM.
If you have any additional resources on this subject, not necessarily with
the unique name as example, I would be glad to try them. Im not afraid to
code, not at all, but I really would like to get some dummy-proof resources
J
An additional question: what is the benefit of the Workflow Activity over
the Rules Extension? The Rules Extension is pretty simple and
straightforward. The advantage for Activity Workflow I see is that you can
do a lot with the MPRs.
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Jorge de Almeida
Pinto
Sent: maandag 31 mei 2010 19:47
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] System.DirectoryServices namespace in .NET: site
awareness
Sensitivity: Confidential
If you are using FIM, why are you working with Rules Extensions? Why not
have a Workflow Activity do this?
Met vriendelijke groeten / Kind regards,
Jorge de Almeida Pinto
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Thomas Vuylsteke
Sent: Sunday, May 30, 2010 21:39
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] System.DirectoryServices namespace in .NET: site
awareness
Sensitivity: Confidential
I have followed a 4-day course of FIM and I have been playing around with
it, so my experience is rather limited.
What I want to accomplish is an attribute flow which generates a unique
account name based on the first and last name which comes from an HR source.
Currently Im using the sub MapAttributesForImport which I extended to query
AD and do its magic.
I can see how querying the MV is advised,but at first (and currently) I had
no clue how to search it. So I will take a look into that. Thanks for the
advise.
Regards,
Thomas
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Brian Desmond
Sent: zondag 30 mei 2010 21:23
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] System.DirectoryServices namespace in .NET: site
awareness
Sensitivity: Confidential
Yeah all that uses ADSI which will ultimately invoke DC Locator. You want
the second option with LDAP://DC=constoso,DC=com. The syntax for the third
option is LDAP://dc01.contoso.com/dc=contoso,dc=com. I dont know if
Option 1 is even a permitted constructor.
As a side note my understanding is that its not really best practice to
make calls out from provisioning code/rules extensions like this. Ive been
advised in the past to import all samaccountname values in AD into a custom
object type/attribute and then search the MV.
Thanks,
Brian Desmond
brian@briandesmond.com
c 312.731.3132
From: activedir-owner@mail.activedir.org
[mailto:activedir-owner@mail.activedir.org] On Behalf Of Thomas Vuylsteke
Sent: Sunday, May 30, 2010 2:18 PM
To: activedir@mail.activedir.org
Subject: [ActiveDir] System.DirectoryServices namespace in .NET: site
awareness
Ive been playing around a bit in .NET to get a rules extension for a FIM
MA.
In the extension I do a LDAP search against Active Directory to find out
whether a given AccountName is already in use. Now I was wondering if anyone
knows whether the following lines of code are AD sites&services aware.
Meaning it will locate a DC to use in the same site as the code is being ran
from.
Dim objDeSearchRoot As New DirectoryEntry()
è Should take the domain of the server where the code is being ran
è How will it locate a DC? Will it bluntly use the current logon server?
What if that one is unavailable, will it use search another one?
Dim objDeSearchRoot As New DirectoryEntry(LDAP://contoso.com)
è Same question as above, how will it locate a DC? Will it use DNS to lookup
an IP for contoso.com and hence use some round roubin and 0 site-awareness
Dim objDeSearchRoot As New DirectoryEntry(LDAP://DC01.contoso.com)
è Well cant see how this makes sense, DC down is no more lookups
The following MSDN site explains the different options for binding, but not
really how the DC location process works.
http://msdn.microsoft.com/en-us/library/ms815618
P.S. either way Im not hardcoding strings in the DLL, Im using a XML
besides it.
| | | |
| ZJORZ
Posts:363
| | 06/01/2010 5:57 AM |
| Complex joins, projections and for example datetime conversions can only be
done in Rules Extensions. Sure, do it that way, no problem. But, if it can
be done in the FIM portal, why not?
Sure, someone can be have more experience and still choose to do stuff in
the Sync Engine. In that case nothing will ever change if you do not change
your way of working. Having configurations in multiple places is something I
try to avoid.
My thought: do everything in the portal and only go to the sync engine when
it is not possible in the portal
Met vriendelijke groeten / Kind regards,
Jorge de Almeida Pinto
-----Original Message-----
From: Tomasz Onyszko [mailto:t.onyszko@w2k.pl]
Sent: Tuesday, June 01, 2010 00:48
To: activedir@mail.activedir.org
Cc: Jorge de Almeida Pinto
Subject: Re: [ActiveDir] System.DirectoryServices namespace in .NET: site
awareness
On 5/31/2010 10:13 PM, Jorge de Almeida Pinto wrote:
> I myself can also create a Rules Extension for the Sync Engine, but
> I'm not able to create a WF activity. For the latter you need to
> understand Windows Workflow Foundation and because of that I would ask
> a colleague with lots more coding experience to do the WF activity coding.
>
> Where to do stuff..
>
> ILM is about doing stuff in the Sync Engine
>
> FIM should be about doing stuff in the FIM portal and ONLY go to the
> Sync Engine for the stuff that can only be done in the Sync Engine
Well ... that is a bit philosophical debate - of course using WFF has some
advantages and you can create much more sophisticated rules using activities
at portal level. However some things are still best to handle with standard
attributes flows. And if FIM would allow to write custom functions for
attribute flow in declarative (well, codeless) provisioning? This would
allow to eliminate much of that needs. But it is not so we are still going
to use flow rules extension in more complicated cases. Or move everything
to workflow logic and just push values directly through synch engine to data
sources.
--
Tomasz Onyszko
http://www.w2k.pl/ - (PL)
http://blogs.dirteam.com/blogs/tomek/ - (EN)
| | | |
| barkills
Posts:200
| | 06/01/2010 6:33 PM |
| Granted that this isn't the best approach for FIM/ILM, but if you did want to do something like this in .net, then you'd leverage System.DirectoryServices.ActiveDirectory.
Specifically, you'd use the System.DirectoryServices.ActiveDirectory.ActiveDirectorySite.Servers property to get a System.DirectoryServices.ActiveDirectory.ReadOnlyDirectoryServerCollection object with a list of all the DCs in that site. System.DirectoryServices.ActiveDirectory.ReadOnlyDirectoryServerCollection is an enumerable collection, so easy to work with.
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Thomas Vuylsteke
Sent: Sunday, May 30, 2010 12:18 PM
To: activedir@mail.activedir.org
Subject: [ActiveDir] System.DirectoryServices namespace in .NET: site awareness
I've been playing around a bit in .NET to get a rules extension for a FIM MA.
In the extension I do a LDAP search against Active Directory to find out whether a given AccountName is already in use. Now I was wondering if anyone knows whether the following lines of code are "AD sites&services" - aware. Meaning it will locate a DC to use in the same site as the code is being ran from.
Dim objDeSearchRoot As New DirectoryEntry()
è Should take the domain of the server where the code is being ran
è How will it locate a DC? Will it bluntly use the current logon server? What if that one is unavailable, will it use search another one?
Dim objDeSearchRoot As New DirectoryEntry("LDAP://contoso.com")
è Same question as above, how will it locate a DC? Will it use DNS to lookup an IP for "contoso.com" and hence use some round roubin and 0 site-awareness
Dim objDeSearchRoot As New DirectoryEntry("LDAP://DC01.contoso.com")
è Well can't see how this makes sense, DC down is no more lookups
The following MSDN site explains the different options for binding, but not really how the DC location process works.
http://msdn.microsoft.com/en-us/library/ms815618
P.S. either way I'm not hardcoding strings in the DLL, I'm using a XML besides it.
| | | |
|
|