[superrcat]

That information is specific to the PPD for the printer model. In v10.4, the model of the printer is finally being pushed to the clients, but the server is still pushing out a reference to a generic PPD file regardless. Trying to modify the PPDURL key within com.apple.mcxprinting for the specific printer will not do anything as of right now either; when you try to point to a custom PPD or even one that is loaded with the system, the system will still choose to configure the printer with the generic PPD. It would seem the PPDURL key is still ignored at this point.

[superrcat]

By selecting ‘Create mobile account at login’, ‘Force local home directory on startup disk’, and ‘Use UNC path from Active Directory to derive network home location’ you will provide network users with cached credentials for offline client access, a home directory stored locally on the client and their network file space mounted at login (when connected to the network).

With these options configured, you should be able to accomplish your goal, if I understand it correctly, and wouldn’t need to worry about HomeSync.

[superrcat]

[QUOTE BY= madcat] Hi,

Can you give us some direction on how you went about changing the active directory schema to allow Mac Manger to work – and to get the OS9 clients to authenitcate??

I – and I assume many other people – are having trouble finding information about OS9 / AD integeration

Thanks

Travis[/QUOTE]

You can’t extend the Active Directory schema for Macintosh Manager. The extension that is mentioned (and which is no longer required) was to enable Active Directory to function as a mock Open Directory server. Your best bet would be to follow this article for setting up Kerberos authentication between Active Directory and your OS 9 clients. Macintosh Manager 2: Using Macintosh Manager in a Kerberos Environment. I would highly recommend exploring migration plans from OS 9 as the difficulty to support and maintain a legacy deployment will continue to increase.

[superrcat]

Try going into Server Admin->Selected Server->Firewall->Settings->Logging and select ‘Enable logging’ and ‘Log all denied packets’, you can then go into the Log tab of Firewall and filter to show only Deny entries to see what ports clients are trying to connect to.

You may want to turn off logging of denied packets after you have solved your issue since the log can fill up quickly after a while.

[superrcat]

If you are trying to utilize network home directories, the share point has to allow guest access in order for automount to access it prior to the user’s login. You could alternatively use local home directories with the user’s network home mounted upon login by selecting both “Force local home directory on startup disk” and “Use UNC path from Active Directory to derive network home location”. This alternative method does not attempt to mount the share point until after the user is authenticated. It also mounts the share point with the user’s credentials.

[superrcat]

You can not use Open Directory in the place of Active Directory for Microsoft Exchange. You _could_ have an Active Directory implementation provide pass-thru authentication to your Open Directory KDC, but you would still need to create user objects in Active Directory that would map to the the Kerberos realm of Open Directory.

The University of Michigan has done a lot of work in Kerberos interoperability between Active Directory and MIT Kerberos. You can read more about it here.

[superrcat]

This is a known issue. It should be addressed in the next update.

[superrcat]

[QUOTE BY= Slappy White]
As a “malicious admin” I’d like to add that this is our #1 most annoying support call. With passwords expiring every 45 days and no built-in syncing of the LDAP and Keychain passwords, we have come to despise the Keychain and everything it stands for. This is NOT fixed in Tiger but should be a priority for Apple in the 10.4.3 update.[/QUOTE]

Well, what you are asking for, built-in synchronization between an LDAP directory and user keychains, is not fixed because it is not a bug. What you are asking for is a new feature and the only way it could appear in Mac OS X is through a feature or enhancement request.

Updating the keychain password to match a new password, in my opinion, should only occur on Mac OS X (from the client) and only when the user is changing the password by providing the old password, both occur at loginwindow and System Preferences.

[superrcat]

If it is a Mach-O application the executable permission bit has to be set in order for it to work. Classic applications (CFM applications) are not UNIX executables and ignore the executable permission bit. Both Carbon (Mach-O) and CFM applications have a ‘cfrg’ resource, but Carbon applications have a ‘carb’ resource to let Mac OS X know if the application can run natively.

So since this is a Carbon application and depending on who you want to access it, can you set the permissions on the application to 755?

[superrcat]

[QUOTE BY= macshome] OK, I haven’t seen anyone mention this yet so I will.

The keychain not syncing when the account password is changed at the directory or login window level is by design. It’s a good thing too.

Why? Let me explain.

The Keychain is an all purpose secret repository. It can contain all sorts of stuff like online banking passwords, secure notes, and other fun stuff. This is info that should be protected.

If the keychain automaticly synced when the password was changed at the login window or in the directory than a malicious admin could easily get that info. All they would need to do would be to change the password, walk over, and login.

By not syncing the Keychain anywhere but the system prefs, you reduce this attack vector greatly and it keeps your personal secrets safe. i.e. you need to know the old password to change the current one in the prefs.

Keychain Minder is great becasue it allows a streamlined solution to the user support part of the equation without reducing the security of the keychain contents.[/QUOTE]

I can see what you are saying, but updating a user’s keychain password should be allowed through loginwindow. At the point of the required password change, the user has already authenticated and confirmed who he or she is by supplying the old password.

[superrcat]

[QUOTE BY= Tim Kendall] My question is how do you turn on AD using DSCl. I found the command to add the Authentication path. Just need to turn it on in 103 and 10.4[/QUOTE]

Eh. You could use defaults as in the previous post, but it has the same limitations since DirectoryService is already running…

defaults write /Library/Preferences/DirectoryService/DirectoryService "Active Directory" 'Active'

[superrcat]

[QUOTE BY= mikemchargue] This is not fixed in Tiger. I’m running an OD master on 10.4.2 Server. My clients are 10.4.2 with network homes. When users are prompted to change their passwords at login, their Keychain passwords are not changed and support hell ensues. I have 150 users and most of the accounts were created on the same day. Every 90 days I spend a full work day helping people get their Keychain password to match their OD password.

Of course, if the users use the Change Password button in System Preferences>Accounts the Keychain password is changed. I can’t convince any of them to change their passwords before that 90 day mark though.

This is truly aggravating.

I’ll have to look into this Keychain Minder.[/QUOTE]

Although the desired effect is to have the login password and keychain password synchronized, I can see why it’s not working. Password policy enforcement occurs before a network home is mounted. If the network home is not mounted, then the keychain is not accessible. If the keychain is not accessible, then the keychain password can not be updated.

The mechanism that is handling a password reset occurs before the mechanism that is handling home directory access in the authorization database. If it is not already doing so, the password reset mechanism should be passing a hint or context data to the home directory mechanism with the previous password so the keychain can be updated (since it is now authenticating to the network home with the new password).

This is just a big assumption on the implementation though…

[superrcat]

This problem will also occur if you are using DFS or try logging into a Mac OS X client with a user that has a home directory located on a DFS share.

[superrcat]

-Enable WINS on the Tiger server.

-If not already done, go into Server Admin->Windows->Logging and set to High.

-From Windows Server 2003, configure the network connection to include Tiger as a WINS server by going to All Programs->Accessories->Communications->Network Connections. Right-click on Local Area Connection->Properties. Choose Internet Protocol (TCP/IP) under the General tab, then Properties, then Advanced. Click the WINS tab, then Add and enter the IP address of the Tiger WINS server. Select Enable NetBIOS over TCP/IP, then OK.

-Make sure SMB signing is disabled from Windows 2003 Server (either by gpedit.msc or the Registry).

After this, I would try again and then check the Samba logs from the Tiger server if there are still issues.

[superrcat]

[QUOTE BY= John G] Okay sorry for the delay. I went into dscl and into Active directory -> domain -> users, but when I am logged in on this laptop I use my mobile account, so it doesn’t appear to show up in there. Should I log in as the new network account that was created when I upgraded to Tiger (which I haven’t used at all, but I know when I log into it as the network account, it has a completely different profile, yet the two accounts seem to share a single account on the machine as far as System Preferences and Netinfo Manager show) and do the dscl after that?

Thanks guys,
John[/QUOTE]

Using the shortname of a duplicate user account, try the following:

dscl localhost -read /Search/Users/uid

Where ‘uid’ is the shortname.

Log in as the mobile account, run the command, then log in as the network account, run the command and compare the results.

[Author]

Posts