Re: [Freeipa-users] Announcing FreeIPA 4.4.2

[Coy Hile]

Will there be builds in a COPR for rhel/cents 7?


Sent via the Samsung GALAXY S® 5, an AT 4G LTE smartphone

 Original message 
From: Martin Kosek 
Date: 10/14/16  3:58 AM  (GMT-05:00)
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Announcing FreeIPA 4.4.2


On 10/13/2016 09:17 PM, Petr Vobornik wrote:

The FreeIPA team would like to announce FreeIPA 4.4.2 release!

It can be downloaded from http://www.freeipa.org/page/Downloads. Builds
for Fedora 24 will be available in the official COPR repository
.

This announcement is also available on
http://www.freeipa.org/page/Releases/4.4.2

Fedora 25 update:
https://bodhi.fedoraproject.org/updates/freeipa-4.4.2-1.fc25


Please note that the FreeIPA Public demo was also upgraded to the version
4.4.2, if you want to try it out!

Demo location: https://ipa.demo1.freeipa.org/ipa/ui/

The selected new features that may be best exhibited in the FreeIPA Web UI:

* Improved Topology Management:
  - IPA Server -> Topology -> Graph
  - https://ipa.demo1.freeipa.org/ipa/ui/#/p/topology-graph

* Added Overview of IPA server roles:
  - IPA Server -> Topology -> Server Roles
  - https://ipa.demo1.freeipa.org/ipa/ui/#/e/server_role/search
  - You can click on a role

  - You can also see roles of a server:
  -  
https://ipa.demo1.freeipa.org/ipa/ui/#/e/server/details/ipa.demo1.freeipa.org


* Added DNS Location Mechanism:
  - IPA Server -> Topology -> IPA Locations
  - You can add a location
  - In the location details, you can add the servers to it (you can only test
UI as changing a location of IPA server requires DNS server restart)

* Added support for Sub-CAs
  - Open Authentication -> Certificate Authorities
  - Add new CA Authority, with subject like "CN=Certificate
Authority,O=VPN,O=DEMO1.FREEIPA.ORG"
  - Set ACL for authority in "CA ACLs" so that Admin can use this CA
  - Generate new certificate:
 - Open for example a test Service
 - Click Options -> New Certificate
 - Follow the steps (and use the new Sub-CA). I typed these  
options to get

the CSR:
   - cd /tmp/
   - mkdir test
   - cd test/
   - certutil -N -d .
   - certutil -R -d . -a -g 2048 -s
'CN=ipa.demo1.freeipa.org,O=VPN,O=DEMO1.FREEIPA.ORG' -8  
'ipa.demo1.freeipa.org'

 - Paste the CSR blob to FreeIPA, it should pass
 - It will show that Issuer is "CN = Certificate Authority,O = VPN,O =
DEMO1.FREEIPA.ORG", i.e. our new Sub-CA

Enjoy!
Martin

--
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




--
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

[Freeipa-users] Question about ID views

[Coy Hile]

In looking at the ID Views functionality in FreeIPA, it looks like I can 
accomplish overrides (such as users’ shell in LDAP is /bin/bash, but on a 
certain subset of hosts, users get /some/restrictive/shell instead? (Use case 
#1: a bastion host or jump box where admins might want to validate that users 
are only attempting to access authorized internal destinations.)

However, it looks like one has to list each user individually?

Is it possible to do things like this?
*:/usr/bin/restricted_shell  <— override EVERY user en masse

some_ldap_group:::newGid:::  <—— Override *EVERYONE* in some_ldap_group en masse

ldap_group_2:::newGid::/somepath/home/%s:/usr/bin/restricted_shell
<—— Override members of ldap_group_2 overriding each individual user’s home 
directory as well from, e.g. , /home/jdoe -> /somepath/home/jdoe



--
Coy Hile
coy.h...@coyhile.com


-- 
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

Re: [Freeipa-users] How does one authenticate Windows login against IPA

[Coy Hile]

Right, you have some process that creates the shadow accounts with a random, 
unknown, unused pass. This assumes you have some workflow for provisioning 
rather than doing ad hoc ipa user add as a human.

Sent from my iPad

> On May 18, 2016, at 23:20, John Meyers  wrote:
> 
> Even if you get that to work, you are still stuck with same issue
> discussed earlier in this thread -- you need to have a Windows account,
> either local or AD, to be able to login and grant rights against.  pGina
> just handles the authentication part.  The only way to do either a 1-way
> Kerberos trust (AD->IPA) or pGina is to somehow sync native IPA users to
> AD (or Samba AD) to create the "shadow account"?  Winsync will not do this.
> 
> 
> 
>> On 5/18/16 7:49 PM, Michael ORourke wrote:
>> What about using the pGina project on the Windows side?
>> 
>> Reference:
>> http://blog.zwiegnet.com/linux-server/configure-pgina-windows-7-openldap-authentication/
>> 
>> -Mike
>> 
>> -Original Message-
>>> From: John Meyers 
>>> Sent: May 18, 2016 5:19 PM
>>> To: freeipa-users@redhat.com
>>> Subject: [Freeipa-users] How does one authenticate Windows login against IPA
>>> 
>>> All,
>>> 
>>> FreeIPA as we've discovered has some wonderful Windows integration
>>> capability, but it is all predicated on Windows AD being the
>>> authoritative source of user information.  2-Way trusts are great, but
>>> they only work for kerberotized applications, not native Windows rights
>>> (that would require FreeIPA to act as global catalog as I learned from
>>> Alexander).  The winsync capability does not, as it turns out, sync
>>> native IPA users to AD.
>>> 
>>> The million dollar question is if you are 90% Linux shop and FreeIPA is
>>> your authoritative user repository (AD is a blank slate), how do you
>>> perform local Windows login authentication for the 10% of Windows
>>> machines against FreeIPA?
>>> 
>>> Thank you all!
>>> 
>>> John
>>> 
>>> 
>>> -- 
>>> 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
> 
> 
> 
> -- 
> 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

-- 
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

Re: [Freeipa-users] How does one authenticate Windows login against IPA

[Coy Hile]

When I've done this in the past, I used mit directly, not IPA. I set up a one 
way trust, then used "shadow objects" for users mapped using 
alternateSecurityID. I've setup the same one way trust testing with freeipa, 
but unfortunately I had to use kadmin.local to do it. I don't know that that's 
actually supported. Simo?

-c

Sent from my iPad

> On May 18, 2016, at 17:19, John Meyers  wrote:
> 
> All,
> 
> FreeIPA as we've discovered has some wonderful Windows integration
> capability, but it is all predicated on Windows AD being the
> authoritative source of user information.  2-Way trusts are great, but
> they only work for kerberotized applications, not native Windows rights
> (that would require FreeIPA to act as global catalog as I learned from
> Alexander).  The winsync capability does not, as it turns out, sync
> native IPA users to AD.
> 
> The million dollar question is if you are 90% Linux shop and FreeIPA is
> your authoritative user repository (AD is a blank slate), how do you
> perform local Windows login authentication for the 10% of Windows
> machines against FreeIPA?
> 
> Thank you all!
> 
> John
> 
> 
> -- 
> 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

-- 
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

Re: [Freeipa-users] IPA-AD Login

[Coy Hile]

> On Feb 7, 2016, at 2:05 PM, Alexander Bokovoy <aboko...@redhat.com> wrote:
> 
> On Thu, 04 Feb 2016, Alan P wrote:
>> Hi,
>> 
>> I just configured a trust between an IPA and an Active Directory to
>> authenticate IPA users in Windows machines joined in AD domain. The
>> login is successfull, but only after several minutes (nearly 25
>> minutes) in the first attempt; in the next attempts, the required time
>> goes from 5 to 10 min. So, what can I do to reduce the time to
>> something more acceptable? (For reference, when an AD user
>> authenticates it only takes 10 seconds or less).
> Alan, this is not yet supported for multiple reasons. We just have
> worked on this with Michael Brown at DevConf.cz over this weekend and
> while we have had certain progress, it requires heavily patching several
> key components, including CyrusSASL library, 389-ds and FreeIPA. Worse
> to that, we need to write Global Catalog service support in FreeIPA to
> allow Windows machines to actually assign proper rights to IPA users.
> 

Wouldn’t a somewhat easier solution for dealing with Windows be to create a 
one-way trust so that the AD domain trusts the IPA realm?  Then use 
AltSecurityID in Windows land to map a “shadow” user to each real principal?  
In that way AD gets relegated to a second-class citizen used only for the 
subset of (likely comparatively unimportant) tasks where one is forced to use 
Windows?

--
Coy Hile
coy.h...@coyhile.com


-- 
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

Re: [Freeipa-users] Client enrolment user

[Coy Hile]

Is there documentation thst states explicitly which permissions are  
granted to the Various built in roles?



Sent via the Samsung GALAXY S® 5, an AT 4G LTE smartphone

 Original message 
From: Rob Crittenden 
Date: 11/05/2015  10:18  (GMT-05:00)
To: Freeipa-users@redhat.com, andrew.hol...@gmail.com
Subject: Re: [Freeipa-users] Client enrolment user


Andrew Holway wrote:

Some time ago I saw an article on how to set up a user that can only
enrol clients into freeipa.

Does anyone have information on how to do this because we're currently
using the admin user and this is a bit scary.


Create a role for enrolling hosts and add the privilege 'Host
Enrollment' to it.

Note that 'Host Enrollment' is VERY specific. It only enrolls host. It
will not create host entries. If you want to be able to do that as well
then you'll need the 'Add Hosts' permission. I guess I'd create a new
privilege and add that permission, then add that privilege to the role
you create.

Some folks add the existing 'Host Administrators' privilege instead but
IMHO that is a bit broad.

rob

--
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




--
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

Re: [Freeipa-users] How to handle users with multiple homedirs on different machines?

[Coy Hile]

For solaris, just use the standard automounter config in auto_home:
*  /export/home/


Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone

 Original message 
From: Lukas Slebodnik lsleb...@redhat.com
Date: 06/03/2015  02:29  (GMT-05:00)
To: netv...@gmail.com
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] How to handle users with multiple  
homedirs on different machines?



On (02/06/15 17:07), swartz wrote:

I have a environment that spans across multiple physical locations where
there is a mix of Linux and Solaris workstations/servers. So far we've been
managing accounts (/etc/password) via Puppet.

Problem: FreeIPA allows to store only one homedir path.
Q: Is there a way to store/set a different home path based on the system
that the user is logged into?


sssd configuration is quite flexible in this way.
You can override homedir with configuration option
man sssd.conf - override_homedir

However sssd is available just on linux (or FreeBSD)
I'm not sure which clients do you use on Solaris or other
old system, maybe there is a way how to override homedir as well.
Or you can configure home directory attribute to the non-existing
attribute in FreeIPA and use some fallback (if possible)


As an example, I have user Bob.
On a Linux box Bob has homedir at /home/b/bob

 ^
Unfortunatelly, there's no way how to say
sssd to use just first letter from name.

On a Solaris this is likely /export/home/bob
While on some other odd system it could be /mnt/nas/users/bob

Different prefix for homedir /export/home, /home, /mnt/nas/users
could be addresed with the option homedir_substring in sssd conf.
https://fedorahosted.org/sssd/ticket/1853

So you could store %H in ldap attribute,
but clients need to understand such value.
(sssd = 1.11.6). I'm not sure about other clients.

LS

--
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




--
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

Re: [Freeipa-users] How to handle users with multiple homedirs on different machines?

[Coy Hile]

They are, but a correct automounter config will allow you to keep the  
attribute as /home/jdoe notwithstanding the OS.



Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone

 Original message 
From: Lukas Slebodnik lsleb...@redhat.com
Date: 06/03/2015  11:32  (GMT-05:00)
To: coy.h...@coyhile.com
Cc: freeipa-users@redhat.com, netv...@gmail.com
Subject: Re: [Freeipa-users] How to handle users with multiple  
homedirs on different machines?



On (03/06/15 12:54), Coy Hile wrote:



For solaris, just use the standard automounter config in auto_home:
*  /export/home/

I thought that automount and getent passwd user
are two different thigs on Solaris (the same as on Linux)

LS




--
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

[Freeipa-users] ID Ranges in FreeIPA

[Coy Hile]

Hi all,

When I installed FreeIPA, it created a default ID range (of which user admin
is currently the only user existing).  Through the UI, I've found that one can
create additional ranges (and that the ipa tools will complain if a user has a
uid assigned manually that falls outside the defined range.)  That  
makes sense.
Is there a way that one can instruct the tools which particular range  
it should
use for a particular operation?  Say one wants different classes of  
users to be
allocated from different ranges (For example, faculty/staff vs  
students, FTE vs
contractors, or 'eyeball' users vs role accounts like jdoe vs  
appteambuildbot)?


Thanks,

-c
--
Coy Hile
coy.h...@coyhile.com

--
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

Re: [Freeipa-users] Creating arbitrary users?

[coy . hile]

Quoting Simo Sorce s...@redhat.com


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 administratively one knows
are the same set of eyeballs).  For example, I might have my normal
user (hile), and I might have another distinct MIT principal
hile/admin used when I’m doing administrative work in the kerb
database, or potentially yet another hile/vpn for remote access.  Only
the first of these is a ‘real’ user that needs to have a uid, gid,
home directory, and shell; the others are just Kerberos principals
that might have differing password policies applied to them.  In
FreeIPA, it appears all kerberos principals are tied to a user (or to
a host in the case of host/ or another service definition). Is it
possible to define a non-posix user?  There is no good reason for
hile/admin@MY.REALM to have a uidNumber or gidNumber; one should never
login directly using that principal.


Early on when we created FreeIPA we decided against providing
alternative principals for the same user as it made things a lot more
complex for little gain. To this day we still do not support them.

Keep in mind that adding a principal is not the whole story, once you do
that  then you probably still want to associate it to some user, and
assign privileges and allow alternative principal names to ssh into some
machines, which means distributing k5login files 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, Inc * New York


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  
*/admin, I would expect that user to login to the ipa ui or to be  
kinit'd to prior to running ipa administrative commands, but I should  
hope that it should never login directly. 


Does that question make more sense? 


Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone


 Original message 
From: Simo Sorce s...@redhat.com
Date:04/07/2015  08:52  (GMT-05:00)
To: coy.h...@coyhile.com
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Creating arbitrary users?



--
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

Re: [Freeipa-users] Creating arbitrary users?

[Coy Hile]

Quoting Simo Sorce s...@redhat.com:




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
*/admin, I would expect that user to login to the ipa ui or to be
kinit'd to prior to running ipa administrative commands, but I should
hope that it should never login directly.

Does that question make more sense?


It does, but we do not have such a feature, sorry.

Simo.



Could one hypothetically remove the posix attributes (via some scripted
process that validates that what it's doing is inline with organizational
norms/goals) without breaking freeIPA, or are the posix attributes MUST in
the IPA object classes?   I'm sorry for so many endless questions, but having
finally got my personal setup/lab using something other than Active Directory,
I'm looking to migrate to something that is easier to manage, so I'm trying to
draw comparisons between what I had been used to in previous vanilla krb/ldap
shops.

Thanks,
-c

--
Coy Hile
coy.h...@coyhile.com

--
Coy Hile
coy.h...@coyhile.com

--
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

Re: [Freeipa-users] Creating arbitrary users?

[Coy Hile]

 On Apr 7, 2015, at 2:58 PM, Simo Sorce s...@redhat.com wrote:
 
 On Tue, 2015-04-07 at 18:54 +, Coy Hile wrote:
 Quoting Simo Sorce s...@redhat.com:
 
 
 
 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
 */admin, I would expect that user to login to the ipa ui or to be
 kinit'd to prior to running ipa administrative commands, but I should
 hope that it should never login directly.
 
 Does that question make more sense?
 
 It does, but we do not have such a feature, sorry.
 
 Simo.
 
 
 Could one hypothetically remove the posix attributes (via some scripted
 process that validates that what it's doing is inline with organizational
 norms/goals) without breaking freeIPA, or are the posix attributes MUST in
 the IPA object classes?   I'm sorry for so many endless questions, but having
 finally got my personal setup/lab using something other than Active 
 Directory,
 I'm looking to migrate to something that is easier to manage, so I'm trying 
 to
 draw comparisons between what I had been used to in previous vanilla krb/ldap
 shops.
 
 Removing attributes will probably not work well, but let me ask:
 Do you require different passwords for these principals ?
 Or do you merely want to have the alternative names but would be ok if
 the credentials were identical ?
 
 Because you could (manually for now) add aliases so that hile@
 hile/admin@ hile/foo@ are the same thing, where hile@ is the canonical
 name but you can use aliases too (just make sure not to request
 canonicalization at kinit time.
 

My intent was that they have different passwords (and perhaps differing 
password policies.) For example, a /admin principal might enforce password 
expiry with a shorter lifespan than a normal principal, or might have a shorter 
maximum ticket lifetime before kinit -R is necessary.  It’s merely convenient 
that these other instances not necessarily be posix accounts to enforce there’s 
no possible way that, for example, someone logs in and is running a full GNOME 
session as an admin.  But I can live with them being posix accounts since it’s 
baked in.

We’ve all heard the horror stories of the Microsoft shops where some genius 
decided to login to his workstation with his juser_domainadmin account, or 
worse Administrator….



--
Coy Hile
coy.h...@coyhile.com


-- 
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

[Freeipa-users] Creating arbitrary users?

[Coy Hile]

In MIT land, one can potentially have multiple instances tied (by convention) 
to a given user (that is, that administratively one knows are the same set of 
eyeballs).  For example, I might have my normal user (hile), and I might have 
another distinct MIT principal hile/admin used when I’m doing administrative 
work in the kerb database, or potentially yet another hile/vpn for remote 
access.  Only the first of these is a ‘real’ user that needs to have a uid, 
gid, home directory, and shell; the others are just Kerberos principals that 
might have differing password policies applied to them.  In FreeIPA, it appears 
all kerberos principals are tied to a user (or to a host in the case of host/ 
or another service definition). Is it possible to define a non-posix user?  
There is no good reason for hile/admin@MY.REALM to have a uidNumber or 
gidNumber; one should never login directly using that principal.


 
--
Coy Hile
coy.h...@coyhile.com


-- 
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

[Freeipa-users] Question on freeipa-server-trust-ad

[Coy Hile]

Hi all,

What purpose does this package serve?  The way I’ve done Kerberos between 
Active Directory and AD, the trust was always one way (outgoing): the MIT realm 
is authoritative and AD “shadow accounts” were mapped to ‘real’ principals via 
the alternateSecurityID attribute.  Looking at what freeipa-server-trust-ad 
installs, it appears the dependencies installed are around letting someone a 
bidirectional trust (or at least let the AD users be authoritative).  If one 
wants to setup his trust in the way I described, all he really needs to do in 
MIT land is create 

krbtgt/AD.REALM@MIT.REALM

in the MIT Realm.  

Is there a ‘supported’ way to do something similar with FreeIPA? Time to break 
out kadmin.local -x ipa-setup-override-restrictions? Or would that not drop the 
principal in the right place in the LDAP tree?



--
Coy Hile
coy.h...@coyhile.com


-- 
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

Re: [Freeipa-users] Is systemd really a requirement for freeipa 4.x?

[Coy Hile]

Quoting Andrew Holway andrew.hol...@gmail.com:



When I look at the SPEC file for freeipa-4.1.3, I see requirements

around Systemd.  Is that really a hard requirement, or is it possible to
run newer FreeIPA (that is to say 4.x) on a host that hasn't been
infested by systemd




From an SELinux standpoint systemd is far superior to initd as it allows

far more graceful domain transitions.

Apart from the binary logging and it being a bit monolithic; I really don't
understand the anit-systemd crowd problems. Its advantages over the now
ancient initd seem to be obvious.


hijack
The binary logging is a big problem. Log to the filesystem usefully, or log to
syslog. Then one can get that data into Splunk or similar.  Aside from that,
systemd feels like the answer to the question no one asked.  It's a bit like
what Oracle has done to bastardize smf(5) in Oracle Solaris 11 over what was
there in Solaris 10 (and the former OpenSolaris, now illumos).  The S10
incarnation was awesome, even though the definition of service  
manifests in xml

makes me want to claw my eyes out. Oracle's Microsoftened embrace and extend?
Yeah, not so much

For full disclosure here, the reason I was enquiring about support on  
CentOS 6 is
because my virtualization platform of choice is SmartOS.  For CentOS 6  
and Ubuntu
14.04, I am able to use a 'Branded zone' natively without having to  
add the KVM

hardware emulation layer in there, implying better network and IO performance.
That said, for this particular case, the KVM overhead really doesn't  
matter since
a box that's only doing LDAP and kerb really needn't be all that  
beefy.  Hell, I
could probably run an authoritative KDC for ATHENA.MIT.EDU on an rpi  
if I were so

inclined.
/hijack

Understanding the reason behind the requirements is quite helpful, so  
thanks to all
who provided that.  I'll work with Joyent to add systemd support to  
the lx brand,
and in the meantime, I'll just deploy on KVM infrastructure and take  
the hit.  I

assume there's no good reason to deploy a net new setup using the 3.x release?

-c
--
Coy Hile
coy.h...@coyhile.com

--
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

[Freeipa-users] Is systemd really a requirement for freeipa 4.x?

[Coy Hile]

When I look at the SPEC file for freeipa-4.1.3, I see requirements  
around Systemd.  Is that really a hard requirement, or is it possible  
to run newer FreeIPA (that is to say 4.x) on a host that hasn't been  
infested by systemd (such as CentOS 6, for example)?  At the moment,  
I'm speaking completely of the server components.


thanks,
-c

--
Coy Hile
coy.h...@coyhile.com

--
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

[Freeipa-users] FreeIPA interoperability with an existing kerberos realm?

[Coy Hile]

Hi all,

I’ve got an existing (Heimdal) kerberos realm that I am potentially interested 
in replacing with FreeIPA.  I know that recent MIT krb5 can read a Heimdal 
dump. Is there a supported (or even unsupported but it works is fine) way to 
pre-seed the kerb realm before running the IPA setup in the quick start?  I’ve 
got a handful of services (most notably OpenAFS and a trust to an existing 
Windows Domain) that I should prefer not to have to rekey if I can avoid it.  
If I can simply load the existing dump, then let FreeIPA create what it needs, 
that should make my life easier.

Thanks,

--
Coy Hile
coy.h...@coyhile.com


-- 
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