Recently a colleague of mine was dealing with a client whom he had been building an FBA site for. All was fine and dandy until it came time to deploy the FBA site to the clients production WSS v3 server. It turns out, which was completely news to me, that WSS v3 during the installation allows Active Directory Account Creation Mode to be enabled in the advanced settings. I lended a hand and as you'll see why below, I immediately regretted the decision.
Ok you say, that's nice, WSS v3 allows that setting but the bad news is that apparently ADAM and FBA do not play nice together. When WSS v3 is installed with the ADAM setting enabled, it makes the assumption that account names are in the form "domain\username". Now anyone that has dealt with FBA knows that FBA account names are in the form "membershipProvider:accountname", so you can immediately see the problem.
ADAM and FBA just won't work together as it turns out, so after some digging, a BA I work with ran across the following link (http://office.microsoft.com/download/afile.aspx?AssetID=AM102157711033). The link is to a document which details best practices for setting up WSS v3 in a Shared Hosting Solution. Page 13, section 3.1.1 details Account Creation Mode, as well as page 16, section 4.1.1 details its shortcomings. Page 23, section 5.1.1 details how ADAM and FBA just won't play nice together. The key section in the document is 4.1.1. That section states that MS recommends that you move off of ADAM at your earliest convenience, as well as stating that its a deprecated feature in WSS v3 and really shouldn't be used. The document also states that ADAM is a security risk but doesn't really state why. I also found (http://objectmix.com/sharepoint/337244-questions-regarding-ad-account-creation-mode.html), I believe it was Mike Walsh (a WSS MVP) stated that the next release of WSS will not support ADAM, that alone should prove why not to use it. One final shortcoming I was able to dig up was that MOSS 2007 doesn't support ADAM, which should be another indicator to you why not to use ADAM.
Alright, all the above being said, we needed to let the client know exactly what security issues there were with having ADAM enabled. Below is what I received back from a source at Microsoft:
- When we use Active Directory account creation mode ,We have to use command line tool for creation of sites and other admin related tasks.
- Limited user creation capability.
- Users cannot be created in different OUs.
- When we use Active Directory account creation mode, we cannot use pre-existing domain accounts; instead, new accounts are created whenever we add users.
- Creating users and cross-site groups with Active Directory account creation mode is the same as creating users with domain account mode, except that we only enter the e-mail address or group name, not a domain account, when adding the user or cross-site group to a site. Windows SharePoint Services checks Active Directory to see if an account with that e-mail address or group name already exists. If the user or cross-site group already has an account in Active Directory, the account is used. If the user or cross-site group is new, an account is created for them in Active Directory, using the Windows SharePoint Services credentials, and they are notified of their account name and password through e-mail. This is very risky.
- When we are in Active Directory account creation mode, there are certain administrative tasks that are unavailable in the HTML Administration pages. For example, we cannot create a top-level Web site, we cannot enable Self-Service Site Creation, and we cannot add a user to a site from the Central Administration pages. To perform these actions in Active Directory account creation mode, we must use the command line or the object model.
- When we create a new account with Active Directory account creation mode ,The Minimum Password Age group policy on the domain controller must be set to 0 days. Failure to do so will result in users being unable to change their passwords, unless they have administrator rights on the server.
- The ADAM authentication mechanism uses accounts defined within its own data store, Windows accounts valid on a system on which an ADAM instance instance resides, or it can redirect authentication request to Active Directory or Windows NT domains. In the latter case, the link to the Active Directory account is based on having its SID value stored in an ADAM user Proxy object. Redirection via proxy not only provides a single sign-on, but also enables storage of application-specific data for an Active Directory user outside of the Active Directory database, which is very problematic.
- No administrator friendly account management Directory Services tool (equivalent to Active Directory Users and Computers) is currently available for ADAM installations. SO administrators will have to resort to more challenging methods to populate and manage directory information.
This basically answered well enough for me the security issues revolving around using ADAM.
Below are also some good links that may come in handy for you as well if you run into the issue.
Long story short, ADAM is deprecated in WSS v3 and will not be support in the next version, ADAM and FBA don't play nice so move off of it ASAP to avoid issues for yourself in the future. If your working with MOSS, then you need not worry since ADAM isn't even an install option, so no chance of accidentally turning it on.
Originally we stumbled upon this problem when doing a site collection backup to the WSS v3. The GUI threw us an error so we tried STSADM but still no luck. The following links provied useful: