search for: krb5_kuserok

Attached is a patch which in my environment (Linux/Heimdal 1.2.1) fixes cross-realm GSSAPI authentication. Changes it makes: 1. When using krb5_kuserok, do not call gss_compare_name to check that authn_name and authz_name are the same. Instead, make TWO calls to krb5_kuserok, one for each ID. If both IDs are acceptable, allow the login. 2. Disable checking that the name is a GSS_KRB5_PRINCIPAL_NAME, as this doesn't appear to be always the c...

https://bugzilla.mindrot.org/show_bug.cgi?id=2032 Priority: P5 Bug ID: 2032 Assignee: unassigned-bugs at mindrot.org Summary: Local user name in krb5_kuserok call Severity: normal Classification: Unclassified OS: AIX Reporter: miguel.sanders at uniforce.be Hardware: PPC Status: NEW Version: 6.0p1 Component: Kerberos support Product: Portable OpenSSH Created att...

...aneous failure (Credentials cache permission incorrect) Failed password for <user> from <ip> port <port> ssh2 -- I had a look at the responsible source code in auth-krb5.c. By doing some debugging there I found out that the following code fragment fails: auth-krb5.c:137 --- if (!krb5_kuserok(authctxt->krb5_ctx, authctxt->krb5_user, authctxt->pw->pw_name)) { problem = -1; goto out; } --- When I comment out this if-block then I can login using OpenSSH's internal kerberos support and even get my kerberos5 ticket and KRB5CCNAME. I'm not that involved into kerbe...

...ver when I attempt to authenticate using cross realm authentication the login fails (logs below). After perusing the source code I beleive that the problem is as such: All taking place in mech-gssapi.c 1. mech_gssapi_userok(...) calls mech_gssapi_krb5_userok 2. mech_gssapi_krb5_userok(...) calls krb5_kuserok(...) to verify that the given Kerberos prinicpal can log in as the requested user. 3. The authentication process is running as the Dovecot user so: 3a. krb5_kuserok(...) looks for ~dovecot/.k5login to authorize cross realm logins 3b. There is no ~dovecot/.k5login, thus no cross realm access is...

...ALM" and the authz_name is "username" (or vice versa, I don't remember). The attached patch causes dovecot to display these two values in human-readable format to illustrate the issue. Because these two GSS names differ, Dovecot refuses to allow access in spite of the fact that krb5_kuserok would return TRUE. I am not the only one to have noticed this problem: http://dovecot.org/pipermail/dovecot/2007-July/023868.html http://dovecot.org/pipermail/dovecot/2007-October/026027.html Might I suggest that some more robust security checking be done instead of abusing gss_compare_name like...

...a reply; krb5_ticket *ticket; + Key k; + char *client_name; int fd, ret; ret = 0; @@ -95,14 +98,30 @@ if (problem) goto err; + if (!krb5_unparse_name(authctxt->krb5_ctx, authctxt->krb5_user, + &client_name)) + goto err; + /* Check .k5login authorization now. */ - if (!krb5_kuserok(authctxt->krb5_ctx, authctxt->krb5_user, - authctxt->pw->pw_name)) + k.type = KEY_NAME; + k.name = client_name; + k.name_type = "krb5"; + + ret = user_key_allowed(authctxt->pw, &k); + if (ret < 0) { + ret = 0; goto err; + } + if (ret == 0 && !krb5_kus...

Hello, SSH supports ~/.ssh/authorzied_keys for SSH keys and ~/.ssh/authorized_principals for X509 certs. I could not find an equivalent of authorzied_keys using Kerberos authentication. IMHO it should be possible using the Kerberos principal very much like the principal contained inside a X509 certificate. My main use case is assigning a specific command to a user logging in using Kerberos

[Apologies if this is an off-topic question; please direct me to a more appropriate place if so.] Using Kerberos/GSSAPIAuthentication, is there a way to centrally control/manage (perhaps using LDAP?) which user principals can log into what hosts/accounts? -- Jos Backus jos at catnook.com

...ot receive identification string from ([:[:xdigit:].]|UNKNOWN)+$ +^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sshd\[[0-9]+\]: Did not receive identification string from ([:[:xdigit:].]+|UNKNOWN)+$ ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sshd\[[0-9]+\]: Authorized to [^[:space:]]+, krb5 principal [^[:space:]]+ \(krb5_kuserok\)$ ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ sshd\[[0-9]+\]: error: Could not get shadow information for NOUSER$ ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ sshd\[[[:digit:]]+\]: Bad protocol version identification '[^']*' from ([:.[:xdigit:]]+|UNKNOWN)$ -- Please do not send copies of list m...

...n in case anyone finds it useful. The major drawback is that it doesn't work under privsep, due to the chroot jail. I tried adding the necessary files under /var/empty and was able to get the password change to work, but then authentication itself still fails (in auth_krb5_password_via_kbd_int:krb5_kuserok(), possibly due to the absence of <chroot>/etc/.name_service_door). Does anyone know if it's architecturally possible to get this code to work under privsep, or rather, out from under privsep? Privsep is a bit difficult to debug, but I'll keep plugging away if need be. (Note, this...

...keytab But on the member use : net ads keytab add idmap/your.host.tld at REALM This add the spn to the local keytab file AND the AD. Here you have 2 options. Use the system default keytab file or setup a separated. And you might need to add in the krb5.conf the line ignore k5login # due to krb5_kuserok() is used to check if access is allowed. Greetz, Louis > -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens > basti via samba > Verzonden: woensdag 12 december 2018 16:02 > Aan: samba at lists.samba.org > Onderwerp: Re: [Samba] G...

...principal princ; + int retval; + + if (ssh_gssapi_krb5_init() == 0) + return 0; + + if ((retval = krb5_parse_name(krb_context, client->exportedname.value, + &princ))) { + logit("krb5_parse_name(): %.100s", + krb5_get_err_text(krb_context, retval)); + return 0; + } + if (krb5_kuserok(krb_context, princ, name)) { + retval = 1; + logit("Authorized to %s, krb5 principal %s (krb5_kuserok)", + name, (char *)client->displayname.value); + } else + retval = 0; + + krb5_free_principal(krb_context, princ); + return retval; +} + + +/* This writes out any forwarded cre...

...g the Capsicum API introduced in FreeBSD 10. * Switch to a ChaCha20-based arc4random() PRNG for platforms that do not provide their own. * sshd(8): bz#2156: restore Linux oom_adj setting when handling SIGHUP to maintain behaviour over retart. * sshd(8): bz#2032: use local username in krb5_kuserok check rather than full client name which may be of form user at REALM. * ssh(1), sshd(8): Test for both the presence of ECC NID numbers in OpenSSL and that they actually work. Fedora (at least) has NID_secp521r1 that doesn't work. * bz#2173: use pkg-config --libs to include correct...

...} #endif With these two changes, ssh is now able to authenticate with Kerberos, and I get a nice shell prompt on the remote machine. Server logs look good too: WARNING: /usr/local/etc/moduli does not exist, using fixed modulus Authorized to vatester, krb5 principal vatester at VADEV.COM (krb5_kuserok) Accepted gssapi-with-mic for vatester from 10.18.3.52 port 2729 ssh2 I honestly have no clue how this could have ever have worked - my guess is that at one point in the past libgssapi didn't use the gss_union_name_t, and just used krb5_principal as a return parameter from gss_accept_sec_co...

Hi, we are currently moving our mailserver to a new server with Dovecot, virtual users in LDAP, Passwords in Kerberos Setup. Everything works fine except for GSSAPI which seems to be a bit buggy. The thing is, that when using a .k5login [1] file it seems that SASL does not get passed the home directory specified userdb. In other words, mails for user1 (see below) are stored in

...g the Capsicum API introduced in FreeBSD 10. * Switch to a ChaCha20-based arc4random() PRNG for platforms that do not provide their own. * sshd(8): bz#2156: restore Linux oom_adj setting when handling SIGHUP to maintain behaviour over retart. * sshd(8): bz#2032: use local username in krb5_kuserok check rather than full client name which may be of form user at REALM. * ssh(1), sshd(8): Test for both the presence of ECC NID numbers in OpenSSL and that they actually work. Fedora (at least) has NID_secp521r1 that doesn't work. * bz#2173: use pkg-config --libs to include correct...

Hello, I try to setup Dovecot with Kerberos/GSSAPI and use this howto: https://wiki.samba.org/index.php/Authenticating_Dovecot_against_Active_Directory#Create_the_Dovecot_user_and_keytab I also try https://wiki.dovecot.org/Authentication/Kerberos I can login as windows user on win7 and access shares. When I open Thunderbird I get the message: "kerberos/gssapi ticket was not accepted"

Playing around with the [wonderful] GSS-API patches for OpenSSH [1] I noticed that there is a bit of functionality missing from OpenSSH/GSS-API, namely that authorized_keys2 has no meaning when using GSS authentication. Yes, ~/.k5login can be used to grant access to an account for applications that support Kerberos, as does OpenSSH with those GSS patches, but .k5login does not and cannot provide

...own at loglevel>=verbose) Portable OpenSSH: * Switch to a ChaCha20-based arc4random() PRNG for platforms that do not provide their own. * sshd(8): bz#2156: restore Linux oom_adj setting when handling SIGHUP to maintain behaviour over retart. * sshd(8): bz#2032: use local username in krb5_kuserok check rather than full client name which may be of form user at REALM. * ssh(1), sshd(8): Test for both the presence of ECC NID numbers in OpenSSL and that they actually work. Fedora (at least) has NID_secp521r1 that doesn't work. * bz#2173: use pkg-config --libs to include correct...

...domain to a new domain structure. Do not use periods in new NetBIOS domain names. but again, i dont know sssd that "might" be normal. Per example, my kerberized output of auth.log Jul 16 15:57:24 member1 sshd[110373]: Authorized to username, krb5 principal username at MY.REALM.TLD (krb5_kuserok) Jul 16 15:57:24 member1 sshd[110373]: Accepted gssapi-with-mic for username from 192.168.0.1 port 53254 ssh2: username at MY.REALM.TLD Jul 16 15:57:24 member1 sshd[110373]: pam_unix(sshd:session): session opened for user username by (uid=0) Jul 16 15:57:24 member1 systemd-logind[726]: New session...