Logo 
Search:

MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

Allowing AD additions via GUI...is this an install option?

  Asked By: Raymundo    Date: Sep 29    Category: MOSS    Views: 1024

We are about to install MOSS and one of the features we're looking
forward to using is allowing site admins to add people into an AD domain
directly from MOSS. This is to enable site admins to share content with
non-employees without having to route everything through our own AD
admins.

We were told by MS that this is a built in feature, however, I'm now
reading the "Microsoft Sharepoint
Products and Technologies Administrator's Pocket Consultant from
Microsoft" and page 26 has me a bit confused:

======================================================
Active Directory Account Creation Mode
--------------------------------------------

WSS allows corresponding accounts to be created automatically in AD when

they are created in SP site collecti9ns, in addition to using accounts
created by admins. this installation mode requires site collections to
be
created from the command line interface.


What does this mean, exactly? Is this a WSS only thing or does it apply
to
MOSS? Does it mean that if we want site admins to be able to add users
to a
DMZ domain from within MOSS's site admin screens that we first need to
install MOSS using this particular mode? And, if we do, we eliminate the

ability to create site collections from within the GUI?
======================================================

What does this mean, exactly? Is this a WSS only thing or does it apply
to
MOSS? Does it mean that if we want site admins to be able to add users
to a
DMZ domain from within MOSS's site admin screens that we first need to
install MOSS using this particular mode? And, if we do, we eliminate the

ability to create site collections from within the GUI?

I asked this question in MS's newsgroups and only got one response, but
that one response has me a bit concerned:

"My understanding is that MOSS 2007 does not support Active Directory
Account Creation mode and WSS 3 does."

Is that true? And, if so, what does that mean? Isn't MOSS running on
WSS3?

Share: 

 

13 Answers Found

 
Answer #1    Answered By: Yvonne Rodriquez     Answered On: Sep 29

This installation  method is a real problem for most organizations,
except ISPs. One of the primary limitations that I can think of will be
the losing the ability to add/remove site  collections from the Central
Admin GUI. I haven't installed in this manner in the last year, but I
remember it was quite painful.

 
Answer #2    Answered By: Elisha Abbott     Answered On: Sep 29

So, what method of installation, specifically, eliminates the ability to
add/remove site  collections from the GUI?

 
Answer #3    Answered By: Naimish Ranganekar     Answered On: Sep 29

Installing in AD account  creation mode  was never meant to be used in an
enterprise (I think). Instead, it was for MOSS/WSS hosting services so that Site
Collection admins  could create  the users, not just select from an LDAP. To
accomplish this, you install, either WSS or MOSS, in AD account creation  mode.
Unless it changed at RTM, you cannot create site  collections from thr GUI when
installed in this mode. That being said, I haven't tested this method since
Beta2TR, about the same time I finished the pocket consultant.

If you do install  using this method, do let us know how it goes!

 
Answer #4    Answered By: Caleb Gordon     Answered On: Sep 29

Well, I'm not sure we WANT to at this point.
Out entire intention all along was to have our MOSS farm outside our firewall
acting as our extranet and we'd all log in via SSL. The idea was to then allow
business partners access to sites via site  admins creating AD accounts  for them.

This does throw a monkey wrench into things.

Any suggestions on a potential workaround?

I completely missed that you were the author of the Pocket Consultant.
I just want to say it's a really great book. Some of the clearest and most
detailed info I've yet read on MOSS installing.

 
Answer #5    Answered By: Christie Carlson     Answered On: Sep 29

I have one client that is using an LDAP membership provider to do Forms Based
Authentication against AD. Then they are using the ASP.NET User Registration
Wizard to create  user accounts  in AD. The wizard can be set to create the
account in a deactivated state. Then an ADMIN reviews the account  info and
activates it in AD within 24 hours. The user can use it after that to login.

 
Answer #6    Answered By: Dorothy Farmer     Answered On: Sep 29

I got hoodwinked by the same spiel by MS.

Two alternative (better even?) ways of doing this that I'm looking at are:

1. Use an extranet AAM with a different authentication provider than the
intranet AD domain. Either a separate AD domain  or even a database table of
users, either of which I DO have rights to edit.

2. A user account  management web part such as
sharepoint.advis.ch/.../Default.aspx
store.bamboosolutions.com/...rectory-web-part.aspx

 
Answer #7    Answered By: Jacklyn Burnett     Answered On: Sep 29

Most AD/Security people  strongly dislike having users create accounts  in
AD. Usually, there is a manual workflow outside of SharePoint that
ensures the account  is created  and then it is used in SharePoint. I've
not seen anyone allow users to create  accounts in AD except in hosted
environments.

 
Answer #8    Answered By: Breann Beach     Answered On: Sep 29

I'm not a networking guy, but I'll do my best to explain why we decided
to do what we do (and this was in meetings WITH Microsoft, who never
objected to the plan):

All our farm servers will be accessible via HTTPS and site  outside our
firewall. This is to enable  MOSS to act as an extranet for access from
anywhere, as well as a relatively easy way to grant access to
non-employee business partners.

Forms Authentication sounded like a great feature. However, it doesn't
appear that there is any interface/tools to actually manage forms
authentication accounts  from within MOSS out of the box. While there are
a few 3rd party options, they appear to still be in beta/rough forms.

As such, it was decided that we'd create  another AD zone for the sole
purpose of adding business partner accounts to for access to MOSS.

The catch is our AD admins  don't want to be nagged every hour for
another person to be added, so we wanted to enable AD creation  so site
admins can add  their own folks as needed.

BUT, as this thread has brought up, I'm now finding a handful of issues
with this plan:

1) While WSS3 supports AD creation mode, MOSS does not.
2) If you enable AD creation mode  in WSS3, you lose the ability to
create site collections  from the GUI

These two issues, combined, seems to make the whole plan of ours moot,
which, obviously, is insanely frustrating as MS and their gold partner
pretty much gave our plan a stamp of approval.

If we decide to rethink this and go with Forms Authentication, we need
to create another web application to expose this data in a forms
authenticated site, correct? That way we'd have an AD site for
employees, and a Forms Auth. Site for 3rd party folks...both seeing the
same databases. To do that, would we likely need to add another server,
or could we get by with both sites running on the same farm?

Alternatively, is there any way to get a WSS3 server to see the MOSS
sites? Could we have a standalone WSS3 server internal to our network
for the sole purpose of admins logging in to create AD accounts for
their users?

 
Answer #9    Answered By: Timothy Hall     Answered On: Sep 29

As I see them being used, the user account  creation/management web parts
would still only be used by people/groups with roles and organizational
rights to do so. Just like using AD delegation with the desktop AD managment
tool but done via a web interface.

You're right that the AD security people  are a tight fisted bunch ;-), but
ours at least acknowledge the need for our help desk to have enough
delegated rights to fix a phone number or help reset a password. Same deal,
but just via a web interface.

 
Answer #10    Answered By: Ian Powell     Answered On: Sep 29

Right. That's the situation here.

Our internal AD domain  will still be tightly controlled and maintained
through the current networking staff and policies and the like.

What they don't want to have to be bothered with, though, is adding
folks to our 'business partners' AD domain, as we're entrusting site
admins to decide who should/shouldn't see stuff on their MOSS sites.

At this point, from what I can tell, WSS3 support AD account  creation
from within the GUI of SharePoint, but MOSS does NOT. This obviously
messes up our rollout plans and I now need to start looking into
alternatives. It sounds like alternatives are:

- use forms authentication. To do this we'd need to:
- purchase/develop web parts to handle the GUI part of adding users
to the DB
- extend our farm to another server so that we have two separate
URLS
One for AD authentication and one for Forms authentication
- Look into the 3rd party options such as the recommended Bamboo web
part
To handle AD creation
- Other? Can we have a WSS3 server that can 'see' the MOSS sites that
we'd let
Site admins  log into for the sole purpose of adding AD accounts?
Are there 3rd party web apps outside of MOSS that give a GUI
interface
For AD domain user account management?

 
Answer #11    Answered By: Osvaldo Winters     Answered On: Sep 29

So here's an alternative solution:

1) Extend the existing AD Zone to a new Web Application. This
creates a new ZONE (either Intranet, Extranet, Internet, or Custom).
The address can be as close to the original url as http: vs. https:, but
I would recommend a different URL.

2) Use Forms based authentication using an LDAP Membership provider
pointing at a different AD domain. Since you are accessing it via LDAP
I think you can actually get away with pointing the LDAP provider at a
Domain that is different from the AD domain  for the server.

3) Copy and modify the LOGIN.aspx file in the Layouts directory  of
the 12 hive to include the standard ASP.net 2.0 userRegistrationControl.
This will allow users the ability to self-create accounts  in the LDAP AD
domain. I recommend setting the control to create  the users in a
disabled state.

4) Have an AD domain admin  for the LDAP domain activate the
accounts using the server acting as DC for the LDAP domain using the
regular Active Directory Users and computers application.

You can have an external AD administered without 3rd party tools. You
won't need webparts to administer users. You probably won't need
another server to host the alternate SharePoint URL (external) either.
You will need a server to be the DC of the external Active Directory.
You will need to do some custom coding of the Login page, but that uses
standard ASP.net server controls.

 
Answer #12    Answered By: Kylie Gill     Answered On: Sep 29

Some of that is Greek to me, but sounds like a thorough explanation.
I'll pass this around our networking group here and see what happens.
THANKS!

 
Answer #13    Answered By: Brianna Olson     Answered On: Sep 29

> 1. Use an extranet AAM with a different authentication provider than
> the
> intranet AD domain. Either a separate AD domain  or even a database
> table of
> users, either of which I DO have rights to edit.

We are planning on having a completely separate AD domain for these
external folks. As for an external database, that'd be for forms
authentication, correct?

Also, what's an AAM? (I'm not a networking guy).

> 2. A user account  management web part such as
> sharepoint.advis.ch/.../Default.aspx
> <sharepoint.advis.ch/.../Default.aspx>
> store.bamboosolutions.com/...rectory-web-part.aspx
>
<store.bamboosolutions.com/...rectory-web-part.aspx>

That looks promising! Is it designed for site  admins to use, though? It
appears to be more of a 'better/SP interface' mainly for AD admins. I'll
look at it some more.

 
Didn't find what you were looking for? Find more on Allowing AD additions via GUI...is this an install option? Or get search suggestion and latest updates.




Tagged: