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

Mon Apr 21 14:02:00 PDT 2008

Hi guys,

Thanks Natalie for explaining a bit more about what Solaris is doing, we're an AD environment here so it's good to understand it.

Erast, how do you create domain accounts for windows computers there?  Was I right with my guess about RIS?  Do you have the same problem if you use Samba instead of the CIFS server?

And finally, is this article any help to you?  Microsoft designed RIS so that end users could re-install their computers and rejoin them to the domain without needing admin rights.  Would your domain admins be amenable to trying this procedure to create your computer account?
http://technet2.microsoft.com/windowsserver/en/library/5baf6892-d284-4f8d-942a-d7f571052db91033.mspx?mfr=true

And Natalie, if that worked, would the account still work if the computer was later moved to the appropriate OU?

Ross> Date: Mon, 21 Apr 2008 10:53:39 -0700> From: Natalie.Li at Sun.COM> Subject: Re: [cifs-discuss] smbd AD join for non-root level> To: erast at gnusolaris.org> CC: cifs-discuss at opensolaris.org; myxiplx at hotmail.com> > The following CR has been filed:> > 6691539 Doesn't recognize pre-created computer account in OU other than the default Computers container> > Natalie> > ----- Original Message -----> From: Erast Benson <erast at gnusolaris.org>> Date: Monday, April 21, 2008 10:07 am> Subject: Re: [cifs-discuss] smbd AD join for non-root level> To: Natalie Li <Natalie.Li at Sun.COM>> Cc: cifs-discuss at opensolaris.org, Ross Smith <myxiplx at hotmail.com>> > > > 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. <> > > > > > > _______________________________________________> > cifs-discuss mailing list> > cifs-discuss at opensolaris.org> > http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
_________________________________________________________________
Amazing prizes every hour with Live Search Big Snap
http://www.bigsnapsearch.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.opensolaris.org/pipermail/cifs-discuss/attachments/20080421/ca9f75b3/attachment-0001.html 