Nick Ross wrote: >Hi Natalie, > >I was able to get the second b81 instance (happened to be VM) to also >join the domain -- this time without issue. > >However, I was able to recreate the issue by switching to workgroup mode >for smbadm and attempting to re-join the domain. > >Digging a little deeper, it appears that any domain join attempt to any >DC other than our first DC fails, and since there doesn't seem to be any >way to manually specify which dc to hit first (even though only one is >listed in krb5.conf), I have to clear the cache out, which perhaps by >chance has the effect of the request being directed to our first DC. > >Specifically, when smbd tries to log on with the host account name and >system hostname to *any* DC other than the first DC, it fails to join. >Any join attempts to our first DC always succeed. > > Your observation can be explained by the following setting in your krb5.conf:
kpasswd_server = dominion.hb.acsportal.com This intermittent domain join problem (CR 6607919) happens only when the SMB server discovers a domain controller that is different than the kpasswd_server specified in the krb5.conf. It is a problem for SMB server to authenticate, create the workstation trust account, and perform the NETLOGON credential chain on one DC while the KRB5 mech attempts to change/set the password by sending the KPASSWD request to another DC. As part of the AD domain join process, the SMB server sets the machine account password by calling one of the KRB5 API that doesn't provide a way for the caller to specify a KDC to which the KPASSWD request should be sent. This problem will be fixed in build 85. >This entire problem might be tied to the fact that our first DC, >dominion, has all the FSMO roles. Since the CIFS server presents itself >as an NT 4.0 client, I'm guessing that the domain join is dependent on >the PDC Emulator role, correct? > No. See above. > This would explain why joins are only >successful to our first DC. > >In reference to Bug ID 6607919, the machine account password has never >been manually set or reset (for the b81 nodes), and I believe that the >MS default for Windows-2000 compatible machine accounts is to use the >machine name as the password. > > Yes, that's the initial machine password. The machine password will be set/changed by the domain join operation. >On another note, when trying to set the DACL security permissions on a >share (from a windows client), the only location to specify where to >search for users and groups is the local (b81) machine, not the AD >domain. Is there support for assigning domain user accounts DACL >permissions on a CIFS share from a b81 host? > > Is your Windows client in the same domain? If not, you can't see the domain users and groups. Regards, Natalie >Best Regards, >Nick Ross > > > > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Sent: Friday, February 15, 2008 3:49 PM >To: Nick Ross >Cc: [email protected] >Subject: Re: [storage-discuss] b81: CIFS Server joining domain failure >-- > >Nick, > >Since it is a multiple AD environment, I'd assume you previously >stumbled on CR 6607919. The domain join might fail intermittently in >that environment as mentioned in the CR. You don't have to manually >delete the computer account from the AD before joining the domain. If >the computer account doesn't already exist in AD, the domain join >operation will automatically create one for you. Otherwise, it will >update the attribute of the existing account. > >Natalie > > _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
