> there I can configure the name of the srv-record. Can I do the same in
> krb5.conf? If yes what do I have to do?
>
> Thanks
>
> Stefan
>
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
Kerberos maili
me cases your only option was to use a fixed specific file on
the filesystem not even env vars...
Granted I think 99% of the time it is the other way around, so it would
be nice if we could rewind to the past and make strict acceptor default
to false, but there have been "reasons" f
rary of mine:
ttps://github.com/gssapi/mod_auth_gssapi/blob/master/src/mod_auth_gssap
i.c
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
OK-AS-DELEGATE flags: it’s advice to Kerberos clients that it’s OK to
> delegate credentials to the target host, which is exactly what we want
> to happen.
>
> The only thing we’re not completely sure about is whether setting the
> TRUSTED_FOR_DELEGATION flag in AD will have other
ship of a user by its authentication
ticket).
Philippe,
this is not a trivial problem, may make sense to consider what brought
you to this point and if there is any better way to handle the problem
at hand.
Simo.
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
__
r the specific use case
and specific file credential of the person that built it, and will fall
apart as soon as you do anything funny.
There is also no guarantee it is secure.
As much as I understand the desire of new languages to have "native
code" I strongly suggest to avoid the urge
avoided by network teams
> just supporting IPv6 and not blocking random ports for no reasons…
>
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/m
andable but it is unworkable given the
rest of the worldwide PKI infrastructure still relies on Intermediate
CAs that use 2k keys.
> and this key size makes small devices like the
> Yubikeys very slow when generating the keys. In fact, Yubikey
lly.
>
> > One of the problems I'm finding is that SSHv2 client
> > implementations are
> > proliferating, and IDEs nowadays tend to come with one, and not one
> > of
> > them supports GSS-KEYEX, though most of them support gssapi-with-
> > mic, so
>
principal.
HTH,
Simo.
--
Simo Sorce,
DE @ RHEL Crypto Team,
Red Hat, Inc
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
).
Until that holy grail is found I assume we'll always have arguments
about what is better or simpler or ..., and nobody will ever win one,
because what is better depends on the situation and the protocol and
the ecosystem, and the use case and the point of view...
Sim
er possible you should recommend people use GSSAPI and not krb5
APIs directly, unless they are building tools specifically to manage
aspects of krb5 (acquiring tickets, managing ccaches, etc.)
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
__
or the simplest case where both
realms are really handle by the same organization and are "fully
trusted" to relay this information from one to another.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
ng that RHEL-8 is almost 3 years old now) and is probably
causing the change in behavior wrt environment variables that you are
experiencing.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
oblem. Like having to set up a
> RADIUS
> server? Ugh. It's also a problem for development! Like the only
> way I have found to effectively test preauth mechanisms is to do
> testing on one of our replica KDCs.
Starting an ad-hoc kdc is pretty easy, I have it done in the make ch
s since I try to make pam-krb5 reasonably
> completionist as a hobby (although be aware that it's a purely hobby
> project at this point), but they would need to include changes to the ci
> directory to set up the KDC and RADIUS server appropriately so that the
> test suite could
of the value for the proxy (MS-KKDCP style) is that it
uses a standard port open in most places, and wraps everything in TLS
so that most inspection from broken HTTP middleboxes is prevented).
There is the added TLS channel encryption that can prevent a lot of
MITM as well given the client SHOUL
d not occur
> > (though, as you know, the situation does occur quite often in Active
> > Directory environments). Since the Ticket sname is in the unencrypted part
> > of the ticket, there is no value in validating its contents, as the Ticket
> > could be re-encoded wi
r, please notify the sender immediately by return e-mail and
> permanently delete the e-mail and any attachments.
>
>
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
s you usually have better telemetry than classic systems,
and is normally remoted from the stateless container, which means it is
much harder to alter to cover tracks, so perhaps this concern/risk can
also be better managed there, if you care for it.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
ck" or "false" in a future version. IMHO this
> would make it easier to deploy Kerberos applications in modern hosting
> environments.
FWIW in RHEL and Fedora we set rdns = false by default since 2013, and
we are now also setting dns
on-default
principal, if you have only one krbtgt regardless of what it is I
expect an NFS mount to try to use that credential.
Simo.
> > On Jul 23, 2019, at 9:35 AM, Simo Sorce wrote:
> >
> > On Mon, 2019-07-22 at 20:10 +, Charles Hedrick wrote:
> >
specific form for the user's principal
name to look for, but that can't be the default as it would break
current uses.
HTH,
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
ons, if they
> > exists or provide me the steps to make this work?
> >
> > Thank you in advance!
> >
> > Joseph
>
>
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
mediately by reply e-mail and delete this message. Thank you for
> your cooperation.
>
>
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
--
Simo Sorce
Sr. Principal Software En
rse.)
Available here:
https://github.com/latchset/kdcproxy
HTH,
Simo.
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
ng
> > ? (i.e., disable it, clear it, ...).
>
> The MIT krb5 client library does not cache SRV records.
But locator plugins might, so you need to know if any are in use.
Simo.
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
dal implementation of Kerberos,
> but is not present in MIT krb5.
>
> Upon cursory examination, it seems that
> krb5_get_init_creds_password() and krb5_verify_init_creds() together might
> be a suitable replacement. Note that it requi
On Fri, 2017-11-17 at 15:49 -0500, Simo Sorce wrote:
> On Fri, 2017-11-17 at 16:20 +, Chris Hecker wrote:
> > (Once more, with feeling...and also hopefully acceptable-to-mailman
> > formatting.)
> >
> > This is all kind of half-baked, so bear with me while I thin
n you would need to set an AI that says it is a
regular user, a steam user would get a "STEAM" indicator instead.
Then configure your TGS so that only krbtgts that have the regular Auth
Indicator can get tickets for the services you do not want to expose to
STEAM users. Bas
noticed rfc 2743 has the following comment about
> gss_{init,accept} calls only: "this call may block pending network
> interactions".
RFC2743 is generic, and with mechanisms different from krb5
gss_accept_sec_context() can indeed block. For example the N
ish the identity of the client).
At this point, depending on the protocol, SASL may be out of the way or
it may be still used to provide privacy/confidentiality protection for
the channel established between the peers.
So in a nutshell you should see SASL/GSSAPI as 2 things:
1. an authentication abs
.
There are some setting in Windows environments to enable Channel
Bindings (It's called Extended Protection for Authentication), and when
that is enabled and enforced a Proxy-in-the-middle would cause
authentication failures.
HTH,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
__
On Tue, 2017-03-14 at 18:59 +, Charles Hedrick wrote:
> The KEYRING mechanism is nice, in many ways. But it has some
> unexpected effects.
>
> There’s a “primary” key for the usual keyring. But this is a global
> object. That is, which cache is primary is the same for all sessions,
> and for N
are asking here honestly :-)
> Something to chew on for Kerberos 6 and a next generation of AD/IPAs.
> Kerberos 5 is pretty much married to DNS and can't go much farther
> than it's already gone.
We could relatively easily ass DNS records that each machine can set to
indicate what i
> have received this message in error, please notify the sender and delete
> > the email immediately.
> >
> > Kerberos mailing list Kerberos@mit.edu
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> >
&
is the size of packet
> size, what encryption is done and what are the sizes of keys etc.
You can find most of this information in RFC4120.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https
ewable.
> >
> > I guess it has something to do with the ssh-client on Mac OS X? (but
> > copying the ssh_config from linuxserver1 to the macbook does not solve
> > it. Copying the krb5.conf doesn't solve it either)
> > Or should I search the cause in another
On Wed, 2016-09-28 at 22:17 +0200, Cedric Blancher wrote:
> On 28 September 2016 at 19:01, Simo Sorce wrote:
> > On Wed, 2016-09-28 at 11:43 -0400, Ken Hornstein wrote:
> >> >Storing: Simply on a ram filesystem and use ACLS to tackle it down to
> >> >the list of
hat in production, right ? Because if you do, the
keyring issue is not the major problem here.
Besides there are various part of the kernel that depends on the keyring
now, disabling it is going to cause hard to diagnose issues or limit the
features you
ed users/uids can obtain the secure data.
We are working upstream to properly namespace the keyring too, once done
the container's case will be addressed too.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
ser Kerberos, it is also possible to pass a TGT from the
> service back to the client, and the client passes that verbatim without
> being able to make heads or tails of it. That is what I meant. But I
> may have been nitpicking, sorry about that.
user-to-user is a different protocol, it's not delegation, so I do not
understand how it relates.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
On Thu, 2016-08-25 at 13:26 -0400, Michael B Allen wrote:
> On Thu, Aug 25, 2016 at 10:09 AM, Simo Sorce wrote:
> > On Wed, 2016-08-24 at 22:05 -0400, Michael B Allen wrote:
> >> But, again, the point is that the client would not be "joined" to a
> >> dom
cret between them.
The user's KDC does not need to be the same as the server's KDC as long
as there is a way to create a trusted path between the two KDCs.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
I'm
> not taking anything out of context by saying that, I'm not sure about
> that but will probably be corrected if I am.]
The TGT is all you need. It gives you access to all the resources the
"real owner" has access to with no limitations. You do not need the lo
On Wed, 2016-08-24 at 15:55 -0400, Michael B Allen wrote:
> On Wed, Aug 24, 2016 at 3:12 PM, Simo Sorce wrote:
> > On Wed, 2016-08-24 at 12:35 -0400, Michael B Allen wrote:
> >> On Wed, Aug 24, 2016 at 2:36 AM, Rick van Rein
> >> wrote:
> >> > Hey Mi
erberos road.
>
> Unfortunately I don't know all the nomenclature so I'll duck this one.
The problem is name resolution is still a problem in 2016, mostly
because of bad practices everywhere and a DNS system that has always
been hard to use for the general public.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
ent phase for mutual authentication)
and just accept the 200 OK code as it comes
HTH,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
access_log from apache.
Sound like your Apache server is not configured to apply authentication
modules to the location you are asking for ?
A 200 OK message means either that authentication was successful, or was
not needed.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
r possible with mod_auth_gssapi ?
Yes, it is the whole point of the basic auth fallback option.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
_
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
ernt krb5.conf file (using the KRB5_CONFIG
environment variable) and use a completely separate directory for the
ccache files used by cron jobs, so they won't interfere with NFS ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
t; feel free to forward my reply to the list on reply, if needed)
>>
> Not intended. I've resent my message, and am now forwarding your full
> comments inline to the list.
>
> Thanks for your explanations, Simo!
>
>
>
> -Rick
> _
AuthorizationData carrying all the backend services
> are supported, and all these certificates could be in the name of the
> client. No FORWARDED TGT required, let alone its contained session key!
>
> I'm wondering if that angle would be a nicer one to consider for
> TLS-KDH, ins
t it's not easy to see the whole picture.
Documetns you may want to read:
MS-KILE: https://msdn.microsoft.com/en-us/library/cc233855.aspx
MS-PAC: https://msdn.microsoft.com/en-us/library/cc237917.aspx
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
- Original Message -
> From: "John Devitofranceschi"
> To: kerberos@mit.edu
> Cc: "Simo Sorce"
> Sent: Friday, July 17, 2015 6:52:01 AM
> Subject: Re: kerberos ticket cache
>
>
> > On Jul 10, 2015, at 10:06 AM, Simo Sorce wrote:
> &
gt; Also, we generally recommend that people use kdestroy to destroy
> Kerberos tickets.
The same is for Kerberized NFS in Linux, the session keys are stored in
the kernel and there is currently no way to revoke them, however once
the session is destroyed the kernel will not be able
ed virtual realms" may be more
> descriptive.
>
> I had nothing to do with it. :)
In AD there is a mapping function to know which user a certificate
belongs to. AD does not care at all about the name you have in there
outside the mapping. Once mappe
On Tue, 2015-06-02 at 21:29 -0700, Jim Shi wrote:
> Hi, Simo,
> Does this require to modify MIT KDC source code?
Yes
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/m
tools.ietf.org/html/draft-ietf-kitten-krb-auth-indicator-00
Hopefully this will be approved soon, implementation is underway.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
do the same with the
GSS-Proxy project, where keys can be segregated from the application.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
rly as open ended as MIT's CApath, and works only
with established (And 'verified') trusts relationships.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
ollowed by a kinit.
>
> I'd appreciate any thoughts anyone has, or other clues I might need to look
> for.
When rpc.gssd crawls /tmp for tickets, it will take the first one that
matches the uid, and try to use it. If it fails ... though luck.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
idate a cached
> > entry.
>
> It's nice to hear that we're not the only ones thinking this is not
> such a good idea.
>
>
> @Simo
> On 13.03.2015 at 17:24 Simo Sorce wrote:
> > Note that NFS does not cache a ticket, it simply does not destroy
> >
time.
> * Are the ideas under (1) and (2) above worth considering?
Probably not. (1) should be handle with additional Authorization Data
(2) probably using FAST into a pkinit anonymous channel.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
ce to allow to destroy the NFS's user session on kdestroy has
been discussed with NFS upstream before but it hasn't gone anywhere yet.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
On Thu, 2015-02-12 at 17:57 +0100, Michael Ströder wrote:
> Simo Sorce wrote:
> > On Thu, 2015-02-12 at 09:28 +0100, Gergely Czuczy wrote:
> >> On 2015-02-11 15:25, Simo Sorce wrote:
> >>> You should also search on KrbCanonicalName if you need exact matching,
> &g
On Thu, 2015-02-12 at 09:28 +0100, Gergely Czuczy wrote:
> On 2015-02-11 15:25, Simo Sorce wrote:
> > On Wed, 2015-02-04 at 12:24 +0100, Michael Ströder wrote:
> >> HI!
> >>
> >> Maybe some of you are using MIT Kerberos with LDAP backend.
> >>
&g
On Wed, 2015-02-11 at 16:24 +0100, Michael Ströder wrote:
> Simo Sorce wrote:
> > On Wed, 2015-02-04 at 12:24 +0100, Michael Ströder wrote:
> >> HI!
> >>
> >> Maybe some of you are using MIT Kerberos with LDAP backend.
> >>
> >> For creating a
A5Match, so for convenience I'd
> add something to use caseIgnoreIA5Match without the user having to select that
> himself.
You should also search on KrbCanonicalName if you need exact matching,
krbPrincipalName is multivalued and may
rk done in FreeIPA, but is not yet included in
the MIT code.
> Even after reading MIT's test file
> (https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_s4u2proxy_krb5.c)
> dedicated to s4u2proxy, I've not seen any "unusual" gss scenario or
> calls. It basicall
e
neded, and/or support constrained delegation on the receiving end
(s4u2proxy).
My2c.
simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
On Wed, 17 Sep 2014 22:30:29 +0200
Cedric Blancher wrote:
> On 17 September 2014 17:05, Simo Sorce wrote:
> > On Wed, 17 Sep 2014 13:20:19 +0200
> > Cedric Blancher wrote:
> >
> >> What happens if there is no relation between KRB Realm names and
> >> FQDN
apping in the appropriate section in krb5.conf
on the client.
2. allow the KDC to send back a referral (but not all clients will ask
their own KDC, some can do only 1).
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list
- Original Message -
> From: "Cedric Blancher"
> To: "Simo Sorce"
> Cc: "Jurjen Bokma" , "" ,
> "Linux NFS Mailing List"
> , "Steve Dickson"
> Sent: Tuesday, September 9, 2014 8:31:00 PM
> Subject: Re:
ent key for different shares.
It allows you to choose a different key for the *machine* principal, but
does nothing for authenticating users using different credentials.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
or GSSAPI know which of the
> entries is the one they want?
They'll make a guess based on the realm, or pick the primary.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
are of a similar facility for Nginx?
No, but if the code does not require enormous changes I could consider
restructuring it to build a nginx module too (patches would also be
welcome :-)
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos maili
On Thu, 2014-08-14 at 18:43 -0400, Simo Sorce wrote:
> On Thu, 2014-08-14 at 15:29 -0700, Chris Hecker wrote:
> > By being gss-only, do you mean the module, or clients must use gss as well?
>
> yes.
Oups I misread the question, the module uses GSSAPI only, the clients
can use wh
On Thu, 2014-08-14 at 15:29 -0700, Chris Hecker wrote:
> By being gss-only, do you mean the module, or clients must use gss as well?
yes.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
ht
of use to others.
Simo.
[1] https://github.com/modauthgssapi/mod_auth_gssapi
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
On Thu, 2014-08-14 at 20:47 +, Jaap Winius wrote:
> On Thu, 14 Aug 2014 09:56:35 -0400, Simo Sorce wrote:
>
> > Keep in mind that this will make f...@myrealm.com and f...@example.com
> > effectively the same user...
>
> Yes, a nuance that did not escape me. In fact
h_to_local = RULE:[1:$1@$0](.*@MYREALM.COM)s/@MYREALM.COM$/@myrealm.com/
(hopefully got the replaces right :-)
This would result in:
f...@example.com -> foo
f...@myrealm.com -> myrealm-foo [or f...@myrealm.com]
So you can distinguish between the 2 users.
Simo.
--
Simo Sorce *
- Original Message -
> Hi,
>
> > The KDC has no way of knowing if DNS is correct or wrong,
>
> It could of course use a DNSSEC-aware resolver.
>
> > nor would it
> > trust the DNS
>
> That is a setting with MIT krb5, and an admin could feel safe to enable it
> after setting up DNSSEC.
ey. If you have the correct key that is proof
you are who you claim to be regardless of what DNS may think.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
ls required to manage this properly, or if typical
> clients would cope.
The FreeIPA project uses random salts since when we started, it seem all
clients we know of cope just fine.
We do not change rounds, so I can't speak about changing that.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
g to to redefine prototypes for accept and connect
> to determine whether a system is using socklen_t. But it's pretty
> complicated and the author wasn't completely confident in its
> correctness at the time.
> _______
nel to communicate with the client instead of just using the
existing channel the client opened against the server.
Opening back channels from servers have been proven brittle (firewalls,
NAT, etc.. all get in the way) time and again since ages, se
ea).
I think what you mean is that not all mobile devices can use dyndns to
update the name -> ip map, but this shouldn't be a problem in the NFS
case.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list
T Krb 1.11, we haven't backported it to RHEL 6
which runs on 1.10, RHEL 7 will have keytab initiation support.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
ion algorithms when
releasing tickets for the principal to other clients.
HTH,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
On Thu, 2014-03-20 at 14:24 +0100, ольга крыжановская wrote:
> Simo, please be careful with advertising. Fedora has the same problem.
>
> Olga
>
> On Thu, Mar 20, 2014 at 2:16 PM, Simo Sorce wrote:
> > On Thu, 2014-03-20 at 13:05 +0100, Wendy Lin wrote:
> >> Doab
uy a service contract from a distribution you will get
tested stuff, documentation and help with this kind of issues... just
saying.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit
y vs confidentiality bits, so if you use
a library like cyrus-sasl you need to pass to it the "ad_compat" option,
or some Active Directory servers with stricter policies may refuse to
connect.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
_
uld be the approach here. Pls let me know if
> there is any specific GSS or Kerberos API that can be used here.
> Help would be highly appreciated.
You could look into using GSS-Proxy to handle privilege separation:
https://fedorahosted.org/gss-proxy/
however it requires the exclusive use o
re that Samba3 supports.
Samba 3.x doesn't really have any specific support for the kpasswd
protocol except perhaps as a client in Winbind.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
t makes no sense to have
no allowed clients (why would you create an ACI if that were the case,
absence of an ACI already prevents access).
HTH,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
t;, a regex
would not really do it nuless you are thinking of ".*"
We could change the code so that you have to add the literal "ALL"
maybe, I am not opposed, and could easily migrate FreeIPA users to that
syntax.
Shawn, what do you think ?
Simo.
--
Simo Sorce *
we are working on bringing
this to the standard MIT LDAP driver.
Se the project page here:
http://k5wiki.kerberos.org/wiki/Projects/KerberosDelegationACL
If you want to help with this effort there is some work to do to
implement thi in the current MIT LDAP code.
Simo.
--
Simo Sorce * Red Hat, I
On Thu, 2014-01-09 at 09:04 -0800, Russ Allbery wrote:
> Simo Sorce writes:
> > On Thu, 2014-01-09 at 08:35 -0800, Russ Allbery wrote:
>
> >> Debian distinguishes between interactive and noninteractive sessions,
> >> yes. But I don't believe that r
1 - 100 of 162 matches
Mail list logo
