It depends entirely on how the application talks to the LDAP Server, or more specifically finds the ldap server and what is in it and authNs. Each application will be different just like it is when trying to incorporate them into AD in the first place. You will not have a one size fits all solution with all defined as any app that could ever use AD or AD/AM.
I am thinking about mostly non-windows based apps here, so you don't have the auto resource location skills that a Windows app can have by virtue of using the Windows LDAP libs. They simply need to know a base, host name, and binding info. As long as the same attributes are available for searching and sometimes even the same basic hierarchy exists, they are usually quite fine. In fact, if you force the entire forest hierarchy into a single AD/AM, that is much better for many of those apps versus using a GC and then having to chase into other DCs for more info, easier to config. If you have multiple trees it is a little more involved to do this since you will need to add a top level DN to encompass all of the trees (say like cn=root) but if you are specifying the search base in the app, that isn't a problem. Transparency would be more of a challenge with apps using default Windows location services. For instance, Exchange, if it could put its data into ADAM would never work since you can't specify anything, it looks at the defaults of the machine it is sitting on and goes from there. This is a complete PITA to anyone managing multiple forests and means one admin managing multiple Exchange forests (say like a service provider) either needs multiple workstations (real or virtual) or needs to TS into other machines to do their admin work which is just plain silly. There really is no reason other than developer laziness there and a kind of thinking that the world revolves around you and your app. Unfortunately, if you have tried to set up the _ldap DNS entries to get the location services to locate an AD/AM as a DC you know that AD/AM doesn't respond properly to the UDP LDAP query of (&(DnsDomain=domain.com)(Host=ServerName)(NtVer=\006)) so the whole Windows location service breaks down. But then MS isn't really using the SRV record for that properly anyway, they ignore the port setting so even if ADAM did respond properly, the client would only query properly if ADAM was on 389 and one of the nice things about using SRV records is so you can jump ports... So plain and simple, Windows LDAP location services doesn't work for this. However, if the app has implemented its own SRV record lookup which I have seen on a couple of UNIX based apps now, that can work fine as they simply look for the SRV records and go from there. So if you have a UNIX app that knows how to find a resource based on SRV records it could probably find an ADAM just fine that way. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, August 10, 2005 7:34 AM To: [email protected] Subject: RE: [ActiveDir] Adding custom fields to AD Can you outline how ADAM could be made transparent to an application? I've been considering this myself but haven't delved far enough into the subject yet... :m:dsm:cci:mvp -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Wednesday, August 10, 2005 1:55 AM To: [email protected] Subject: RE: [ActiveDir] Adding custom fields to AD > I'm sure that if we tried, the TerraServer could be served by a few > optimized ADAM servers, don't you think? I realize this is tongue in cheek but no I don't think it would be good. I am not of the opinion that everything should go into an LDAP Store. LDAP isn't really designed for easily working with binary blobs which is what that is all about. SQL Server is probably still a little on the hokey side with it as well but handles it better than AD does. If the app is already doing LDAP to get basic user info then I don't see the point to jump to SQL unless there is some overriding major factor that requires it. Plus, switching to AD/AM "could be nearly" or "actually could be" transparent to apps which can't be discounted, that is HUGE in the world of app dev. Consider that MANY of the apps that are used in larger orgs are UNIX/LINUX/JAVA based and you will probably find it generally easier to access LDAP than an MS SQL Server from something other than Windows and vbscript/VB. In this case it is sharepoint, so maybe SQL Server is the best solution. Plus there is the syncronization piece and I think there are more pre-built options to sync AD with AD/AM than AD with SQL. It certainly should be more straightforward. Plus, like you with WINS, I have never been a fan of SQL Server. :o) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Wednesday, August 10, 2005 12:19 AM To: [email protected] Subject: RE: [ActiveDir] Adding custom fields to AD joe, You hit the nail on the head with what my problem is with this whole thread - we're dumping crap into AD that really doesn't belong there. Seriously, the data needs to be available to a SharePoint server and some other apps, unless I read something wrong (wouldn't be the first time today...). Let AD do the authN, let SQL serve the data to the SharePoint and the other apps. It confounds me sometimes.... AD shouldn't be the repository for this type of data, unless we're applying the "We've got a solution, as long as it's AD" mentality. I'm sure that if we tried, the TerraServer could be served by a few optimized ADAM servers, don't you think? ;op Rick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Tuesday, August 09, 2005 4:58 PM To: [email protected] Subject: RE: [ActiveDir] Adding custom fields to AD I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: [email protected] Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he wants.... What are everyone's thoughts on the topic? Thanks S List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
