Is there a best practice? For what? For making it work or for security purposes?
JoeK has a book full of coding information. That might be of use.
As for a model, my personal advice is to ensure that the coder doesn't assume that the ldap data is static. For example, never assume that the items that aren't guaranteed to be unique will remain unique such as CN. In a multi-domain forest, the CN is not likely going to be unique unless additional steps have previously been taken. DN, RDN etc follow suit.
As for more than one domain and pulling the data from domain at a time, well, that's up to the application. Is there a reason you only want it from one at a time that we should be aware of? Vs. say pulling information from a GC?
WINNT code: yes it will still work depending on how you want to run it. But it won't allow you access to the GC, and it's going to have problems in multidomain models if the samaccountname is not unique across the domain boundaries.
WINNT code is also legacy code and not guaranteed to work for future versions IIRC.
Al
On 6/12/06, Rob MOIR <[EMAIL PROTECTED]> wrote:
Just a quick question. Is anyone aware of any "best practice"
documentation of how a product ought to integrate with AD ( e.g. to pull
out user data for its own use).
Failing that, can anyone comment on what they think of a model that can
only pull data out of one domain at a time so for a >1 domain forest
needs to make a connection to each domain in turn, pull down that
information and then load it into SQL server. Am I crazy in thinking
that anyone following this model has probably just found out that their
old NT4 domain integration code "kinda works" and did the bare minimum
tidying up before halting any further work?
--
Robert Moir
Microsoft MVP for Windows Servers & Security
Senior IT Systems Engineer
Luton Sixth Form College
Right vs. Wrong | Good vs. Evil
God vs. the devil | What side you on?
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
