n
using GSSAPI/Krb5, an IP address cannot be resolved to a proper key as
keys are registerd into the KDC as
host/machine.fully.qualified.name@REALM.
It's the same thing as with HTTPS, the client need to know the "name" of
the server in order to be able to properly communicate with it.
tten WG we are also starting the process to
deprecate RC4 and 3DES and we have a ticket to stop using them by
default in FreeIPA too: https://fedorahosted.org/freeipa/ticket/4740
HTH,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
;>>
> > >>>>>>>>> Matt
> > >>>>>>>>>
> > >>>>>>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat :
> > >>>>>>>>>> Hi,
> > >>>>>>>>>>
> > >>>>>>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind
> > >>>>>>>>>> a load
> > >>>>>>>>>> balancer, specifically Amazon ELB.
> > >>>>>>>>>>
> > >>>>>>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf
> > >>>>>>>>>> but looks like
> > >>>>>>>>>> there is more to it than just this file.
> > >>>>>>>>>>
> > >>>>>>>>>> Any suggestions ?
> > >>>>>>>>>>
> > >>>>>>>>>> Thanks.
> > >>>>>>>>>> --Prashant
> >
> >
> > --
> > Thank you,
> > Dmitri Pal
> >
> > Sr. Engineering Manager IdM portfolio
> > Red Hat, Inc.
> >
>
> kerberos is load balancer friendly, if you pet it nicely.
>
> you generate a principal for the VIP. you then create a keytab for the
> VIP. you distribute the keytab via SCP (or other secure method) to all
> load balanced pool members. you must distribute the same exact keytab
> to all devices. the KVNO for the VIP principal must match in all copies
> put on the pool members. use "klist -Kket /path/to/file.keytab" to
> validate this on all pool members.
>
> there are additional steps you may want to take, in order to add the
> individual principal(s) to the same keytab, so that you can access the
> pool members themselves (not via the VIP). this requires that you
> distribute the keytab as above, and then add the individual principals
> to the local copy of the keytab file.
>
> example:
>
> you have created the principal ldap/ldap.domain.tld for your VIP
> you have created the keytab for ldap/ldap.domain.tld as ~/ldap.keytab
> you have copied the keytab file ~/ldap.keytab to server1, server2 and
> server3 as /etc/ldap.keytab
>
> you ssh to server1 and run kadmin.
> you then add a principal ldap/server1.domain.tld
> you then add the principal ldap/server1.domain.tld to the already
> existing keytab /etc/ldap.keytab.
> quit kadmin
>
> when you run "klist -Kket /etc/ldap.keytab" you should see two
> principals in it. the VIP name and the hostname.
>
> lather, rinse, repeat for all servers.
>
> keep in mind the administrative overhead of changing names of servers or
> VIPs.
>
> there are other tricks for doing kerberos stuff. i use the same VIP,
> but different ports in order to access an individual host/service behind
> the load balancer. this works because the name (of the VIP) stays the
> same and i just point a different front end port to an individual
> backend device/port.
>
This is all true if you just accept connections.
(Un?)fortunately we use delegation within IPA, which requires to use a
local key to contact the KDC. This action "fixates" what key we are
going to use to accept incoming context establishment requests. If a
principal name is not specified then the selected key is usually the
first in the keytab.
In an IPA setup that will usually be the server's specific key.
In order to use multiple keys in conjunction with IPA we'd have to
explicitly support. I am not sure if the SSL layer records which name
was used (perhaps it does if SNI is used, but almost certainly not is
SAN are used), or if multiple virtual hosts need to be used.
If we can know what name the client used then we could modify
mod_auth_gssapi to select a specific name to acquire creds and then
accept the connection with the correct keys. (Another option would be to
explicitly retry with each available key if something fails).
I am afraid I won't try to coerce mod_auth_kerb to do that, so this
option is probably something we can do only post 4.2 and only if we can
make appropriate modifications.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
On Tue, 2015-03-31 at 13:21 -0400, Brendan Kearney wrote:
> On Tue, 2015-03-31 at 12:53 -0400, Simo Sorce wrote:
> > On Tue, 2015-03-31 at 11:41 -0400, Brendan Kearney wrote:
> > > On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote:
> > > > On 03/31/2015 10:38 AM
On Tue, 2015-03-31 at 13:50 -0400, Simo Sorce wrote:
> But IPA is more complex and some operations will be performed directly
> against the specific server name, so you need to keep 2 sets of keys
> (one for the server name and one for the load balancer name), but that
> does not wo
whole keyset is encrypted with the
master key, so the hashes cannot be seen even if you have access to the
LDAP attribute.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go
On Thu, 2015-04-02 at 00:22 +0100, g.fer.or...@unicyber.co.uk wrote:
> Hi
>
> if you got the NTPs in sync and using the same timzeone on both it
> should be ok
All operations use UTC, so you can set whatever timezone you want on the
machines.
Simo.
--
Simo Sorce * Red Hat, In
e available on-demand computing power provided by
cloud operators, so distributing hashes is riskier than ever, especially
old hashes based on DES or MD5, but SHA-1 is not far down the list.
HTH,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-user
users nor really services, so
keeping it in cn=kerberos for now it is fine.
However do not use kadmin.local to create actual user principals please.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/l
https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
>
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
I wrote a blog post to clarify a little bit how load balancers and
Kerberos interact: https://ssimo.org/blog/id_019.html
HTH,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go
s or providing explicit
support in the new aname2lname plugin.
To do all this means adding new objects and configuration facilities to
handle these special non-users, we haven't yet found enough benefit in
adding support for these to warrant the work involved.
Simo.
--
Simo Sorce * Red Hat, I
On Tue, 2015-04-07 at 14:16 +, coy.h...@coyhile.com wrote:
> Quoting Simo Sorce
>
> > On Mon, 2015-04-06 at 21:16 -0400, Coy Hile wrote:
> >> In MIT land, one can potentially have multiple instances tied (by
> >> convention) to a given user (that is, that admin
cy if you kinit manually ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
On Tue, 2015-04-07 at 18:54 +, Coy Hile wrote:
> Quoting Simo Sorce :
>
> >> >
> >> >
> >> I guess that makes sense. Is it possible to add a user that simply
> >> doesn't have the posix attributes defined? In the particular case of
>
On Tue, 2015-04-07 at 22:01 -0400, Coy Hile wrote:
> > On Apr 7, 2015, at 2:58 PM, Simo Sorce wrote:
> >
> > On Tue, 2015-04-07 at 18:54 +, Coy Hile wrote:
> >> Quoting Simo Sorce :
> >>
> >>>>>
> >>>>>
&
On Wed, 2015-04-08 at 10:11 +0200, Martin (Lists) wrote:
> Am 07.04.2015 um 18:27 schrieb Simo Sorce:
> > On Tue, 2015-04-07 at 17:57 +0200, Martin (Lists) wrote:
> >> Hallo
> >>
> >> attached you can find the data from krb_child.log. As far as I can see
>
for external
users/groups (IIRC).
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
On Mon, 2015-04-27 at 12:51 +0200, Martin Kosek wrote:
> On 04/26/2015 08:23 AM, Alexander Bokovoy wrote:
> >
> >
> > - Original Message -
> >> Hi Rob and Dimitri
> >>
> >> Migrating via Replica is the obvious way that I would have gone, had the
> >> FreeIPA /RedHat documentation not sugg
what we should do is to have a logout option that says "log in
with a different user" and redirect to anon kerberized page that allows
you to do form based login.
This would address the case where a domain user wants to log in as admin
w/o exiting their user session or destroying there ccache
r completeness.
>
> thanks
>
> Chris
>
>
>
> From: Simo Sorce
> To: d...@redhat.com
> Cc: Rob Crittenden , Christopher
> Lamb/Switzerland/IBM@IBMCH, freeipa-users@redhat.com
> Date: 29.04.2015 03:31
> Subject: Re: [Freeipa-users] Fre
ed.org/freeipa/ticket/5010
>
> As this my first Fedora ticket, please forgive me If I didn't do it right
> 8-)
It's perfectly fine, thank you.
Simo.
> Cheers
>
> Chris
>
>
>
>
> From: Craig White
> To: Christopher Lamb/Switzerland/IBM@IBMCH, S
ing here?
Have you recently changed the user password ?
If so this symptom may indicate you are having replication issues
between your servers, and one of the client is hitting the server that
didn't get the keys replicated to it.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your
Is this expected? It's with 4.1.0.
> >> Yes, we have a bug for this, actually, few of them:
> >> https://fedorahosted.org/freeipa/ticket/4757
> >>
> >> The actual issue is due to https://fedorahosted.org/freeipa/ticket/4914
> >>
> >
> >Well, in this case the principal isn't changed at all, it's still
> >b...@example.test, which is why the password doesn't work. There probably
> >is no bob1 principal anywhere.
> Yep, and there is a note in the first bug (#4757) about that. I think
> ipa user-mod should be doing that rename for krbPrincipalName too but we
> need to fix password generation via kadmin as well because chances are
> that users changed their passwords via SSSD which leads to kadmin use.
Patch to fix this is sitting in the fedora-devel list for a month or so,
please review and ack it.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
by that other replica, restart all IPA components and make sure
a round of replication happens. Then restore the krb5.conf file and
restart all.
> > Or it is better to destroy it and do a new install?
>
> That may be even faster for the making that particular replica up and running
> a
0 Jun 2 16:05 known_hosts
> drwxr-xr-x 2 root root 4096 May 28 01:13 krb5.include.d
> [root@ipaclient pubconf]#
>
> So... I am still looking for the actual location on disk that this is
> apparently being cached and cannot find it.
You won't find a "file" because
.
I think we have a report about the "case" used to generate some
algorithm names, that get embedded in the QR code:
https://fedorahosted.org/freeipa/ticket/5047
It may be the same issue here.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freei
volved that is
causing you trouble.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
ction(PSTRING const &, PSTRING const &,
> int, JSTRING const &) ()
> #23 0x08059106 in EXCO::Initiate(void) ()
> #24 0x0805a355 in EXCO::Edit(void) ()
> #25 0x080544f5 in main ()
>
> // Richard
>
> 2015-06-15 15:34 skrev Simo Sorce:
> > On Sun, 2015-06-14 at 20
@ipadomain.net
> kvno: Credentials cache file '/tmp/krb5cc_0' not found while getting
> client principal name
> [root@fe1 home]# kinit username
> Password for usern...@ipadomain.net:
> [root@fe1 home]# kvno host/fe1.ipadomain@ipadomain.net
> host/fe1.ipadomain@ipadomain.net: kvno = 1
This is normal, you can obtain a ticket (that's what kvno does) only if
you have a TGT (which is stored in the Credentials Cache).
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
or:
> CA did not start in 300.0s
>
>
> I've modified the
> /usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py to
> increase the timeout value, but no luck.
>
> Suggestions?
What pki-base package version do you have installed ?
Simo.
--
Simo Sorc
On Thu, 2015-06-18 at 10:47 -0500, James Benson wrote:
> Freeipa 4.1.4
Please run rpm -qi pki-base
> On 06/18/2015 10:28 AM, Simo Sorce wrote:
> > On Thu, 2015-06-18 at 10:08 -0500, James Benson wrote:
> >> Hi all,
> >> I'm a fairly advanced user, how
; Rather, it is a virtual view of some other data in the directory.
>
> --
> / Alexander Bokovoy
>
What this means is that you need to explicitly turn on schema compat on
each server you want to use to serve it.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Fre
r requirements?
>
> With the recent 'views' feature, you can set POSIX attributes for IPA
> users without touching the AD LDAP schema, even per-host.
Just for clarity:
note that use of these features will require an upgrade of your server
to the latest Centos 7.2 (whe
p the 3rd replica agreements with the first
after you create agreements that connect the third to the second.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
u are not alone and can share experiences, ask for
help and in general get up to speed with various parts of the
infrastructure as you need it, not being forced to know everything like
a pro before even starting.
This is my humble opinion.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage y
ation is
> not aware of the service used. If e.g. OTP was used to just get a
> response from some unprotected and unprivileged service the intercepted
> password can be used to log in with ssh as well. So I guess we need a
> careful discussion here.
The solution for this environments already exists and it is called
GSSAPI. You can obtain a ticket with 2FA and then use your TGT for 10 or
more hours. There is no need to invent broken ways to skip two factor
auth when we already have a way to make this easy *and* secure.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
s
> a freeipa user with valid kerberos ticket it appears to work fine though. I
> cannot get it working from a remote client however. Is this error a red
> herring or should I be concerned about this? kvno and klist show same number.
What's the output of klist -kt /opt/oracle/ad
06/30/15 17:12:13 oracledb/oracledbsrvr.example@example.com
>2 06/30/15 17:12:13 oracledb/oracledbsrvr.example@example.com
>2 06/30/15 17:12:13 oracledb/oracledbsrvr.example@example.com
> From: Simo Sorce
> To: sipazzo
> Cc: Freeipa-users
> Sent: Tuesda
(have ipa 4.1 and samba 4.1.12 here)
>
> Greetz
> Christoph Kaminski
>
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
using kpasswd it may happen if a re-transmission
occurs, as kpasswd uses UDP, so the second request ends up with that
error, I think, not 100% sure.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/
/sssd/sssd.conf was moved
> to /etc/sssd/sssd.conf.deletedSSSD service could not be stoppedRestoring
> client configuration filesnscd daemon is not installed, skip
> configurationnslcd daemon is not installed, skip
> configuration/etc/ipa/default.conf could not be removed: [Errno 2
Dogtag project component that implements the
secure storage for the Vault feature.
HTH,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
ell me the correct file?
> >
> > Thanks for a answer
> >
> > --
> >
> > mit freundlichen Grüssen / best regards,
> >
> > Günther J. Niederwimmer
> >
> >
> >
> Hi,
>
> IPA CA certificate is located here /etc/ipa/ca.crt on serv
On Tue, 2015-08-18 at 18:01 -0400, Simo Sorce wrote:
> The load balancer would have to have the exact same name (for the
> clients) as the IPA server, which may be challenging depending on the
> network configuration you have.
More on that issue here:
http://ssimo.org/blog/id_019.html
t;> not redirect to https? Reason is simple - offloading SSL to a load
> >> balancer on the front end. (this is for web only, not the LDAP or
> >> Kerberos)
> >>
> >> Thank you
> >> ~J
> >>
> >
> > You could try disabling t
you.
There is still the problem of the referer, but should be easy to fix
with a rewrite rule.
Simo.
> ~J
>
> On 8/18/15 3:02 PM, Simo Sorce wrote:
> > On Tue, 2015-08-18 at 18:01 -0400, Simo Sorce wrote:
> >> The load balancer would have to have the exact same name (
*RHCE, VCE-CIA, RACKSPACE CLOUD U Certified*
> >
> > <https://www.fb.com/yks> <http://in.linkedin.com/in/yks>
> > <https://twitter.com/checkwithyogesh>
> > <http://google.com/+YogeshSharmaOnGooglePlus>
> >
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
anpage which will tell
you that the way you are specifying the umask is incorrect :-)
Hint: see oddjob-mkhomedir.conf
HTH,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http
e authoritative at the
> >> same time as AD. (Neither we support IPA being a slave for other DNS
> >> server).
> >>
> >>> 3) Have the IPA manage the forward zone (linux.corp.com), and have the
> >>> clients update its own A record automatically
} 5587c5c30003 55b8a04900010003
> unable to decode: {replica 5} 55cc82ab041d0005 55cc82ab041d0005
Have you tried restarting DS before trying to clean the ruv ?
I run in a similar problem in a test install recently, and I got better
results that way. The bug is known to th
> > --
> >
> >3 30/08/2015 15:50:36 libvirt/nice-hkvm-ctrl
> > -01.core.nice.cloud.oliv
> > arim@cloud.olivarim.com (aes256-cts-hmac-sha1-96)
> >3 30/08/2015 15:50:36 libvirt/nice-hk
ds ?
There is a global DNS option (As awell as per-zone setting) called
"Allow PTR Sync" you may want to enable.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://fre
sing ipa-getkeytab -P, if it is
not, please file a bug.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
e to disable clients from using
UDP completely, although I am not 100% certain this will avoid the
problem, IIRC at least in some versions the client library would retry
after 1 second even on TCP.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users
not be able to share
the same DNS namespace).
HTH,
Simo.
http://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA
Lenka was already investigating https://fedorahosted.org/freeipa/ticket/3656,
so some updates may happen.
--
Simo Sorce * Red Hat, Inc * New York
IDM are so closely coupled, for someone who requires
HBAC, the choice is either take both SSSD and IDM or neither. So other
solutions are being explored instead.
Do these reasons make sense as to why I posted the original ask?
When SSSD is integrated directly in AD you can use Group Pol
ames, so looking at file permissions
you will not be able to see user names, but only SIDs for IPA users.
Some tools that may depend on SID->Name translation may also fail in
unexpected ways.
This is why we do not recommend to try this, but it is technically
possible if you know very well how to
On 02/10/15 04:06, Alexander Bokovoy wrote:
On Thu, 01 Oct 2015, Simo Sorce wrote:
On 01/10/15 03:15, Petr Spacek wrote:
On 30.9.2015 20:36, Matt Wells wrote:
Hi all, I hoped I may glean some brilliance from the group.
I have a Freeipa Server sitting atop a Fedora 21 server. The
initial plan
mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
--
/ Alexander Bokovoy
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/free
should land in RHEL7.3 and hopefully make it easier to deal with this
problem.
https://fedorahosted.org/freeipa/ticket/5614
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to ht
uide/id-views.html
Also here:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/id-views.html
note that ID Views are not confined just to AD trust environments this
second doc is just to have a wider view of the feature.
HTH,
Simo.
--
Simo Sorce * Red
he affected users can add something like:
> >
> >export KRB5CCNAME=$HOME/my_cc_cache
> ^
> Is FILE: considered as default or it need to be
> written as well for KRB5CCNAME
If no ccache type is specified the krb5 libs default to the FILE ccache
type.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
te to the coexistence of FreeIPA and AD in a single DNS domain.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
take it
away.
Simo.
> --David Alston
>
> -Original Message-
> From: Simo Sorce [mailto:s...@redhat.com]
> Sent: Friday, July 22, 2016 10:49 AM
> To: Alston, David
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Replicating users/
th on RHEL6.8)
>
> Then please provide all objectclasses that have a random imported user
>
> regards
> Martin
>
>
> I apologize if this has already been answered, I tried google-fu and it
> didn't return anything useful.
> Using IPA 3.0 on Redhat 6.8
>
>
ipa-users
> Go to http://freeipa.org for more info on the project
You can have a Realm named COMPANY.COM (AD) and a Realm named
FREEIPA.COMPANY.COM (IPA), as long as the AD Servers never had computer
objects or subdomains in the DNS domain freeipa.company.com in it.
If that's the case you can creat
re by providing a GC service.
HTH,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
).
No you can't have this (if you want SSO and avoid headaches in general)
no matter what you do. You have to keep server names on separate
(sub)domains.
In some cases you can use CNAMEs though.
> Also, thanks for your other answers. They were very helpful :^)
You are welcome,
S
? Has anyone attempted not opening port
> 80 from IPA Server to IPA Server and clients to IPA server?
> ipa-server-3.0.0-50.el6.1.x86_64
Port 80 is not required, the only thing you'll find there is a redirect
to the HTTPS port.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage
On Thu, 2016-09-01 at 09:33 +1000, Peter Fern wrote:
> On 01/09/16 08:35, Simo Sorce wrote:
> > Port 80 is not required, the only thing you'll find there is a redirect
> > to the HTTPS port.
>
> What about CRL/OCSP (and possibly others)? The Apache configs
> explic
red valid.
> >> > Not a bad thing, IMO.
> >> >
> >> > All this said, I think there is a valid RFE in allowing Kerberos
> >> > principal aliases to be consulted when validating a CSR. This would
> >> > mean you do not have to create new objects, just add more principal
> >> > names to the existing one. I filed a ticket:
> >> >
> >> > https://fedorahosted.org/freeipa/ticket/6432
> >> >
> >> > Alexander, Simo, what do you think?
> >> Certainly principal aliases should be checked if they were asked to be
> >> in SAN. The question is what type of the SAN extension should be
> >> considered for them in addition to Kerberos principal. The aliases are
> >> stored in their full format (alias@REALM), so either you need to do full
> >> match or consider dropping the realm for some types. This needs to be
> >> clarified before any implementation happens.
> >>
> >Right, UPN and KR5PrincipalName can be checked as-is.
> >
> >We should check dnsNames by affixing around the dnsName the same
> >service type (e.g. `HTTP') and realm as the nominated principal, and
> >looking for that in the aliases. e.g. for nominated principal
> >`HTTP/web.example@example.com', if there is a SAN dnsName
> >`www.example.com', we look for `HTTP/www.example@example.com' in
> >its aliases.
> >
> >Does this sound reasonable?
> >
> >No other GeneralName types shall be checked against principal
> >aliases, unless/until we support SRVName.
> Sounds reasonable for me, thanks.
+1
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
h was a pretty complex product but
> gave the user lots of possible customizations of the web ui and
> included workflows. Is that possible with ipa also?
With the latest FreeIPA versions it is possible to write plugins to
extend the Web UI, we are working on making it more straightforward, b
t and not just give it blanket access to
read everything from the directory and write every password, you should
limit it to users for example and not allow it to change service's or
host's "passwords".
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscriptio
ond should "fix" them ...
unless you depended on the incorrect configuration in some way ...
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
r its own computer account I would
think of adding it to the local user database, if you have to distribute
it via LDAP you'll have to create actual user accounts ion the directory
I guess.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-us
istribute it to both server's http keytab so they can
decrypt incoming requests.
However your load balancer then also needs to stick with one server for
all requests coming from the same client, because we use session cookies
to maintain authentication and we do not share them between serv
-uninstall) and
then re-join after.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
pal: Server error while creating "WELLKNOWN/anonym...@pan-net.eu".
> kadmin.local:
Whether the principal has keys or not doesn't matter, pkinit
pre-authentication ignores the keys anyway.
> I've also tried all the above when the user's krb5.conf "realm&qu
in with Ipsilon and
> FreeIPA... Has anyone else tried this before? If so, are there any
> pitfalls or problems you have encountered or any general advise?
I think there are issues with the workflow Duo requires and the latency
(sending token via SMS and waiting for user to input).
Simo.
--
Simo
Enough people complained they cannot cope with the change I made
recently.
So I am reverting this change and will try to find a better solution for
the spam issue the list user's are subject to.
Thanks for your understanding,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage
Sorry David,
it is not clear to me what you are objecting to, please be more specific
or quote the specific part of my previous reply that you find
questionable.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat
This is an automated message to probe our subscribers email address, in order
to pinpoint the bot harvesting our emails.
Please disregard.
Freeipa-users list administrators.
Dear freeipa-users,
in an attempt to identify how the recent wave of spamming activity
targets mailing list posters, I have temporarily disabled free access to
the archives.
This is not a permanent change and public access will be restored
shortly.
Regards,
Simo.
--
Simo Sorce * Red Hat, Inc
On Mon, 2016-12-12 at 05:04 -0500, Simo Sorce wrote:
> Dear freeipa-users,
> in an attempt to identify how the recent wave of spamming activity
> targets mailing list posters, I have temporarily disabled free access to
> the archives.
> This is not a permanent change and public
e to a proper database backend in a separate 389-ds
> instance.
Yes it is definitely a bug, but not an easy fix, please do file a bug,
however it will take some time before we can fix it.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
e problem. Interestingly the LDAP
> server should use the ds.keytab file instead of krb5.keytab.
>
> We need someone from DS team of with deep Kerberos/gssproxy knowledge to look
> into it.
>
> Simo, Ludwig, how can this happen?
As Martin said, incorrect configuration of DS makes
ser you want to authenticate,
and none of that is set up by default.
We are planning to enable the integrated Samba server (which is used for
trusts only at the moment) to provide NTLM services for radius servers,
but it is not ready yet, although you may try to experiment with it.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Jessie with sssd 1.13.4.
>
>
> sssd.conf is attached, of course. Every helpful comment is highly
> appreciated.
>
> Harri
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http:
is still in development, so it may take a little while to
mature, but should be usable shortly.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
On Wed, 2014-04-09 at 15:20 +0200, Petr Spacek wrote:
> On 9.4.2014 15:15, Simo Sorce wrote:
> > On Wed, 2014-04-09 at 13:05 +, Ondrej Valousek wrote:
> >> Hi List,
> >> Quick question, is something like SAML 2.0 support planned for IPA to help
> >&
s would allow SSO, we could store a cookie
with the user's name from the Idp, so that if the user uses always the
same browser it may be automatically chained to its Idp of origin,
otherwise at least a username or password will have to be provided by
the user.
>
It is indeed a bit down the r
m is that keytab received by user has to be short-lived. For
> example, IdP could generate a new random password for user principal 1 minute
> after sending keytab to the user.
>
> This could work if the whole process should be automated.
http://www.umich.edu/~x509/
I already have a plan to implement this in Ipsilon eventually :-)
> Is seems that variant (B) should be really simple to code/script when we have
> SAML/OpenID capable IdP.
It can be done indeed.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
ns to push to enable the service.
I am not a Mac expert by a long shot so I cannot help you much here.
Is there any guide available on how to use this service with other LDAP
servers, like openLDAP or Active Directory ? We can probably draw some
conclusions from there.
Simo.
--
Simo Sorce * R
> security issues.
>
>
> Is it really necessary to have this option set to yes when using
> Keberos authentication?
No, GSSAPI authentication does not need PasswordAuthentication, of
course it requires valid kerberos credentials on the client and a valid
keytab on the server.
Sim
ssd on the system. Using
password based authentication via pam/sssd would allow sssd to cache
password hashes of the users and allow authentication even when the VPN
link fails and would be much more lightweight.
HTH,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
___
_bind_script/Mac_OpenLDAP_bind_script.sh,
> which gave me the idea of
> updating the RealName mapping to displayName. This solved the problem, I'll
> have to recreate the permissions for every share, but the user names now
> show up, and stick. No more UIDs.
>
>
> On Tu
host/...
> >
> > kvno -k /etc/krb5.keytab host/...
> > host/...: kvno = 1, keytab entry valid
> >
> > So the Kerberos setup on the machine seems to be fine, but still the
> > login SSH using Keberos is not working. GSSAPI is correctly enabled in
> > the sshd
rvice principal
> > 04/16/14 23:24:51 04/17/14 23:24:47 krbtgt/...
> > 04/16/14 23:25:51 04/17/14 23:24:47 host/...
> >
> > kvno -k /etc/krb5.keytab host/...
> > host/...: kvno = 1, keytab entry valid
> >
> > So the Kerberos setup on the machine seems to be fine, but still the
> > login SSH using Keberos is not working. GSSAPI is correctly enabled in
> > the sshd configuration file. Any hint is highly appreciated. Thanks.
> >
>
> Seems like sshd looked for the wrong key. Run klist -kt /etc/krb5.keytab
> and see what principal is there. sshd didn't look for a FQDN according
> to your log.
>
> rob
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
--
Simo Sorce * Red Hat, Inc * New York
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
?
> >>
> >
> > All you need to do is installing http://ipaserver/ipa/config/ca.crt .
>
> Brilliant! Thanks.
The FreeIPA certificate is also available on each freeipa client
in /etc/ipa/ca.crt, it is downloaded there securely so you know it is
101 - 200 of 896 matches
Mail list logo
