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 10 of 19 last Next
  • by Christoph Ewering1,

    Christoph Ewering1 Christoph Ewering1 Mar 29, 2015 10:13 AM in response to Christoph Ewering1
    Level 1 (18 points)
    Mac OS X
    Mar 29, 2015 10:13 AM in response to Christoph Ewering1

    Hello!

     

    I played around with a test computer and as far as i can tell Yosemite does not kill around 20-25 process and let them run endlessly when a user logs out.

     

    I tried to solve this with a script that starts as launch agent, the script  "traps" SIGINT, SIGKILL and SIGHUB to do some stuff but it looks like Yosemite kills this script so fast that it is able to kill only a few processes until it self get killed.

     

    So I took the brutal way and played with Benjamin Losch script. I thought why kill secd only? What if you kill all process of a user at login?

    Well I tried it - if a user logins and a launch agent kills all processes immediately - the login takes a few seconds longer or the user sees the desktop a few seconds than it looks like it got logged out just to see the desktop again.

    I found only one problem: programs that should automatically start when the user logs in get killed and do not start.

     

    Bye,

    eweri

     

    P.S: Is there a way to get a signal when a user logs out? So it would be really ease to write a launch daemon that runs as root and could kill all process of a just logged out user after a little waiting.

     

    P.P.S: Just saw another disadvantage of the "brutal way" - the Dock lost its setup

  • by macmartin,

    macmartin macmartin Apr 9, 2015 5:28 AM in response to Christoph Ewering1
    Level 2 (499 points)
    Apr 9, 2015 5:28 AM in response to Christoph Ewering1

    You could use a logouthook script.

    I described on page 9 of this thread how this is done.

     

    But will that solve the problems with keychain loosing passwords.

    I have a logout script that kills send and secinitd but still users are losing their passwords.

     

     

    BTW:

    Did anyone check if the problem persists with OS X 10.10.3?

     

    Regards

    Martin

  • by John Lockwood,

    John Lockwood John Lockwood Apr 9, 2015 6:09 AM in response to macmartin
    Level 6 (9,349 points)
    Servers Enterprise
    Apr 9, 2015 6:09 AM in response to macmartin

    For what its worth I have succcesfully implemented the script as a logouthook (I put an additional line in to write to the console log to show it had run) but I am like you finding that at least some users still have the problem in that when they log back in Mail/Calendar/Contacts re-asks for the password. The majority of our users are still running Mavericks 10.9.5 but with a Yosemite 10.10.2 server.

  • by macmartin,

    macmartin macmartin Apr 9, 2015 8:31 AM in response to John Lockwood
    Level 2 (499 points)
    Apr 9, 2015 8:31 AM in response to John Lockwood

    In my network it happens that Mail/Contacts/Calendar ask for passwords after users have been logged in for several hours and have been using this apps all day.

    The keychain then is empty.

     

    In some cases the keys come back into the keychain when the user logs out and back in again.

    But usually I have to copy the ~/Library/keychains folder from a backup while the user is logged out.

  • by Benjamin Losch,

    Benjamin Losch Benjamin Losch Apr 13, 2015 6:14 AM in response to macmartin
    Level 1 (29 points)
    Mac OS X
    Apr 13, 2015 6:14 AM in response to macmartin

    Hi Martin,

    thanks for the addition to the kill script!

    I was waiting eagerly for a 10.10 solution and now i can't wait to test this!

     

    I have to report that this Bug stays unfixed from Apple's side in 10.10.3

     

    Greetings,

    Ben

  • by Gerard Dirks,

    Gerard Dirks Gerard Dirks Apr 14, 2015 10:06 AM in response to Benjamin Losch
    Level 1 (38 points)
    Desktops
    Apr 14, 2015 10:06 AM in response to Benjamin Losch

    Hallo

     

    Could it be localisation Problem? possible that this problem occurred more on international System like German. Please write what Langauge or Country settings you are using!

     

    Regards

    Gérard

  • by Christoph Ewering1,

    Christoph Ewering1 Christoph Ewering1 Apr 15, 2015 1:09 AM in response to Gerard Dirks
    Level 1 (18 points)
    Mac OS X
    Apr 15, 2015 1:09 AM in response to Gerard Dirks

    Hello Gérad!

     

    Good point:

     

    The systems I see with this problem are all setup with german language and the users all use german as thier language setup.

     

    If this bug depends on languages it is still a bug - function should not depend on language selection.

     

    Bye,

    eweri

  • by Benjamin Losch,

    Benjamin Losch Benjamin Losch Apr 15, 2015 4:42 AM in response to Christoph Ewering1
    Level 1 (29 points)
    Mac OS X
    Apr 15, 2015 4:42 AM in response to Christoph Ewering1

    At first i tended to neglect the possibility that localization could be a factor here.

    But if all affected systems are running germane locale?

    Mine does run in german. Hase someone a test setup for testing?

    Laufen wirklich alle betroffenen Systeme auf Deutsch? Könnt ihr das bestätigen?

     

    Thanks & greetings,

    Ben

  • by Douglas155,

    Douglas155 Douglas155 Apr 15, 2015 4:55 AM in response to Benjamin Losch
    Level 1 (9 points)
    Apr 15, 2015 4:55 AM in response to Benjamin Losch

    Hello,

     

    I am running localized English versions of both clients and server and this is definitely a real problem. So bad for so long that we are looking at other solutions.

     

    Doug

  • by Christoph Ewering1,

    Christoph Ewering1 Christoph Ewering1 Apr 15, 2015 8:35 AM in response to Benjamin Losch
    Level 1 (18 points)
    Mac OS X
    Apr 15, 2015 8:35 AM in response to Benjamin Losch

    Hello!

     

    Just got a call from my customer looks like the script that should fix this bug works 50-70% of the time, only. One User had a problem with passwords all day and the next day the problem was gone until today to have the password problem again.

     

    I am waiting for a recall of my customer if I understand what she told me, today she could not get Mail or Calendar running logging in at two different computers but she never got a problem at a computer she used to log in 90% of the time. I am still waiting for confirmation.

     

    Looks like computers that a network user used before the update to Yosemite do not run into this problem.

     

    BTW. My two bug reports were closed by Apple because they were duplicates.

  • by breakplease,

    breakplease breakplease May 6, 2015 2:06 AM in response to Christoph Ewering1
    Level 1 (0 points)
    May 6, 2015 2:06 AM in response to Christoph Ewering1

    Hello

     

    actually we are rolling out 15 iMacs and one OS X Server. Both runs with 10.10.3.

    Unfortunatly we have excatly the same issue with the keychain. Password from calendar, mail and browser wont be safe when the process is blocked.

     

    Have anybode some news with this issue?

     

    Thanks & best regards

    Juerg

  • by Christoph Ewering1,

    Christoph Ewering1 Christoph Ewering1 May 7, 2015 2:22 AM in response to breakplease
    Level 1 (18 points)
    Mac OS X
    May 7, 2015 2:22 AM in response to breakplease

    Its a shame but this bug is still not fixed. As far as I can tell its still in 10.10.4.

     

    Yosemite keeps about twenty user processes alive after logout of a user - I can not even imagine what is it good for. When I logout I expect that every process under my user-id should be stopped/killed and terminated in a reasonable time period (10 seconds max).

     

    Yesterday I had to move the next network home user to a local user because of this bug. It is ridiculous because this makes OS X Server useless - and Apple does not care at all.

     

    I think the guys who have to classify bug report had not understood how horrible this bug really is. It is a key feature of OS X Server that is broken or at least very unreliable.

     

    @Tim Cook: You know there are business customers out there how have to work with OS X?

     

    I decided if 10.10.* won't fix this bug and smb bugs I am going to (had to) move my customer to Windows servers.

     

    Bye,

    Christoph

  • by John Lockwood,

    John Lockwood John Lockwood May 7, 2015 3:03 AM in response to Christoph Ewering1
    Level 6 (9,349 points)
    Servers Enterprise
    May 7, 2015 3:03 AM in response to Christoph Ewering1

    I agree it is appalling that this is not (apparently) being fixed as an urgent matter since clearly it is a widely experienced problem. However I feel this is a client related issue rather than a server issue although I can believe Apple's 'server' software does not help matters by failing to terminate idle connections like it used to be able to do. It is the client that would be responsible for terminating local processes when a user logs out. This is why the suggested fix in this discussion of implementing a logout-hook makes sense and seems to work for some people. In my own case it at least initially did not work but things might have recently settled down. (Touch wood.)

     

    (In case it was not clear I don't think moving to e.g. a Windows server would help with this issue.)

     

    Sadly it is seeming like a case of 'I'm alright Jack' in that likely Apple's own engineers do not use true network home directory based accounts and either use mobile accounts or portable home directories (stored locally and synced) and hence do not experience this themselves.

  • by Gerard Dirks,

    Gerard Dirks Gerard Dirks May 7, 2015 3:07 AM in response to Christoph Ewering1
    Level 1 (38 points)
    Desktops
    May 7, 2015 3:07 AM in response to Christoph Ewering1

    Hello Christoph

     

    I completely agree you thread, but want to make a small correction. First I thought it was a problem of the OS X Server, it isn't!  It is a problem to the OS X Client who can't handle the logoff.

    The problem even occurred if you connect as OS X client if you are using an Small-Business Server using Active-Directory and Mounting the User Directories with SMB

     

    The only solution for this problem is if you switch the Clients to Windows (then you have maybe other problems like virus etc.) As you write Apple doesn't care about this problem. It exist since 10.9.2. The best way is that all Business Clients switch from Apple to another Platform (like Windows). Then they can struggle about iWatch, iPad, iPhone and other gadgets and lose the complete Business Segment in the Market.

     

    I am an Apple User since 1979 but now I am very frustrated the way the handle us as professional users. The argument the OS X is free and OS X Server costs only US$ 20 can't be a reason for don't fixing bugs. They even deny there a bugs and nothing is somewhere described in Knowledges Notes.

     

    Apple isn't interesting in business users anymore, at this moment they are only to cowardly to write it on their website that Apple is only interesting in producing Hardware and Software for the Consumer market and that all Business Clients should switch to other platforms!

     

    Regards

    Gérard

  • by John Agapitos,

    John Agapitos John Agapitos May 24, 2015 1:35 AM in response to Gerard Dirks
    Level 1 (29 points)
    May 24, 2015 1:35 AM in response to Gerard Dirks

    Can someone help me work out a way of having the client machine reboot after every logout.  This seems to be the only bad solution to this problem of hot desking. I've tried to do it with Profile manager but could not install the script.

     

    I would appreciate a step by step as I'm not a unix guru.

     

    Many thanks.

    JOHN AGAPITOS

first Previous Page 10 of 19 last Next