Erich Wetzel

Q: Mavericks Server Keychain not properly storing information network users.

OS 10.9.1, Server 3.0.2. Clients OS 10.9.1 bound to server Open Directory and managed with Profile Manager. 10.6.8 Mail server bound to 10.9.1 server Open Directory. Messages is running on the 10.9.1 server which hosts the users.

 

Changeip -checkhostname indicates DNS is correct for the server. Server is running on a FQDN, no .local or other DNS issues.

 

For everything below: the Keychain for any of the users does not need to be repaired.

 

Generally things are going well with one exception which is a big problem.

 

Each time a network user logs and tries to use either Mail to connect to our mail server via IMAP or Messages in they are prompted for passwords. Messages takes the password and logs in. Mail acts as though the password was incorrect and asks for it again, it does not pass the connection to the mail server. There is no trace of the attempted login on the mail server logs.

 

Functional workarounds:

 

1 - OS reinstall allows immediate login on the mail server and connections as expected. This is a little too much for day to day use.

 

2 - (From somewhere in the forums forgot who, sorry), User login, go to User's network home/Library/Keychains and move any keychains with long strings of letters and numbers as name to another folder or put in trash, immediately reboot, User login again, enter passwords in Mail, immediate connection to mail server and expected behavior from Mail.app.

 

As a network user machine in a multi user environment, the next user will have to repeat the entire procedure above, including the reboot, to get access to the contents of the mail server. The first user in the example above will have to repeat it, if they come back to the same machine and log in again.

 

This is what we are doing now. It appears that it would work on a personal machine with local users and has solved a lot of issues in the forum. It is helping but does not solve the keychain problem for network users.

 

Does anyone have any advice.

 

Thanks.

 

-Erich

OS X Server

Posted on Jan 10, 2014 6:42 PM

Close

Q: Mavericks Server Keychain not properly storing information network users.

  • All replies
  • Helpful answers

first Previous Page 18 of 19 last Next
  • by Gerard Dirks,

    Gerard Dirks Gerard Dirks Jun 22, 2016 11:39 PM in response to Christoph Ewering1
    Level 1 (38 points)
    Desktops
    Jun 22, 2016 11:39 PM in response to Christoph Ewering1

    Hello Christoph

     

    As you maybe know this is called in the German Areas as "Salami-Taktik". Their are no clean statements. You need to analyse their behaviour and then the conclusion would be the same as you write. Apple want to leave the Corporate Market, and sell only Gadgets like iPhones, iPads, iPhones and maybe a Electric Car

     

    As you see how long it take before they bring new iMacs, Macminis, MacBooks Pro. That is not the market for them. At the WWDC they rename OS X to MacOS, next year they probable rename it again to iOS and then you know which device will run with it.

     

    Very nice that Management Based US Companies doesn't learn from mistakes in the past. The only difference with 1992-1997 will be that they have now plenty money in their "petty cash"

     

    Gérard

  • by Gerard Dirks,

    Gerard Dirks Gerard Dirks Jul 18, 2016 9:55 AM in response to John Agapitos
    Level 1 (38 points)
    Desktops
    Jul 18, 2016 9:55 AM in response to John Agapitos

    Hello

     

    I am still debugging. I have 2 questions to the followers of this thread?

    1) What is default path for the NetworkUser Directories? a) /Users/ or b) e.g. /HomeFolders/ both on the root of the boot volume.

    2) Is someone using the Program "Passengers" to reset the permissions? (http://macinmind.com/?area=app&app=passenger&pg=info)

     

    Regards

    Gérard

  • by John Lockwood,

    John Lockwood John Lockwood Jul 18, 2016 10:09 AM in response to Gerard Dirks
    Level 6 (9,230 points)
    Servers Enterprise
    Jul 18, 2016 10:09 AM in response to Gerard Dirks

    The default path from a client point of view would look something like -

     

    /Network/Servers/server.domain.com/Volumes/Users/

     

    On the server itself it would be whatever folder or volume you have chosen to share so could be anything at all.

  • by Gerard Dirks,

    Gerard Dirks Gerard Dirks Jul 18, 2016 12:20 PM in response to John Lockwood
    Level 1 (38 points)
    Desktops
    Jul 18, 2016 12:20 PM in response to John Lockwood

    My question is if this users folder is the default /Users/ on the root of the boot volume of OS X or have you define an new User Sharepoint like /HomeFolders/

  • by John Lockwood,

    John Lockwood John Lockwood Jul 18, 2016 1:22 PM in response to Gerard Dirks
    Level 6 (9,230 points)
    Servers Enterprise
    Jul 18, 2016 1:22 PM in response to Gerard Dirks

    Gerard Dirks wrote:

     

    My question is if this users folder is the default /Users/ on the root of the boot volume of OS X or have you define an new User Sharepoint like /HomeFolders/

     

    And I answered that.

     

    On the Mac server a folder or volume is shared and marked as a special type of share to be used for network home directories. This then gets mounted automatically by client Macs as /Network/Servers/server.domain.com/Volumes/Users/ when a network user logins in to that client Mac. If a network user with a shortname of jsmith logs in then their home directory would be

     

    /Network/Servers/server.domain.com/Volumes/Users/jsmith

     

    The usual shortcut for a users home directory of ~/ still works if you want to use that.

     

    Note: server.domain.com will be whatever is appropriate for your server, and the /Users at the end will be the name of the folder or volume shared by that server. It does not have to be Users but that is a common choice.

  • by Gerard Dirks,

    Gerard Dirks Gerard Dirks Jul 18, 2016 1:48 PM in response to John Lockwood
    Level 1 (38 points)
    Desktops
    Jul 18, 2016 1:48 PM in response to John Lockwood

    I feel that you don't understand me!

     

    It is clear that the networkuser will be redirected to the SharedPoint definied in the Server.app. I want to know where it es physicaly on the mac

    (Macintosh HD/Users/). I would like to know if the problem also occurred if the HomeDirectories is defined as e.g. (Macintosh HD/HomeFolders/) or another Volume used for storing the HomeDirectories!

  • by John Lockwood,

    John Lockwood John Lockwood Jul 18, 2016 2:28 PM in response to Gerard Dirks
    Level 6 (9,230 points)
    Servers Enterprise
    Jul 18, 2016 2:28 PM in response to Gerard Dirks

    With network logins and network home directories the users home directory is never stored on the local client Mac. It is stored on the server. The network login accesses it by logging in to their client Mac which triggers the mounting of the network share from the server. This share is as I have repeatedly explained is mounted in /Network/Servers/server.domain.com/Volumes/Users/

     

    It is not repeat not stored on the client Mac. Nor is it copied to the client Mac.

     

    If one can describe something which is not stored on the client Mac as having a location then once again as I have already explained it is in /Network/Servers/insert-name-of-your-server/Volumes/insert-name-of-share/

     

    This is not normally visible in the Finder but can be navigated to via Terminal.app and typing -

     

    cd /Network/Servers/insert-name-of-your-server/Volumes/insert-name-of-share/

     

    Normal network shares would be in /Volumes again not a location normally visible in the Finder. However network home directory shares are special shares and get mounted in the location I keep telling you.

  • by Gerard Dirks,

    Gerard Dirks Gerard Dirks Jul 18, 2016 2:48 PM in response to John Lockwood
    Level 1 (38 points)
    Desktops
    Jul 18, 2016 2:48 PM in response to John Lockwood

    we talking on different stuff!

    Bildschirmfoto 2016-07-18 um 23.45.43.png

     

    I mean on the Mac where the Server app is running, the OS X Server. I am not talking about clients!

    Their is also an local User path! The folder "Benutzer" is the default "Users" on an OS X Server!

  • by John Lockwood,

    John Lockwood John Lockwood Jul 18, 2016 3:09 PM in response to Gerard Dirks
    Level 6 (9,230 points)
    Servers Enterprise
    Jul 18, 2016 3:09 PM in response to Gerard Dirks

    I did answer what happens on the server as well.

     

    To repeat, you can select any folder or an entire dedicated volume and tell Server.app to share it. You then edit the settings of that share in Server.app and enable the option to use it for holding network home directories. The folder or volume you share can be called anything. Some people advise not sharing the entire volume of e.g. an external drive but instead to share a folder on the external volume. I would agree this can in the longer run be a better option.

     

    As an example I have an external drive connected to my server. I have shared a folder called Users on that drive via Server.app and enabled the option to use it for network home directories.

     

    You also use Server.app to set user accounts to use that share as the location for home directories. It is possible to have two or more volumes and therefore shared folders and allocate some users to one and some to the other.

  • by Gerard Dirks,

    Gerard Dirks Gerard Dirks Jul 18, 2016 3:23 PM in response to John Lockwood
    Level 1 (38 points)
    Desktops
    Jul 18, 2016 3:23 PM in response to John Lockwood

    I know what you can do with the server.app

     

    What I am looking is the use of /Users/ and then run Disk Utility. I think the Right will be correct in a different way to /Users/ then to other like /HomeFolders/

     

    Therefor my questions. Does this keychain problem occurred the network users and stored in /Users/ or in /HomeFolders/

     

    Gérard

  • by John Lockwood,

    John Lockwood John Lockwood Jul 18, 2016 3:41 PM in response to Gerard Dirks
    Level 6 (9,230 points)
    Servers Enterprise
    Jul 18, 2016 3:41 PM in response to Gerard Dirks

    /Users (on the boot drive) is for user accounts used on the server itself i.e. the local admin account. It is not impossible but it is not a good idea to use that for network login accounts.

     

    /HomeFolders is not a standard folder it is merely an ordinary folder someone - presumably you has created. It is no better or worse than creating any other folder which you would then share via Server.app and enable for the use of network home directories.

     

    The various keychain problems discussed in this and other threads apply to any folder being shared for network home directories. The name and location is totally irrelevant. (There are actually at least five maybe six different network home directories bugs, none of them are related to the name or location of the shared folder on the server, they are merely down to the fact you are using network home directories.)

  • by EOC Admin,

    EOC Admin EOC Admin Jul 21, 2016 10:12 AM in response to John Lockwood
    Level 1 (9 points)
    Servers Enterprise
    Jul 21, 2016 10:12 AM in response to John Lockwood

    Just to weigh back in on this, I don't think this issue resides with the server or server software in these keychain issues.  My feeling is that it is solely the client OS that is causing the issues.  It has been noted that until 10.9 client was released this issue was nonexistent.  Something occurred around 10.9 client when Apple decided to change the location of the keychain information.  Things have been whacked ever since.

     

    I think what Gerard is getting at is does it make a difference what the home folders directory is called on the server, or which directory on the server is used to store the home directories.  I don't believe it does since it seems to be an issue with the way the client software is handling keychain information, an not how Server or the server is handling the home folders.

  • by John Lockwood,

    John Lockwood John Lockwood Jul 21, 2016 10:37 AM in response to EOC Admin
    Level 6 (9,230 points)
    Servers Enterprise
    Jul 21, 2016 10:37 AM in response to EOC Admin

    There are multiple problems. Most of them probably do indeed relate to the client end of things but not all of them. If it was solely a client issue then likely it would not solely apply to network home directory use.

     

    Yes the problems all start with Mavericks which is when Apple introduced iCloud Keychain syncing which required the use of the new 'local items' keychain. Prior to this Mail etc. stored their details in the standard 'Login' keychain.

     

    Note: Even if you don't use iCloud Keychain Syncing and even if your not even logged in to iCloud you are still forced to use the 'local items' keychain.

     

    1. If use logs out of a network home directory then files get left open, the home directory is still mounted, user processes are still left running. Arguably a client issue. There are some scripts in this thread detailing how to kill the processes and force the disconnection of the network home directory, this is all done in a logout-hook. (Could be considered two or three different but linked issues.)
    2. If a user hot-desks between Macs their 'local items' keychain does not follow them. This is because the 'local items' keychain is in a folder which is named after the UUID number of the Mac. If you login on a different Mac it has a different UUID and hence does not see the original 'local items' keychain. I have seen no fix for this unless one actually does chose to use iCloud Keychain Syncing which is not really suited to business use. This could also be considered a client only issue.
    3. We randomly but regularly find that all logged in users will have their 'local items' keychain corrupted practically simultaneously. This requires either logging out and then back in to create a new one, or deleting the corrupted one which is in an area mere users do not see or understand - hence the easier advice is to get them to logout and back in. You then get a fresh uncorrupted 'local items' keychain and have to re-enter the passwords. This is definitely a server issue.
  • by Gerard Dirks,

    Gerard Dirks Gerard Dirks Aug 3, 2016 7:26 PM in response to John Lockwood
    Level 1 (38 points)
    Desktops
    Aug 3, 2016 7:26 PM in response to John Lockwood

    Hello

     

    It seems that the Update 10.11.6 solve our problem with the Keychain & Apple Mail. After  some test during the last week to problem wasn't occurred anymore. Even on Mac where we haven't installed the "unload_secd" script.

     

    But now we recognised a new Bug. Spotlight can't finish its job after login the NetworkUser. We find the indexing stops working and the spotlight file wouldn't became larger as a couple of kilobytes. You can't find any keywords in your Mail. Another serious bug, making Apple Mail useless to work with!

     

    Even the Global Spotlight Search would work properly. The Spotlight Index File would not grow larger as 4.8Kb. even after hours of running!

     

    Bildschirmfoto 2016-08-04 um 04.14.14.png

     

    Let's hope Apple will fix this issue!

     

    Gérard

  • by Erich Wetzel,Solvedanswer

    Erich Wetzel Erich Wetzel Sep 8, 2016 2:18 PM in response to Erich Wetzel
    Level 2 (341 points)
    Sep 8, 2016 2:18 PM in response to Erich Wetzel

    Everyone,

     

    This discussion started 1-10-2014. It is now 9-8-2016, 1.75 years and 18 pages containing 269 replies later. We have had 38,980 views of this discussion as of this post.

     

    We started at OS X 10.9.1 and Server 3.0.2 and have have reached OS X 10.11.6 and Server 5.1.7. In both cases, we are just short of 3 full releases later.

     

    Apple seems to have finally resolved the problem. We have been logging in and out on 10.11.6 clients and our keychains are holding information as they should have been over all of this time.

     

    Thank you all for your many contributions and attempts to resolve this issue. It is finally time to close this discussion and put it behind us.

     

    -Erich

first Previous Page 18 of 19 last Next