[LoadStar]

My experience: Downloaded Office 2008 from the Licensing website, then dragged the package from the disk image to my InstaDMG workflow. Also downloaded 12.1.0 update and added that to the workflow.

Office 2008 seemed to install perfectly. I didn’t have to do anything to modify the installer from the one I got off the Licensing website. However, while 12.1.0 update didn’t error or anything, it just didn’t seem to do anything, the resulting image contained the 12.0.0 versions of the Office apps. It did, however, apparently install the 2.1.1 version of the AutoUpdate program. I’m a bit confused at that one.

[LoadStar]

While it may not have been the original intent, I sort of like the idea of having all Apple products installed first, then the third party applications. I too have iLife and it’s associated updates in the AppleUpdates hierarchy, and it seems to work nicely for me so far. (Admittedly, I’m not sure what I’ll do when I finally get my copies of Final Cut Studio… but I digress.)

The proposed change actually muddies the water a bit – if you use a retail disc, then iLife is in one place; otherwise, if you use an OEM disc, then iLife is in another. Seems more straightforward to leave it the way it is.

Is there a technical reason (i.e. a planned enhancement or something) that requires this change?

[LoadStar]

Update – again. Seems I was partially mistaken in my last post.

Here’s the sitch as I know it:
– If I force a local home directory, I log on just fine. I do get a set of 3 entries on the domain controller/KDC’s event log, all identical:

Event Type:	Failure Audit
Event Source:	Security
Event Category:	Account Logon 
Event ID:	675
Date:		6/30/2005
Time:		7:50:52 PM
User:		NT AUTHORITY\SYSTEM
Computer:	PRIME1
Description:
Pre-authentication failed:
 	User Name:	testaccount
 	User ID:		DOMAIN_NAME\testaccount
 	Service Name:	krbtgt/DOMAIN.EDU
 	Pre-Authentication Type:	0x0
 	Failure Code:	0x19
 	Client Address:	xxx.xxx.4.5


For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Doesn’t seem to have an impact on being able to log on. I do get a Kerberos TGT without a problem.

– If I DON’T force a local home directory (i.e use the home directory from Active Directory), I get this log entry, over and over, on the Domain Controller/KDC:

Event Type:	Failure Audit
Event Source:	Security
Event Category:	Account Logon 
Event ID:	680
Date:		6/30/2005
Time:		9:05:18 PM
User:		NT AUTHORITY\SYSTEM
Computer:	PRIME2
Description:
Logon attempt by:	MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
 Logon account:	ROOT
 Source Workstation:	\\TEST-IMAC
 Error Code:	0xC0000064


For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

And the following log entry on the home directory server:

Event Type:	Failure Audit
Event Source:	Security
Event Category:	Logon/Logoff 
Event ID:	529
Date:		6/30/2005
Time:		8:29:46 PM
User:		NT AUTHORITY\SYSTEM
Computer:	HOME_DIR_SERVER
Description:
Logon Failure:
 	Reason:		Unknown user name or bad password
 	User Name:	ROOT
 	Domain:		DOMAIN_NAME
 	Logon Type:	3
 	Logon Process:	NtLmSsp 
 	Authentication Package:	MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
 	Workstation Name:	\\TEST-IMAC

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

So, clearly, when I have the “force local home directory” checkbox UNCHECKED, for some reason, it seems to be trying to log on as ROOT, not as the username I’m entering. If I have it CHECKED, it logs on just fine as the username I enter.

I’d say it’s clearly a bug, a glitch with the AD plugin for Directory Services, but I’m understanding that other people aren’t having the same problem. I dunno at this point what to do.

[LoadStar]

Success. Well, not success. Progress, at least. I now know the problem, I just don’t know the cause or the solution. But knowing is half the battle! (Some of you will get that one.)

What the problem is NOT:
– DNS. Gave the Mac a static IP address, and added it to the DNS tables. Didn’t change a thing.
– Authentication. I am authenticating without a problem. Finally sat there and watched the system log on the AD domain controller, and it is definitely authenticating just fine.
– Kerberos (at least on the server side). According to the log entry for the login success, the login method is Kerberos.
– Time differential between client and server. They’re within a few seconds of each other.
– How many folders deep the home directory is within the sharepoint. (This was a fairly out there idea… thought perhaps the Mac was having an issue with a home directory that was nested an extra folder deep within the sharepoint.) Created a home directory at the very top of the sharepoint, as I figured it would be looking for – didn’t change anything.

So what did the problem end up appearing to be? SMB on the Mac. Yeah, that’s right. Thanks, Apple. For some reason, it’s trying to connect to the home directory server as ROOT. Yeah, WTF is right.

What I did to find this out: I changed the home directory for a test user in AD to point to a box I could do some auditing on. I then attempted to log in, and started seeing failures in the Security log on my box. Here’s the description from the log entry:

Logon Failure:
 	Reason:		Unknown user name or bad password
 	User Name:	ROOT
 	Domain:		DOMAIN_NAME
 	Logon Type:	3
 	Logon Process:	NtLmSsp 
 	Authentication Package:	MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
 	Workstation Name:	\\TEST-IMAC

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

(I redacted the “domain” in the log entry above. You don’t need to know that, suffice to say that it was indeed the correct domain name.)

Now. What is the source of the problem, and how do I fix this? Anyone have any brilliant ideas?

[LoadStar]

[QUOTE BY= MacTroll] Check out our article on troubleshooting home directories. It’ll show you how to run automountd in debug mode, which might help some here.[/QUOTE]

Good thought. Here’s the problems I have following the instructions in that article:
[QUOTE]1. Check the record in the directory service.[/QUOTE]
I can’t check the record from Directory Service as long as I have the “force local home directory” checkbox unchecked. As soon as I read a record with dscl, automount flips out.

[quote]2. Check and make sure that the client is getting the mount record.[/quote]
When the “force local home directory” checkbox is unchecked, the only user I can log in as is the local administrator account, and doing lookupd -d and allMounts as the local administrator account is non-revealing.

[quote]3. Run the automount process by hand.[/quote]
Again, as long as the “force local homde directory” checkbox is checked, I can’t login as a network user, and logging in as a local account I’m obviously not going to get any mount records from directory service. So, trying to follow the instructions in this step won’t work, as they presume you’re logged in as the account from directory service. (Additionally, I can only presume that the location automounts are in has changed under 10.4 – “/private/var/automount/Network/Servers” doesn’t exist, but “/private/Network/Servers” does.)

[quote]4. Turn on guest access.[/quote]
Tried opening the security on the sharepoint on the server where the home directory is stored – it’s open Everyone – Full Access. Didn’t change anything. Automount still flipped out. (Also tried setting permissions on the entire directory tr

[quote]5. Group folders.[/quote]
Not applicable.

[quote]6. 10.3.5.[/quote]
Not applicable.

I’m not deliberately being obtuse – if I am, it’s purely accidental! I just don’t see that article as being of much help. Is there any way to set the automount daemon to run in debug mode when it’s called by the kernel?

[Author]

Posts