On Wed, 2008-03-05 at 15:31 -0800, Natalie Li wrote:
> John Connett wrote:
>
> >On Wed, 2008-03-05 at 14:15 -0800, Natalie Li wrote:
> >
> >
> >>John Connett wrote:
> >>
> >>
> >>
> >>>On Fri, 2008-02-29 at 07:10 -0800, Ross wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Update: It appears it's not even that, testing the CIFS server on
> >>>>another machine, it looks like you just need a reboot after setting it
> >>>>up. So the whole process to enable CIFS on a brand new b82 box is:
> >>>>
> >>>>- Install snv_82. Configure kerberos, networking and DNC when prompted.
> >>>>- Once installed, start the CIFS server and join the domain:
> >>>> # svcadm enable -r smb/server
> >>>> # smbadm join -u domain-user domain-name
> >>>>- Reboot server
> >>>>
> >>>>And then just create zfs filesystems and set sharesmb=on as needed.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>I have been trying to join a snv 83a SPARC system to a domain, so far
> >>>without success.
> >>>
> >>>
> >>>
> >>Did you see any error messages in the syslog after you ran the smbadm
> >>join CLI? Is it a multiple domain controllers environment?
> >>
> >>
> >>
> >>> The system had a text mode initial install just
> >>>preserving the slice that holds a zpool. Networking and kerberos were
> >>>configured during the install. What is DNC?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>I'm not so sure if the domain join failure has anything to do with the
> >>installation. As long as you configure your DNS and Kerberos similar to
> >>what mentioned in the Admin Guide prior to joining your system to a
> >>domain, you should be good to go. The "How to Configure an AD Client"
> >>section of the CIFS admin guide might be helpful.
> >>
> >>http://docs.sun.com/app/docs/doc/820-2429/configureadtask?a=view
> >>
> >>Note that both 'ads_domain' and 'ads_enable' properties are obsolete as
> >>of snv_81. Thus, you don't have to set those via sharectl.
> >>
> >>
> >>
> >>>Do I need to modify the kerberos configuration post-installation?
> >>>
> >>>
> >>>
> >>Yes. See above.
> >>
> >>
> >
> >Here's what I have:
> >======================================================================
> >bash-3.2# cat /etc/krb5/krb5.conf
> >[libdefaults]
> > default_realm = uk.example.net
> >
> It should be "default_realm = UK.EXAMPLE.NET"
>
> >
> >[realms]
> > uk.example.net = {
> >
> It should be "UK.EXAMPLE.NET = {"
Fixed.
> >
> > kdc = uknt-70.uk.example.net
> > kdc = uknt-72.uk.example.net
> > admin_server = uknt-70.uk.example.net
> > kpasswd_server = uknt-70.uk.example.net
> > kpasswd_protocol = SET_CHANGE
> > }
> >
> >[domain_realm]
> > .uk..net = UK.EXAMPLE.NET
Oops! Sloppy editing. The real domain name has something else in place
of 'example' ...
> >
> >[logging]
> > default = FILE:/var/krb5/kdc.log
> > kdc = FILE:/var/krb5/kdc.log
> > kdc_rotate = {
> >
> ># How often to rotate kdc.log. Logs will get rotated no more
> ># often than the period, and less often if the KDC is not used#
> >frequently.
> >
> > period = 1d
> >
> >
> ># how many versions of kdc.log to keep around (kdc.log.0,
> >kdc.log.1, ...)
> > version = 10
> >}
> >[appdefaults]
> > kinit = {
> > renewable = true
> > forwardable= true
> > }
> >
> >
>
> Kerberos realm should be composed of all upper-case letters. However,
> this is not the root cause of your problem.
>
> >bash-3.2#
> >======================================================================
> >
> >Here's what happened on the command line:
> >
> >bash-3.2# smbadm join -u Administrator uk.example.net
> >Enter domain password:
> >Joining 'uk.example.net' ... this may take a minute ...
> >failed to join domain 'uk.example.net' (LOGON_FAILURE)
> >bash-3.2#
> >
> >I found the following in /var/adm/messages:
> >
> >Mar 5 22:48:04 tequila idmap[314]: [ID 840489 daemon.error] idmapd:
> >Couldn't open and SASL bind LDAP connections to any domain controllers;
> >discovery of some items will fail
> >Mar 5 22:48:05 tequila last message repeated 3 times
> >Mar 5 22:50:44 tequila smbd[401]: [ID 871254 daemon.error] smbd: failed
> >joining uk.example.net (LOGON_FAILURE)
> >
> >
> Please disable the packet signing on your domain controller and try
> again. There is an open bug for this issue which only happens on sparc
> system.
> {See CR 6615461).
Unfortunately, that is not within my control. However, I copied
the /etc/krb5/krb5.conf file to an x86 32-bit system running snv_83 and
'smbadm join' worked.
That certainly seems to have identified the problem.
Many thanks.
> Natalie
>
> >
> >
> >>> How
> >>>about NTP, LDAP or PAM?
> >>>
> >>>
> >>>
> >>>
> >>I'm not sure what the question here is. You can always use NTP for time
> >>synchronization. You won't be able to acquire a Kerberos TGT ticket if
> >>your time is off by 5 minutes or so.
> >>
> >>
> >
> >I wasn't sure whether the 'smbadm join' does additional configuration in
> >the background. There are several Domain Controllers and I configured
> >NTP to use the time servers on two of them. Synchronization should be
> >well within 5 minutes.
> >
> >
> >
> >>>How does it compare with Scott Lowe's "Solaris 10-AD Integration"?
> >>>
> >>>http://blog.scottlowe.org/2007/04/25/solaris-10-ad-integration-version-3/
> >>>
> >>>I'm guessing that the LDAP configuration would need to be modified to
> >>>specify the account in Active Directory that will be used to bind to
> >>>Active Directory for LDAP queries.
> >>>
> >>>
> >>>
> >>>
> >>Yes. During domain join, a security context to an LDAP service on the
> >>specified AD server is established for the user account (i.e. the
> >>username argument of the smbadm join CLI). After the system is joined
> >>to a domain, the computer account will be used to bind to AD for any
> >>subsequent LDAP requests.
> >>
> >>
> >>
> >>>Does idmap support using LDAP queries to extract UNIX attributes from
> >>>Active Directory?
> >>>
> >>>
> >>>
> >>>
> >>I'll let the Winchester folks to answer any idmap related questions.
> >>
> >>Natalie
> >>
> >>
> >>
> >>>Thanks in anticipation
> >>>--
> >>>John Connett
> >>>
> >>>_______________________________________________
> >>>storage-discuss mailing list
> >>>[email protected]
> >>>http://mail.opensolaris.org/mailman/listinfo/storage-discuss
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
>
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
