Answered by:
Adding users not in AD

Question
-
We recently took over administration of a sharepoint 2007 site and one of the sharepoint users who is not part of the AD needs to reset his password. Upon investigation of the server it appears that the user in question is in AD as a contact, and has no actual account in AD. The question i have is how do you add users to the sharepoint site that are not in AD? IF you can use contacts instead of usersas it appears how do we go about that?
Also while logged in as an SP administrator there is no option to change passwords for users in the edit user section.
please help
Wednesday, September 3, 2008 7:31 PM
Answers
-
Easiest possible alternative: You can create user accounts in the SSP (user profiles) without having an AD entry to reference. This is the simplest method to add these users.
Alternatives:
My short answer is that you can set up the membership provider to be pretty much anything you want in the webconfig's of the affected SharePoint web applications and you will be able to add those users by referencing the membership provider 'colon' associated login.
The most typical example of this is using a SQL database and Forms Authentication. There are hundreds of resources on this in google, so I won't go too deep into this stuff.
In your case the issue is that you want both AD authentication and the ability to potentially add non AD users. Maybe contacts, or related entries. If you use a CRM or other Line Of Business Applications that contain many 'potential' users it may not always be valid to have AD entries created for them.
The simplest solution in my mind is to create two AD's (since it sounds like you already have talent and knowledge in your organization for managing and using AD). The first is the corporate AD, and the second could be a 'contacts' or 'customers' AD where you can add those specific people you wouldn't want in your corporate AD. If security and management/delegation isn't a real big issue you could even just use the corporate AD with serperate OU's, policies and rules for these 'special accounts'. The end result is that you need to create the AD entries though to have it work out of the box (without any custom or extra effort).
The alternative is to basically use 'forms authentication' to reference another AD (LDAP) or another LOB system (such as SQL databases).
Hope this helps,
Richard Harbridge- Proposed as answer by Jeff DeVerter Thursday, September 4, 2008 4:18 PM
- Marked as answer by Lambert Qin [秦磊] Friday, September 5, 2008 6:12 AM
Thursday, September 4, 2008 10:42 AM
All replies
-
Is it possible that NTLM or forms authentication is being used on the site?Wednesday, September 3, 2008 9:57 PM
-
Easiest possible alternative: You can create user accounts in the SSP (user profiles) without having an AD entry to reference. This is the simplest method to add these users.
Alternatives:
My short answer is that you can set up the membership provider to be pretty much anything you want in the webconfig's of the affected SharePoint web applications and you will be able to add those users by referencing the membership provider 'colon' associated login.
The most typical example of this is using a SQL database and Forms Authentication. There are hundreds of resources on this in google, so I won't go too deep into this stuff.
In your case the issue is that you want both AD authentication and the ability to potentially add non AD users. Maybe contacts, or related entries. If you use a CRM or other Line Of Business Applications that contain many 'potential' users it may not always be valid to have AD entries created for them.
The simplest solution in my mind is to create two AD's (since it sounds like you already have talent and knowledge in your organization for managing and using AD). The first is the corporate AD, and the second could be a 'contacts' or 'customers' AD where you can add those specific people you wouldn't want in your corporate AD. If security and management/delegation isn't a real big issue you could even just use the corporate AD with serperate OU's, policies and rules for these 'special accounts'. The end result is that you need to create the AD entries though to have it work out of the box (without any custom or extra effort).
The alternative is to basically use 'forms authentication' to reference another AD (LDAP) or another LOB system (such as SQL databases).
Hope this helps,
Richard Harbridge- Proposed as answer by Jeff DeVerter Thursday, September 4, 2008 4:18 PM
- Marked as answer by Lambert Qin [秦磊] Friday, September 5, 2008 6:12 AM
Thursday, September 4, 2008 10:42 AM