[cifs-discuss] smbd AD join for non-root level

Mon Apr 21 10:06:09 PDT 2008

Natalie,

yes, unfortunately, there are bureaucratic environments out there, and
we really can not get permissions for Computer's container
administering. So, in summary, OpenSolaris smbd is trying to find and
create this object:

cn=XXX-NAS1,cn=Computers,dc=adsroot,dc=itcs,dc=umich,dc=edu 

...but it isn't allowed to. Instead it should use pre-defined OUs.

On Mon, 2008-04-21 at 09:23 -0700, Natalie Li wrote:
> Ross Smith wrote:
> > As will pre-creating the computer account.  I don't think this is an 
> > issue with how Solaris is implementing this, it sounds like the 
> > expected behavour on the domain personally.
> I guess it'd work with a Windows system, but not with Solaris (at least 
> for now).  The AD join needs to be fixed such that it searches the 
> entire directory, not just the Computers container, for the specified 
> computer account.  If the computer account was pre-created in 
> appropriate OU, that account should be used. If the computer account 
> could not be found in target domain, it will be created in the Computers 
> container.
> 
> >  
> > Natalie, when I mentioned RIS, it's not something that's built into 
> > windows as such.  RIS = Remote Installation Services.  It's something 
> > you can set up on a server (Windows 2000 or later) that provides 
> > remote network booting, and the ability to install windows from a 
> > central source.  One of the RIS menu pages creates the computer 
> > account for you before it begins the installation.
> >  
> Thanks for the clarification, Ross!
> > As far as I'm aware there's no method in windows to specify the 
> > location of the computer account when you join the domain, so Solaris 
> > appears to match windows in that respect.
> >  
> Since you brought up the scenario where administrators to be delegated 
> permissions only small part of the tree, I thought allowing the location 
> of the system's AD computer to be configurable would be helpful because 
> the domain join operation will automatically create the computer account 
> at the specified OU during domain join.  Pre-creating computer account 
> might be common but not always be the best practice.  Assuming an 
> bureaucratic environment in which there are a few hundred sites, a few 
> hundred thousand computer objects, and a few dozen on-site technical 
> personnel spread across the country.  You probably don't want a ticket 
> (for pre-creating the computer account) opened up everytime someone 
> needs to join a computer to the domain.
> 
> > Erast, could you try creating a computer account in advance and see 
> > whether it works?  I suspect that provided you have the computer name 
> > right you will be able to join to the domain fine.
> If the computer account were to be pre-created in the Computers 
> container, it would work.  Unfortunately, it doesn't work for Erast's case.
> 
> Regards,
> 
> Natalie
> 
> >
> >
> > > Date: Fri, 18 Apr 2008 13:20:28 -0700
> > > From: Natalie.Li at Sun.COM
> > > Subject: Re: [cifs-discuss] smbd AD join for non-root level
> > > To: erast at gnusolaris.org
> > > CC: myxiplx at hotmail.com; cifs-discuss at opensolaris.org
> > >
> > > With the current implementation, smbadm will always add/modify the
> > > system's computer object. Behaviour is undefined if you attempt to
> > > remove the code that modifies the attributes of a pre-existed account.
> > > Until we allow alternative locations to store a system's AD computer
> > > object, you should be in touch with your domain administrator.
> > > Modifying the ACL's of the Computer container to grant sufficient
> > > permission to the user account you used for joining the domain will
> > > resolve your issue.
> > >
> > > Natalie
> > >
> > > Erast Benson wrote:
> > >
> > > >Thank you for explanations, Natalie!
> > > >
> > > >Is it possible to pre-create / pre-modify objects in Computers, so
> > > >smbadm will not need to touch it and later bail with
> > > >INSUFF_ACCESS_RIGHTS ?
> > > >
> > > >On Fri, 2008-04-18 at 12:49 -0700, Natalie Li wrote:
> > > >
> > > >
> > > >>The current implementation of the smbadm join CLI is based on the
> > > >>default behaviour of Windows. Thus, the system's AD computer 
> > object is
> > > >>automatically created in the built-in Computers container during 
> > domain
> > > >>join if it doesn't already exist. Otherwise, various attributes of 
> > the
> > > >>pre-existed computer object will be updated during domain join.
> > > >>
> > > >>I wasn't aware of the RIS component being introduced by Microsoft 
> > until
> > > >>now. We certainly can make the location of the system's AD computer
> > > >>object configurable if there's such a need. With that, any non-admin
> > > >>user can also join the system to a domain as long as he/she has
> > > >>sufficient access to the container in which the system's AD computer
> > > >>object will be created.
> > > >>
> > > >>The reason as to why I suggested only domain users with 
> > administrative
> > > >>privileges can be used when joining the domain via smbadm join CLI is
> > > >>because the current implementation attempts to create/modify 
> > objects in
> > > >>the Computers container, which by default doesn't grant regular users
> > > >>the right to perform write permission.
> > > >>
> > > >>Regards,
> > > >>
> > > >>Natalie
> > > >>
> > > >>Ross wrote:
> > > >>
> > > >>
> > > >>
> > > >>>Natalie, on larger domains it's quite common for administrators 
> > to be delegated permissions only on a small part of the tree. For 
> > example, on a university you could easily have a structure like:
> > > >>>
> > > >>>University
> > > >>>- Maths
> > > >>>- Physics
> > > >>>
> > > >>>With OU's inside Maths & Physics for their respective computer 
> > accounts. The administrators for those departments would expect to be 
> > able to create accounts for themselves, but they would not have 
> > permissions to access the root computer tree.
> > > >>>
> > > >>>You're right in that when joining a domain, I don't think windows 
> > can specify where to create the account. I *think* that the 
> > recommended approach is to create the account in advance in the 
> > relevant location beforehand. That's purely theoretical knowledge I'm 
> > afraid, it's not something I've ever had to use for myself.
> > > >>>
> > > >>>There is however a way windows accounts can be created in 
> > alternative locations from the client, and I suspect Erast may have 
> > been using this since it's popular in the larger organisations: If you 
> > use RIS to install windows from a central location, during the setup 
> > you are prompted for a computer name and location and it's completely 
> > valid to enter names such as domain.com/servers.
> > > >>>--
> > > >>>This messages posted from opensolaris.org
> > > >>>_______________________________________________
> > > >>>cifs-discuss mailing list
> > > >>>cifs-discuss at opensolaris.org
> > > >>>http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>_______________________________________________
> > > >>cifs-discuss mailing list
> > > >>cifs-discuss at opensolaris.org
> > > >>http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > >
> >
> >
> > ------------------------------------------------------------------------
> > News, Sports, Entertainment and Weather on your mobile. Text MSN to 
> > 63463 Now. <http://mobile.uk.msn.com/pc/msn_content.aspx>
> 