AFP548 Changing the world one server at a time.

tegtmeye

Forum Replies Created

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • tegtmeye
    Participant

    MacTroll wrote:

    Let me see if I can replicate that…

    Any luck? Is this a configuration problem that I am not aware of or is it truly a bug ?

    Mike

    tegtmeye
    Participant

    MacTroll wrote:

    So when you say it doesn’t work from the Linux box when you get the ticket there first… does that mean that SSH doesn’t auth? Or you get in via kerb ssh but don’t get your home?

    Sorry, messages crossed.

    No matter where I got the initial ticket (via kinit), I can log in but I do not retain the ticket. ie (prior to my previous post)

    kinit on machine A (Linux)
    login to machine B (Mac) ticket accepted, no password
    klist on machine B says I have no tickets

    tegtmeye
    Participant

    OK I’ve managed to make some headway, but not much.

    I’m still not convinced that the kerberos ccache is not an in memory one. There are plenty of hits on google for “in memory cache kerberos mac” but admittedly none authoritative.

    In any case, some testing leads me to the following: I can get tickets to forward one hop and one hop only and I’m suspicious that the underlying problem is still the credential cache on the receiving machine.

    Stock setup with network user gives me:

    clutch:~ arl_admin$ ssh tegtmeye@clutch
    Password:
    Last login: Wed Oct  1 16:03:48 2008 from foo.com
    clutch:~ tegtmeye$ klist
    klist: No Kerberos 5 tickets in credentials cache
    clutch:~ tegtmeye$

    Attempting to log into another machine in the same realm asks me for my password. Reading http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/39809/1/06-1646%20.pdf and knowing that logging into ssh requires the system.login.tty right, I try adding builtin:krb5login,privileged to system.login.tty (stock apple sshd_conf)

                    <key>system.login.tty</key>
                    <dict>
                            <key>class</key>
                            <string>evaluate-mechanisms</string>
                            <key>mechanisms</key>
                            <array>
                                    <string>push_hints_to_context</string>
                                    <string>authinternal</string>
                                    <string>builtin:krb5login,privileged</string>
                            </array>
                            <key>tries</key>
                            <integer>1</integer>
                    </dict>

    Which properly forwards my tickets (at least once)

    clutch:~ arl_admin$ ssh tegtmeye@clutch
    Password:
    Last login: Wed Oct  1 16:11:50 2008 from foo.com
    clutch:~ tegtmeye$ klist
    Kerberos 5 ticket cache: 'API:Initial default ccache'
    Default principal: tegtmeye@FOO.COM
    
    Valid Starting     Expires            Service Principal
    10/01/08 15:46:56  10/02/08 01:46:56  krbtgt/FOO.COM@FOO.COM
    	renew until 10/08/08 15:46:56
    10/01/08 15:47:12  10/02/08 01:46:56  host/FOO.COM@FOO.COM
    	renew until 10/08/08 15:46:56

    I’m in! However, I notice in secure.log the error message:

    Oct  1 16:22:21 clutch authorizationhost[9758]:
      k5_store_ticket_in_cache(): got -1765328188 (Internal credentials cache error)
        on plugins/krb5/krb5_operations.c:83

    Trying to go somewhere else via sso (GSSAPI enabled), doesn’t help but at least I didn’t have to put in my password! It appears that ssh via sso doesn’t require system.login.tty right. I’m not sure what is right it does require though and how ultimately the new user is getting set.

    clutch:~ arl_admin$ ssh tegtmeye@clutch
    Password:
    Last login: Wed Oct  1 16:35:26 2008 from foo.com
    clutch:~ tegtmeye$ klist
    Kerberos 5 ticket cache: 'API:Initial default ccache'
    Default principal: tegtmeye@FOO.COM
    
    Valid Starting     Expires            Service Principal
    10/01/08 15:46:56  10/02/08 01:46:56  krbtgt/FOO.COM@FOO.COM
    	renew until 10/08/08 15:46:56
    10/01/08 15:47:12  10/02/08 01:46:56  host/foo.com@FOO.COM
    	renew until 10/08/08 15:46:56
    
    clutch:~ tegtmeye$ ssh pawl
    Password:
    Last login: Wed Oct  1 16:36:29 2008 from foo.com
    pawl:~ tegtmeye$ klist
    klist: No Kerberos 5 tickets in credentials cache
    pawl:~ tegtmeye$ 

    Notice secure.log in the second hop machine (/etc/authorization configured the same, all GSSAPI options enabled in sshd_config):

    Oct  1 16:26:55 pawl sshd[2098]: Authorized to tegtmeye, krb5 principal tegtmeye@FOO.COM (krb5_kuserok)
    Oct  1 16:26:55 pawl sshd[2098]: Accepted gssapi-with-mic for tegtmeye from 123.456.789.123 port 53471 ssh2
    Oct  1 16:26:55 pawl sshd[2098]: krb5_cc_initialize(): Internal credentials cache error

    So the punch-line is that at this point if you add builtin:krb5login,privileged to system.login.tty you can at least partially keep your tickets giving you a one hop sso experience via ssh. Still can’t havin any ticket-relying network home directory as far as I can tell though.

    Mike

    tegtmeye
    Participant

    Getting the ticket beforehand doesn’t work either.

    Also, it was my understanding that ticket caches were in memory now for security reasons (CCacheServer) but between your post and googling around just now I’m not so sure anymore: From MIT Mac Kerberos: http://mailman.mit.edu/pipermail/kerberos/2008-January/012880.html

    But looking in a user’s home folder who does have tickets, I find nothing that remotely looks like a ticket cache, Also, inspecting Kerberos.app with valid tickets shows me suspicious things like

    /private/var/folders/+Q/+Q8xCPFMFRmVtQkuDhIMck+++TI/-Caches-/com.apple.IntlDataCache.le.sbdl
    /private/var/folders/+Q/+Q8xCPFMFRmVtQkuDhIMck+++TI/-Caches-/com.apple.ATS/annex_aux

    Which a random user would not be able to write to if they were logged on some random machine (or maybe this is done as root?)

    In any case, this seems to open up a pretty big security hole if you have to mount your home folders with pretty limited security enabled.

    I’ve looked around on the web pretty extensively regarding this and haven’t found much. I’m wondering what is the “best practice” setup for large enterprise setups who have users who are married to the command line across multiple machines? Surely it can’t be vanilla NFS?

    Thanks,
    Mike

    tegtmeye
    Participant

    You actually mounting a homefolder?

    Trying to. Seems any file sharing protocol that requires a ticket screws everything. For example:

    Setting macuser’s home folder to none or (NFS with standard auth for example) Works fine.

    eg with home dir set to none

    clutch:~ arl_admin$ ssh tegtmeye@clutch
    Password:
    Last login: Wed Oct  1 13:24:01 2008 from example.com
    Could not chdir to home directory 99: No such file or directory
    clutch:/ tegtmeye$ klist
    klist: No Kerberos 5 tickets in credentials cache
    clutch:/ tegtmeye$ kinit
    2008-10-01 13:30:22.329 kinit[813:10b] CFPreferences: user home directory at /99 is unavailable. User domains will be volatile.
    Please enter the password for tegtmeye@EXAMPLE.COM: 

    Now set home dir to kererized NFS or AFP with guest access turned off. Here AFP no guest, no other changes:

    clutch:~ arl_admin$ ssh tegtmeye@clutch
    Password:
    Last login: Wed Oct  1 13:30:17 2008 from example.com
    Could not chdir to home directory /Network/Servers/foo.com/Users/tegtmeye: Unknown error: 118
    -bash: /Network/Servers/foo.comUsers/tegtmeye/.bash_profile: Unknown error: 118
    clutch:/ tegtmeye$ klist
    Unknown Error Code: 118 while initializing Kerberos 5
    clutch:/ tegtmeye$ kinit
    kinit: Unable to create principal for current user: Unknown Error Code: 118
    kinit: Error getting initial tickets: Operation not permitted

    secure.log says:

    Oct  1 13:35:27 clutch com.apple.SecurityServer[36]: checkpw() succeeded, creating credential for user tegtmeye
    Oct  1 13:35:27 clutch com.apple.SecurityServer[36]: checkpw() succeeded, creating shared credential for user tegtmeye
    Oct  1 13:35:27 clutch authorizationhost[922]: k5_store_ticket_in_cache(): got -1765328188 (Internal credentials cache error) on plugins/krb5/krb5_operations.c:83
    Oct  1 13:35:27 clutch com.apple.SecurityServer[36]: Succeeded authorizing right system.login.tty by client /usr/sbin/sshd for authorization created by /usr/sbin/sshd.
    Oct  1 13:35:27 clutch sshd[916]: Accepted keyboard-interactive/pam for tegtmeye from 123.456.789.123 port 50055 ssh2

    for nfs, things get even worse. system.log says:

    Oct  1 09:13:28 clutch gssd[2539]: Error returned by svc_mach_gss_init_sec_context:
    Oct  1 09:13:28 clutch gssd[2539]:      Major error <1> Unspecified GSS failure.
      Minor code may provide more information
    Oct  1 09:13:28 clutch gssd[2539]:      Minor error <1> Unknown Error Code: 19777
    Oct  1 09:13:28 clutch gssd[2539]: nfs client Kerberos: exampe.com:/Users, uid=0 - Unknown Error Code: 19777
Viewing 5 posts - 1 through 5 (of 5 total)