Re: [Freeipa-users] Using external KDC

2014-03-08 Thread Trey Dockendorf
I got a RHEL7-beta VM up and running with basic ipa install (no DNS and no NTP).

IPA is 3.3.3-5.el7
SSSD is 1.11.2-1.el7
krb5 is 1.11.3-31.el7

Based on the docs at http://www.freeipa.org/page/V3/OTP I attempted
the CLI commands under Feature Management, with no luck.

For example:

---
# ipa config-mod --user-auth-type=['password', 'otp', 'radius']
Usage: ipa [global-options] config-mod [options]

ipa: error: no such option: --user-auth-type
---

The ipa subcommands radiusproxy-* do not exist either.

What version of IPA should I use to test this proof of concept?  The
docs mention needing Kerberos no earlier than 1.12, which isn't
available in EL7.

My understanding of Kerberos is not great, but is FreeIPA simply not
designed for external Kerberos (like the use of an external CA)?  Is
there possibly a way to utilize FreeIPA without Kerberos, and just
manage 389DS while still using the web interface (hard to find good
Identity Management Web UI) and CLI tools?  I'd still like to get this
working in FreeIPA, but am working on upgrading our HPC cluster to EL6
(or EL7) and moving to FreeIPA would be a great improvement over 389DS
in terms of manageability.

Thanks
- Trey

On Fri, Mar 7, 2014 at 4:38 PM, Dmitri Pal d...@redhat.com wrote:
 On 03/07/2014 05:26 PM, Trey Dockendorf wrote:

 On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pald...@redhat.com  wrote:

 On 03/05/2014 06:24 PM, Trey Dockendorf wrote:

 Correction from my email, the condition that sets if a 389DS user is
 proxied to pam_krb5 is the pamFilter, sorry.

 On Wed, Mar 5, 2014 at 5:22 PM, Trey Dockendorftreyd...@gmail.com
 wrote:

 On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pald...@redhat.com   wrote:

 On 03/03/2014 07:47 PM, Simo Sorce wrote:

 On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:

 Is it possible with FreeIPA to use an external KDC or pass some or
 all
 authentication to an external KDC?  The KDC at our University may
 give
 me a one way trust if I describe my implementation plan for FreeIPA.
 Currently I use 389DS with PAM pass through using untrusted
 pam_krb5.
 I'd like to fully utilize FreeIPA without managing passwords since
 all
 my users already have University accounts.  I just want to manage
 authorization for my systems, not authentication.

 You could set up a kerberos trust manually but at the moment we do
 not
 support it in the code or the utilities.

 SSSD in particular will have no place to find identity information if
 all you have is a kerberos trust, you'd need also an external
 identity
 store to point to, but there is no builtin code in SSSD to link the 2
 domain at this point.

 We are planning on working on IPA-to-IPA trust, and possibly
 IPA-to-*other* so any requirements you can throw at us will be made
 part
 of the consideration and planning to add this kind of functionality
 in
 the future.

 NM B HTH,
 Simo.

 Can you describe your workflows because I have some idea in mind?

 Right now the workflow I have with 389ds using PAM Pass Through Auth
 is the following:

 For users with the proper attribute defined in 'pamIDAttr'

 client ---   389DS ---   389DS server's pam_krb5 ---   Campus KDC

 For users lacking the attribute for 'pamIDAttr'

 client ---   389DS

 The Kerberos setup currently on the 389DS server is untrusted (no
 krb5.keytab).

 The ideal workflow with FreeIPA would be

 client    IPA ---   Campus KDC

 Would you be OK if your accounts would be in IPA but the
 authentication
 would be proxied out?

 This is fine with me.  Does the idea you describe allow for some
 authentication (ie system accounts or internal accounts) to be handled
 by FreeIPA?  That's the benefit to us when using PAM Pass Through
 Auth, is that we can conditionally proxy out the authentication.

 The idea is that you can use OTP RADIUS capability to proxy passwords
 to
 your main KDC.

 client ---OTP---   IPA ---   OTP Proxy ---   RADIUS ---   Your KDC

 Disclaimer: that would defeat the purpose of Kerberos and the password
 will
 be sent over the wire but it seems that you are already in this setup.

 Would you be interested to give it a try?

 Absolutely.  Right now I need to contact our campus IT group and let
 them know what I require to make our setup work.  I have been told a
 one way trust is the most I can get.  Will that facilitate what you
 described?


 You do not need trust for that setup. Any user account (i am not sure
 about
 special system accounts that are not created in cn=users) would be able
 to
 go to external RADIUS server.


 Would require latest SSSD and kerberos library on the client though
 but
 would work with LDAP binds too.

 Latest SSSD and Kerberos that's available in EL6, or latest upstream?


 Upstream.

 Is it possible use these latest versions in EL6, or is using Fedora
 19+ the only feasible way to do this?  If using EL6 is not possible,
 is it going to be something possible in EL7?



 Latest RHEL7 beta snapshots might be a good starting point.
 This will not be a part

Re: [Freeipa-users] Using external KDC

2014-03-07 Thread Trey Dockendorf
On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal d...@redhat.com wrote:
 On 03/05/2014 06:24 PM, Trey Dockendorf wrote:

 Correction from my email, the condition that sets if a 389DS user is
 proxied to pam_krb5 is the pamFilter, sorry.

 On Wed, Mar 5, 2014 at 5:22 PM, Trey Dockendorftreyd...@gmail.com
 wrote:

 On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pald...@redhat.com  wrote:

 On 03/03/2014 07:47 PM, Simo Sorce wrote:

 On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:

 Is it possible with FreeIPA to use an external KDC or pass some or all
 authentication to an external KDC?  The KDC at our University may give
 me a one way trust if I describe my implementation plan for FreeIPA.
 Currently I use 389DS with PAM pass through using untrusted pam_krb5.
 I'd like to fully utilize FreeIPA without managing passwords since all
 my users already have University accounts.  I just want to manage
 authorization for my systems, not authentication.

 You could set up a kerberos trust manually but at the moment we do not
 support it in the code or the utilities.

 SSSD in particular will have no place to find identity information if
 all you have is a kerberos trust, you'd need also an external identity
 store to point to, but there is no builtin code in SSSD to link the 2
 domain at this point.

 We are planning on working on IPA-to-IPA trust, and possibly
 IPA-to-*other* so any requirements you can throw at us will be made
 part
 of the consideration and planning to add this kind of functionality in
 the future.

 NM B HTH,
 Simo.

 Can you describe your workflows because I have some idea in mind?

 Right now the workflow I have with 389ds using PAM Pass Through Auth
 is the following:

 For users with the proper attribute defined in 'pamIDAttr'

 client ---  389DS ---  389DS server's pam_krb5 ---  Campus KDC

 For users lacking the attribute for 'pamIDAttr'

 client ---  389DS

 The Kerberos setup currently on the 389DS server is untrusted (no
 krb5.keytab).

 The ideal workflow with FreeIPA would be

 client   IPA ---  Campus KDC

 Would you be OK if your accounts would be in IPA but the authentication
 would be proxied out?

 This is fine with me.  Does the idea you describe allow for some
 authentication (ie system accounts or internal accounts) to be handled
 by FreeIPA?  That's the benefit to us when using PAM Pass Through
 Auth, is that we can conditionally proxy out the authentication.

 The idea is that you can use OTP RADIUS capability to proxy passwords to
 your main KDC.

 client ---OTP---  IPA ---  OTP Proxy ---  RADIUS ---  Your KDC

 Disclaimer: that would defeat the purpose of Kerberos and the password
 will
 be sent over the wire but it seems that you are already in this setup.

 Would you be interested to give it a try?

 Absolutely.  Right now I need to contact our campus IT group and let
 them know what I require to make our setup work.  I have been told a
 one way trust is the most I can get.  Will that facilitate what you
 described?


 You do not need trust for that setup. Any user account (i am not sure about
 special system accounts that are not created in cn=users) would be able to
 go to external RADIUS server.



 Would require latest SSSD and kerberos library on the client though but
 would work with LDAP binds too.

 Latest SSSD and Kerberos that's available in EL6, or latest upstream?


 Upstream.


Is it possible use these latest versions in EL6, or is using Fedora
19+ the only feasible way to do this?  If using EL6 is not possible,
is it going to be something possible in EL7?

 Please take a look at the design page: http://www.freeipa.org/page/V3/OTP -
 that will give you an idea about the internals.

 Latest upstream UI should be able to allow to configure external RADIUS
 servers and then change per user policy to proxy via RADIUS. Then you can
 try binding with LDAP to IPA using password from your main KDC.
 Then you can use SSSD on the same system to try to authenticate using
 Kerberos. You will create a new user, set him to use RADIUS server for
 authentication and then try to su to this user or ssh into the box as that
 user. It should work and klist should report a TGT for this user on the box.


Thanks for the info.  I'll see if I can piece together how to make this work.




 --
 Thank you,
 Dmitri Pal

 Sr. Engineering Manager for IdM portfolio
 Red Hat Inc.


 ---
 Looking to carve out IT costs?
 www.redhat.com/carveoutcosts/



 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users



 --
 Thank you,
 Dmitri Pal

 Sr. Engineering Manager for IdM portfolio
 Red Hat Inc.


 ---
 Looking to carve out IT costs?
 www.redhat.com/carveoutcosts/



 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Using external KDC

2014-03-05 Thread Trey Dockendorf
Correction from my email, the condition that sets if a 389DS user is
proxied to pam_krb5 is the pamFilter, sorry.

On Wed, Mar 5, 2014 at 5:22 PM, Trey Dockendorf treyd...@gmail.com wrote:
 On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal d...@redhat.com wrote:
 On 03/03/2014 07:47 PM, Simo Sorce wrote:

 On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:

 Is it possible with FreeIPA to use an external KDC or pass some or all
 authentication to an external KDC?  The KDC at our University may give
 me a one way trust if I describe my implementation plan for FreeIPA.
 Currently I use 389DS with PAM pass through using untrusted pam_krb5.
 I'd like to fully utilize FreeIPA without managing passwords since all
 my users already have University accounts.  I just want to manage
 authorization for my systems, not authentication.

 You could set up a kerberos trust manually but at the moment we do not
 support it in the code or the utilities.

 SSSD in particular will have no place to find identity information if
 all you have is a kerberos trust, you'd need also an external identity
 store to point to, but there is no builtin code in SSSD to link the 2
 domain at this point.

 We are planning on working on IPA-to-IPA trust, and possibly
 IPA-to-*other* so any requirements you can throw at us will be made part
 of the consideration and planning to add this kind of functionality in
 the future.

 NM B HTH,
 Simo.

 Can you describe your workflows because I have some idea in mind?

 Right now the workflow I have with 389ds using PAM Pass Through Auth
 is the following:

 For users with the proper attribute defined in 'pamIDAttr'

 client --- 389DS --- 389DS server's pam_krb5 --- Campus KDC

 For users lacking the attribute for 'pamIDAttr'

 client --- 389DS

 The Kerberos setup currently on the 389DS server is untrusted (no 
 krb5.keytab).

 The ideal workflow with FreeIPA would be

 client  IPA --- Campus KDC

 Would you be OK if your accounts would be in IPA but the authentication
 would be proxied out?

 This is fine with me.  Does the idea you describe allow for some
 authentication (ie system accounts or internal accounts) to be handled
 by FreeIPA?  That's the benefit to us when using PAM Pass Through
 Auth, is that we can conditionally proxy out the authentication.


 The idea is that you can use OTP RADIUS capability to proxy passwords to
 your main KDC.

 client ---OTP--- IPA --- OTP Proxy --- RADIUS --- Your KDC

 Disclaimer: that would defeat the purpose of Kerberos and the password will
 be sent over the wire but it seems that you are already in this setup.

 Would you be interested to give it a try?

 Absolutely.  Right now I need to contact our campus IT group and let
 them know what I require to make our setup work.  I have been told a
 one way trust is the most I can get.  Will that facilitate what you
 described?

 Would require latest SSSD and kerberos library on the client though but
 would work with LDAP binds too.

 Latest SSSD and Kerberos that's available in EL6, or latest upstream?



 --
 Thank you,
 Dmitri Pal

 Sr. Engineering Manager for IdM portfolio
 Red Hat Inc.


 ---
 Looking to carve out IT costs?
 www.redhat.com/carveoutcosts/



 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] Using external KDC

2014-03-05 Thread Trey Dockendorf
On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal d...@redhat.com wrote:
 On 03/03/2014 07:47 PM, Simo Sorce wrote:

 On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:

 Is it possible with FreeIPA to use an external KDC or pass some or all
 authentication to an external KDC?  The KDC at our University may give
 me a one way trust if I describe my implementation plan for FreeIPA.
 Currently I use 389DS with PAM pass through using untrusted pam_krb5.
 I'd like to fully utilize FreeIPA without managing passwords since all
 my users already have University accounts.  I just want to manage
 authorization for my systems, not authentication.

 You could set up a kerberos trust manually but at the moment we do not
 support it in the code or the utilities.

 SSSD in particular will have no place to find identity information if
 all you have is a kerberos trust, you'd need also an external identity
 store to point to, but there is no builtin code in SSSD to link the 2
 domain at this point.

 We are planning on working on IPA-to-IPA trust, and possibly
 IPA-to-*other* so any requirements you can throw at us will be made part
 of the consideration and planning to add this kind of functionality in
 the future.

 NM B HTH,
 Simo.

 Can you describe your workflows because I have some idea in mind?

Right now the workflow I have with 389ds using PAM Pass Through Auth
is the following:

For users with the proper attribute defined in 'pamIDAttr'

client --- 389DS --- 389DS server's pam_krb5 --- Campus KDC

For users lacking the attribute for 'pamIDAttr'

client --- 389DS

The Kerberos setup currently on the 389DS server is untrusted (no krb5.keytab).

The ideal workflow with FreeIPA would be

client  IPA --- Campus KDC

 Would you be OK if your accounts would be in IPA but the authentication
 would be proxied out?

This is fine with me.  Does the idea you describe allow for some
authentication (ie system accounts or internal accounts) to be handled
by FreeIPA?  That's the benefit to us when using PAM Pass Through
Auth, is that we can conditionally proxy out the authentication.


 The idea is that you can use OTP RADIUS capability to proxy passwords to
 your main KDC.

 client ---OTP--- IPA --- OTP Proxy --- RADIUS --- Your KDC

 Disclaimer: that would defeat the purpose of Kerberos and the password will
 be sent over the wire but it seems that you are already in this setup.

 Would you be interested to give it a try?

Absolutely.  Right now I need to contact our campus IT group and let
them know what I require to make our setup work.  I have been told a
one way trust is the most I can get.  Will that facilitate what you
described?

 Would require latest SSSD and kerberos library on the client though but
 would work with LDAP binds too.

Latest SSSD and Kerberos that's available in EL6, or latest upstream?



 --
 Thank you,
 Dmitri Pal

 Sr. Engineering Manager for IdM portfolio
 Red Hat Inc.


 ---
 Looking to carve out IT costs?
 www.redhat.com/carveoutcosts/



 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


[Freeipa-users] Using external KDC

2014-03-03 Thread Trey Dockendorf
Is it possible with FreeIPA to use an external KDC or pass some or all
authentication to an external KDC?  The KDC at our University may give
me a one way trust if I describe my implementation plan for FreeIPA.
Currently I use 389DS with PAM pass through using untrusted pam_krb5.
I'd like to fully utilize FreeIPA without managing passwords since all
my users already have University accounts.  I just want to manage
authorization for my systems, not authentication.

Thanks
- Trey

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


Re: [Freeipa-users] IPA - initial questions

2013-05-10 Thread Trey Dockendorf
On May 10, 2013 1:33 PM, Herb Burnswell herbert.burnsw...@gmail.com
wrote:

 Rob,

 Thank you for your response.  One of my filters on gmail was blocking the
approval responses, I should have known it was user error ;-).  I'm all set
on the subscription.  Also, thanks for the tip on searching google that
way, I'll investigate questions that way.

 Regarding root user, that was what I was thinking.  So that kind of takes
away the ability to centrally manage the root password for 100's of systems
via IPA correct?  Or is there a way to do that?


The root user should be local to every host without access to root relying
on something external such as IPA or any other network service.  If IPA
goes down you still want to be able to gain access to servers.  To manage
root I'd recommend Puppet, or any configuration management tool if one
already exists in your infrastructure.  A single global 'user' resource or
'root module' (in the case of Puppet) can be assigned to every host
allowing a single, central, change to propagate to all hosts.

 thanks,

 Herb



 On Fri, May 10, 2013 at 11:22 AM, Rob Crittenden rcrit...@redhat.com
wrote:

 Herb Burnswell wrote:

 All,

 I am beginning to put an IPA environment together and will be inquiring
 with the community on different issues.

 First, regarding this list, I do not see a way to search archived posts
 for answers.  I apologize if I am just missing how to do so, is there a
 way to search for topics?


 There is no built-in search command but you can use google, something
like site:https://www.redhat.com/archives/freeipa-users/ search-terms


 Second, I have attempted to subscribe to the list a couple times but
 have not received any email notification and cannot log in via the
 credentials I created.  Am I missing something or am I just waiting for
 an approval from moderators or other?


 I don't see any failed subscription requests. I went ahead and
subscribed you.


 Regarding IPA, my initial question is how do folks handle the root
 user?  Is root maintained via IPA centrally or since it's a special
 account is it sill maintained directly on all systems?


 You always want to be able to log in locally as root if something goes
wrong. sssd purposely excludes the root users for this reason.

 If you want to limit root access then you'd be better of investigating
SUDO and limiting who knows the root password(s).

 rob




 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users

I also use Puppet to push out a non-root, local account, for emergency
situations as root on my servers is only accessible via SSH key
authentication or local console.  This gives my team a way to access
servers if key pieces of our infrastructure are down or in maintenance.

- Trey
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] New User - Possible to point authentication to external KDC

2013-03-01 Thread Trey Dockendorf
On Tue, Feb 26, 2013 at 1:18 PM, Dmitri Pal d...@redhat.com wrote:
 On 02/26/2013 01:31 AM, Trey Dockendorf wrote:


 On Feb 25, 2013 1:23 AM, Dmitri Pal d...@redhat.com wrote:

 On 02/23/2013 10:33 PM, Trey Dockendorf wrote:
  I just begun evaluating FreeIPA, after having successfully used 389ds
  for a few months.  The move from 389 ds to FreeIPA is to leverage the
  authorization for host logins and also for simpler management.  The
  University I am deploying at has a campus wide KDC and for security
  and audit reasons I prefer to point my authentication services at that
  Kerberos realm rather than storing passwords.  I have successfully
  implemented this using the 389 ds pam pass through authentication
  plug-in , but have not found any documentation on how to do this same
  thing with FreeIPA.
 
  The complication with doing this is I do not have even a 1 way trust
  with the KDC.  Getting a trust (even 1-way) is very difficult if not
  impossible, but so far I've been able to make PAM work with that
  situation both using local authentication and now 389 ds, both through
  PAM.  Is it possible to have FreeIPA query a remote KDC while still
  being able to fallback to the local password store (ie external users
  not in campus domain).

 IPA uses the 389 DS so it might be possible to configure PAM pass
 through but there might be implications because if users are not in IPA
 you would not get a ticket and since you cant get a ticket you can't use
 UI and CLI. You can still bind using LDAP though as you do with the 389.
 So to manage IPA you would still have to have a user in IPA. However you
 will have two KDCs and I do not know what implications there would be
 for the clients, they might be confused.
 Frankly you are better off with 389 now untill we make setting up trusts
 with other IPAs or MIT KDCs simple. We did that for AD but it requires a
 clean DNS setup. I suspect DNS setup will be an issue in any case.

 
  Thanks
  - Trey
 
  ___
  Freeipa-users mailing list
  Freeipa-users@redhat.com
  https://www.redhat.com/mailman/listinfo/freeipa-users


 --
 Thank you,
 Dmitri Pal

 Sr. Engineering Manager for IdM portfolio
 Red Hat Inc.


 ---
 Looking to carve out IT costs?
 www.redhat.com/carveoutcosts/



 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users

 Thanks for the response!  I do plan to have all my users in freeIPA.  My
 goal is to have my freeIPA install just attempt a password authentication
 against external KDC via pam on the IPA server before trying the local
 password store.  With my current 389 setup, clients are unaware of our
 campus KDC, the authentication is handled my 389 server and currently users
 in my LDAP who have campus accounts get their password verified via PAM and
 others in my LDAP use the local password stored in 389.

 The aspects of IPA aside from 389 are where my uncertainty lies.  For
 example, if I have LDAP authenticate against an external KDC via PAM, can
 the user still get a ticket from my IPA?

 Also getting a trust may not be possible even if freeipa makes the process
 easier.  This is a politics issue with our campus' main IT group and
 something I've worked around thus far.

 Is there anything in changes of the stock 389 that would prevent this from
 working in IPA?  Also is there a preferred method for enabling plugins in
 IPA?  Also how could I test this?  Would a client machine joined to my IPA
 install be the best method?

 Thanks
 - Trey

 If you hit IPA with a kerberos authentication to the best of my knowledge
 KDC will read the data from LDAP and use it for authentication. It would not
 do PAM proxy in this case. The pam proxy would be possible only for the LDAP
 binds so I am not sure whether things would work for you.

 I see that you try to augment the existing infrastructure but I am not sure
 I have a clear picture in my mind of the architecture you envision.
 Is there any chance that you can put together a diagram?

 --
 Thank you,
 Dmitri Pal

 Sr. Engineering Manager for IdM portfolio
 Red Hat Inc.


 ---
 Looking to carve out IT costs?
 www.redhat.com/carveoutcosts/



Is the pam proxy for LDAP binds you mentioned using the method
documented here,
http://directory.fedoraproject.org/wiki/Howto:PAM_Pass_Through ?  That
is what I have working currently with 389 by itself.

Do any diagrams exist of the existing infrastructure design for
FreeIPA?  I could augment an existing one to better illustrate my
intended usage.

A plain text example of what I do now , and wish to do with FreeIPA is
something like this...

Client login (SSH, or LDAP from web app, anything that queries
OpenLDAP) - config[1]
 |
 |
 |
\/
389 ds server - config[2]
|
|
\/
Queries external KDC through PAM from the 389 server
|
|
|Authenticate user locally

[Freeipa-users] New User - Possible to point authentication to external KDC

2013-02-23 Thread Trey Dockendorf
I just begun evaluating FreeIPA, after having successfully used 389ds
for a few months.  The move from 389 ds to FreeIPA is to leverage the
authorization for host logins and also for simpler management.  The
University I am deploying at has a campus wide KDC and for security
and audit reasons I prefer to point my authentication services at that
Kerberos realm rather than storing passwords.  I have successfully
implemented this using the 389 ds pam pass through authentication
plug-in , but have not found any documentation on how to do this same
thing with FreeIPA.

The complication with doing this is I do not have even a 1 way trust
with the KDC.  Getting a trust (even 1-way) is very difficult if not
impossible, but so far I've been able to make PAM work with that
situation both using local authentication and now 389 ds, both through
PAM.  Is it possible to have FreeIPA query a remote KDC while still
being able to fallback to the local password store (ie external users
not in campus domain).

Thanks
- Trey

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users