Re: [Freeipa-users] Freeipa on ARM (raspberry pi) - OpenJDK vs. Oracle JDK

[Nordgren, Bryce L -FS]

My guess aligns with this response:  
http://stackoverflow.com/questions/31153584/why-is-there-such-a-performance-difference-on-raspberry-pi-between-open-and-orac

Bryce

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Winfried de Heiden
Sent: Thursday, December 01, 2016 1:08 AM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] Freeipa on ARM (raspberry pi) - OpenJDK vs. Oracle JDK

Hi all,

Started as "just because it's possible" running FreeIPA on a BananaPI or 
Raspberry PI turned to out to be rather succesfull and for more than a year I 
use FreeIPA at home.

OK, running on small boards like Raspberry PI it never will be fast but it's 
surely quick enough to run at small scale. However, starting FreeIPA became 
much slower since Fedora 24 and even more on Fedora 25.
Since Oracle Java is also available for ARM and there's much written this is 
much faster I took some time for an experiment.

Starting FreeIPA using the default installation (running OpenJDK) starting 
FreeIPA takes a painfull 15 minutes (afterward, it all just works fine):

[root@rpi2 sysconfig]# time ipactl start
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting ipa_memcached Service
Starting httpd Service
Starting ipa-custodia Service
Starting ntpd Service
Starting pki-tomcatd Service
Starting ipa-otpd Service
Starting ipa-dnskeysyncd Service
ipa: INFO: The ipactl command was successful

real15m40.638s
user0m33.095s
sys0m1.910s

Now, after installing Oracle Java and changing JAVA_HOME in 
/etc/sysconfig/pki-tomcat to:

#JAVA_HOME="/usr/lib/jvm/jre-1.8.0-openjdk"
JAVA_HOME="/opt/jdk1.8.0_111/jre"

[root@rpi2 sysconfig]# time ipactl start
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting ipa_memcached Service
Starting httpd Service
Starting ipa-custodia Service
Starting ntpd Service
Starting pki-tomcatd Service
Starting ipa-otpd Service
Starting ipa-dnskeysyncd Service
ipa: INFO: The ipactl command was successful

real2m14.823s
user0m33.400s
sys0m1.730s

Wow, I expected some improvement, but this far better than expected! This 
leaves a question: what is happening here!!??

I prefer to use OpenJDK, it 's Open Source and because it's availabe from the 
Fedora ARM repositories it is also much more easy to update. But for now, 
Oracle is much faster and OpenJDK from this point of view is a very poor 
alternative.
Why is OpenJDK so much slower? Is improvement possible? For now (some 
"tweaking") of in a future release?

For the record, I tested these Java versions:

[root@rpi2 sysconfig]# 
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-3.b16.fc25.arm/jre/bin/java -version
openjdk version "1.8.0_111"
OpenJDK Runtime Environment (build 1.8.0_111-b16)
OpenJDK Zero VM (build 25.111-b16, interpreted mode)

[root@rpi2 sysconfig]# /opt/jdk1.8.0_111/jre/bin/java -version
java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) Client VM (build 25.111-b14, mixed mode)


Kind regards,

Winfried




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
-- 
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] Actions for a stolen/compromised IPA Client

[Nordgren, Bryce L -FS]

Ummm,

Kinit should work from any host, whether that host is part of the domain or 
not. It contains no inherent knowledge of any passwords. If it succeeds, then 
you either picked a bad password, stored the password in a plaintext file, or 
an actual authorized user ran it. It seems that it would make more sense to 
fret about how to somehow revoke any TGTs already issued to that machine.

Kinit authenticates the person running it, not the host it is running from. In 
your example, it successfully authenticated you because you know your admin 
password. If an attacker knows your admin password, focusing on your one 
compromised host is _not_ where you should be spending your energies.

Bryce



-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Paessens, Daniel
Sent: Wednesday, November 16, 2016 2:58 AM
To: Martin Babinsky ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Actions for a stolen/compromised IPA Client

Indeed the kinit keeps working correctly.
If you give a good password it retrieves the tokens correctly.
Thus it's not only DOS, but also an potentional brutal password retriever as 
well.
Blocking on firewall level,ok, but what if you use DHCP. It's more difficult to 
protect it, through that way.

Daniel

-Original Message-
From: Martin Babinsky [mailto:mbabi...@redhat.com]
Sent: Wednesday, November 16, 2016 10:30 AM
To: Paessens, Daniel ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Actions for a stolen/compromised IPA Client

On 11/16/2016 10:04 AM, Paessens, Daniel wrote:
> Currently am I looking for a workable solution for the following situation:
> Let's say that an ipa client has been stolen (or compromised).
> What can we do to block all access from it, towards IPA (and rest)
> For example if we use the command "ipa host-disable" it's noticed
> that IPA users are no longer able to login into the system. But if you
> log into the system as root. Then you can still run (successfully) the
> command kinit, and optain a ticket for it.
> Even if you delete the host from the directory, the behavior
> remains the same.
> Can this anyhow be blocked.
> Regards,
> Daniel
>
>
>

Hi Daniel,

host-disable removes the host kerberos keys and certificates from LDAP as you 
correctly observer. This means that all services on the compromised host stop 
working. SSSD will also stop working since it uses the now invalid host keytab 
to perform user lookup, that's why ssh'ing to host as IPA user stops working.

However, there is nothing preventing the attacker to try to kinit as admin 
directly without sssd on the machine, which can potentialy lead to DoS attack 
on the admin user. So if you realize that the host was compromised it is best 
to first run hist-disable and then block all traffic from that host on ports 88 
tcp/udp (Kerberos), 464 tcp/udp (kadmin), 749 tcp/udp (kpasswd IIRC) and 
LDAP(S) ports (389, 636 tcp).

--
Martin^3 Babinsky

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




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

-- 
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/authentication inside a docker container

[Nordgren, Bryce L -FS]

An RHEL 7 host filesystem may have the same basic structure as an Ubuntu trusty 
container filesystem, but may have different users defined, particularly for 
running services and for owning the files those services must touch. To what 
extent do you want the same users to be enforced between the container and the 
host? Is it OK for service accounts to be different, as long as 
user/login/people accounts are the same?

It almost sounds like you’re using containers to isolate user environments and 
processes, but you’re accumulating data from/sharing data between 
containers…Which implies that the processes generating the data run as the user 
and not as a system service. It may be easier to wrap whatever program you’re 
running as a web service so the users don’t have to log in and your uid:gid 
problem goes away.

Bryce

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Prasun Gera
Sent: Thursday, February 04, 2016 8:19 AM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] client/authentication inside a docker container

I am trying to set up a docker image with a specific development environment. 
We use idm 4.2 for authentication, and non-kerberized nfs (including home) for 
data storage on the hosts. The goal is to run the docker container such that 
when the user calls docker run, it just drops into a shell with the container's 
environment, but everything else looks largely the same. i.e. The user gets the 
same uid:gid and sees the same directories and permissions as the host. I'm 
trying to figure out what the best way of mapping user ids is. I've looked at 
the following options:

  *   ipa-client-install inside the container. This has a few problems. One is 
hostname and DNS. Container needs an fqdn for this to work, and the dns has to 
resolve this hostname. We are not using IPA's DNS. So this whole approach looks 
very kludgy. Besides, I'm not sure what the right way of handling these 
ephemeral host names is. Ideally, they should be un-enrolled when the container 
is destroyed,
  *   Use ipa's fake NIS. This works, and is very simple to setup, but I think 
we want to phase out NIS. If we start using it inside docker, it will never die
  *   Don't do any domain authentication. Just ask the user to create a user 
with the same uid:gid as the host so that they can r/w to their own directories.
The ipa version is 4.2 running on RHEL 7. The container image will be based on 
ubuntu trusty. Hosts are a mix of different OSes.
-- 
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] user account without password

[Nordgren, Bryce L -FS]

Hi Alex, 

Just because I gave up doesn't mean there isn't a way. Does your partitioning 
of local/domain users allow a domain user to run a service on a machine? I was 
trying to run an iPython notebook server as my regular user/domain account via 
systemd. Much of the data that the service needed access to resided on a 
multi-Terabyte NFS share, hence the desire to make it work with my domain 
account. IIRC, systemd was the thing choking on the domain user. 

Do you just manually create a local user with the same attributes as the domain 
user? (and in the case of the above use NFS with sec=host)? 

Thanks,
Bryce

 -Original Message-
 From: Alexander Frolushkin [mailto:alexander.frolush...@megafon.ru]
 Sent: Sunday, April 12, 2015 9:27 PM
 To: Nordgren, Bryce L -FS; 'Martin Kosek'; freeipa-users@redhat.com
 Subject: RE: [Freeipa-users] user account without password
 
 -Original Message-
 From: Nordgren, Bryce L -FS [mailto:bnordg...@fs.fed.us]
 Sent: Friday, April 10, 2015 9:27 PM
 To: Alexander Frolushkin (SIB); 'Martin Kosek'; freeipa-users@redhat.com
 Subject: RE: [Freeipa-users] user account without password
 
  Also, if such account will also exist locally (my case), it will not
  be controlled by HBAC rules - it can be a some kind of security trap...
 
 Pretty sure accounts should be either local or domain-wide, but not both.
 Could lead to strange and unforeseen side effects. Last I checked, only local
 accounts can run services. It may be advantageous to allow local accounts
 (which can run services) to have a representation in the domain, but the local
 accounts need to be scoped to the local machine (e.g., apache on server 1
 is different than apache on server 2). At least that way, they could belong
 to the same groups domain accounts belong to. SSO certainly shouldn't work.
 Any access to shared storage should distinguish between same-named
 accounts on different machines.
 
 Alternatively, allowing domain accounts to run certain services also
 has some merit. (assuming the user has permissions to do so.)
 
 Just thinking into email.
 Bryce
 
 I have a long and positive experience using both local and IPA users with the
 same attributes, but without HBAC and without sudo way to obtain shell of
 such users.
 Default settings in nsswitch.conf and pam provides straight and clear systems
 behavior, for about three years.
 But I agree there can be case when such construction may lead to
 misbehavior and so on. We will try to avoid them.
 SSO not really the aim for us, we just need to made a environment where
 users must remember only one password to access all resources on
 unix/linux servers.
 
 Not trying to argue, just sharing some thoughts :) Alexander
 
 
 
 Информация в этом сообщении предназначена исключительно для
 конкретных лиц, которым она адресована. В сообщении может
 содержаться конфиденциальная информация, которая не может быть
 раскрыта или использована кем-либо, кроме адресатов. Если вы не
 адресат этого сообщения, то использование, переадресация,
 копирование или распространение содержания сообщения или его
 части незаконно и запрещено. Если Вы получили это сообщение
 ошибочно, пожалуйста, незамедлительно сообщите отправителю об
 этом и удалите со всем содержимым само сообщение и любые
 возможные его копии и приложения.
 
 The information contained in this communication is intended solely for the
 use of the individual or entity to whom it is addressed and others authorized
 to receive it. It may contain confidential or legally privileged information. 
 The
 contents may not be disclosed or used by anyone other than the addressee.
 If you are not the intended recipient(s), any use, disclosure, copying,
 distribution or any action taken or omitted to be taken in reliance on it is
 prohibited and may be unlawful. If you have received this communication in
 error please notify us immediately by responding to this email and then
 delete the e-mail and all attachments and any copies thereof.
 
 (c)20mf50

-- 
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] Enrolling with multiple IPA servers

[Nordgren, Bryce L -FS]

 The hostname put by ipa-client-install corresponds to the server to which this
 client is enrolled.  You enroll with a single server, after all.

How would one enroll with multiple IPA servers? For instance, a standard 
configuration for a Rocks HPC cluster is to have at least two and usually three 
networks active, with different DNS zones for each. The public network is 
company.example.com, private is typically an isolated GbE network named 
local, and there's usually a fast network for real work (Infiniband or 
10GbE); let's name it ipoib for IP over Infiniband. There may also be a slow 
100bT network for management.

A few machines have access to all three networks (headnode.company.example.com, 
headnode.local, and headnode.ipoib). Compute nodes have access to two 
(compute-0-0.local, compute-0-0.ipoib).

Is it possible to make a single IPA instance manage the two isolated networks 
(local and ipoib)? Would multiple IPA servers and multiple enrollments be 
required? Once an IPA solution is defined, how does one configure 
openssh/sssd/krb5 on the compute nodes such that Kerberos SSO (and NFS server 
access) works regardless of which isolated network is used for communication?
Would the compute nodes' two-network configuration be extensible to the 
headnode's three-network configuration?

Thanks,
Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

-- 
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] apache kerberized nfs4 /var/www/html access denied for apache user

[Nordgren, Bryce L -FS]

Hi Rob,

How does the NFS server map the apache user to “something” it recognizes? I 
would suggest that the easiest solution may be to use an IPA account called 
“apache”, so that the mappings would just work, but currently I’m having 
trouble running a service as a domain user via systemd. 
(https://lists.fedorahosted.org/pipermail/sssd-users/2014-September/002194.html)

Beyond that, for kerberized NFS (local or domain user), you’ll need something 
to keep a fresh ticket on hand, so you may end up running something like 
k5start, and setting KRB5CCNAME in the environment where you’re running apache.

Bryce

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Rob Verduijn
Sent: Monday, September 15, 2014 9:17 AM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] apache kerberized nfs4 /var/www/html access denied for 
apache user

Hello,

I've got a webserver whose default export is on a kerberized nfs4 export.


The export works fine for regular ipa users

However the apache user is not allowed to read anything from the export.

What would be the best practice to allow the apache user access to the nfs4 
export without switching to sec=sys ?

Cheers
Rob





This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
-- 
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] FreeIPA ActiveDire​ctory Integratio​n: Managing AD Users in IPA

[Nordgren, Bryce L -FS]

Overwriting certain attributes may be more directly addressed by:  
https://fedorahosted.org/freeipa/ticket/3979

You are to some extent describing a feature that we call views that is 
currently in works.
But there are two parts:
a) Ability to overwrite POSIX attributes for AD users - this is views
https://fedorahosted.org/freeipa/ticket/3318
https://fedorahosted.org/freeipa/ticket/4509
b) Ability to apply policies to AD users. It is already possible.
This is done via group membership.
So you create a group in IPA, make AD group an external member of that group 
and then use that IPA group to apply HBAC, SUDO and SELinux rules.

As for RBAC what do you mean?




--

Thank you,

Dmitri Pal



Sr. Engineering Manager IdM portfolio

Red Hat, Inc.




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
-- 
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] Sane request?

[Nordgren, Bryce L -FS]

Sweet! Yes I am apparently talking about that. Consider this an independent 
request for that. :)


You are talking about this, right?
https://fedorahosted.org/freeipa/ticket/4509








This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
-- 
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] Sane request?

[Nordgren, Bryce L -FS]

Is it sane to request that freeipa store ssh keys for users who come into the 
environment via a trust? Not all of them, of course, but those who want to 
store public keys there.

My freeipa server is mostly there to manage machines, and users (incl. me) 
mostly come in over trusts from the corporate AD. It'd sure be nice if I could 
put my laptop's public key on the freeipa server and use it everywhere.

Food for thot.
Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
-- 
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] A prototype of merged domains (views)

[Nordgren, Bryce L -FS]

 -Original Message-
 From: Alexander Bokovoy [mailto:aboko...@redhat.com]
 Sent: Monday, August 25, 2014 3:04 AM
 To: Nordgren, Bryce L -FS
 Cc: 'freeipa-users@redhat.com'; 'sssd-us...@lists.fedorahosted.org'
 Subject: Re: [Freeipa-users] A prototype of merged domains (views)

 What essentially you want is to arbitrate access control to certain services
 regardless the source users or groups are coming from. This is already
 possible to achieve with HBAC rules because we already can make external
 SIDs members of a non-POSIX group that is included into a POSIX group
 which is referenced by an HBAC rule. This works already and doesn't need
 any views because HBAC rules already can be subjected to a specific host and
 specific service on the host.

Ah. My system is intended to work when there is no upstream SID (e.g., the 
source could be something other than active directory). This is necessary to 
provide a loose one-way coupling from the more-truested intranet to the 
less-trusted collaboration network. Getting this established as a foundation is 
also a critical prerequisite to experimenting with a web sso/kerberos gateway.

 We need to extend concept of external members of non-POSIX groups to
 have the same resolving features as we are planning with ID view overrides
 (SID:S-..., IPA:uuid, etc) so that external non-POSIX groups can be used
 more widely.

Nonlocal groups are not interesting to me. They are defined in the internal 
corporate environment which is not at all similar to an external collaboration 
domain. Locally defined groups, containing members drawn from any of the 
contributing identity sources, are interesting.

 Your other problem is that you seem to unable to establish two-way trust
 with AD as currently IPA requires. I have plans to get one-way trust back
 working but it needs additional changes on our side to properly protect trust
 account credentials when distributing them to a group of IPA masters
 participating in the trust.


One way trust was requested in April and is still pending. Chances of getting a 
two-way trust are zero. I'll be using the documented workaround to add the 
Kerberos cross-realm principal to the KDC if and when I get it.

Chances of getting a trust go up if you eliminate all the crap MS overloads 
that word with. A simple Kerberos trust (realm trust) should be easier to get 
than a domain/forest/etc. trust because it exposes the intranet to less 
vulnerability. Much of my problem so far has been that people assume I want a 
domain or forest trust when I'm really asking for a realm trust. If it helps, 
you can think of this as a prototype of what FreeIPA's going to need views to 
do in order to implement a vanilla Kerberos trust.

I want them (CIO) to authenticate users for me and provide a handful of well 
controlled and harmless user attributes. Port 88, port 389, and port 636. 
Nothing else.

In other words, I want a very loose, one-way coupling between the collaboration 
domain and the intranet. Not two way. Not tight coupling. Understand that the 
point of the collaboration domain is to delegate root access to people who are 
not part of the CIO and may not even be employees. Tight, two-way coupling of 
the intranet to this environment amounts to unnecessary exposure to risk.

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

-- 
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] A prototype of merged domains (views)

[Nordgren, Bryce L -FS]

Over the past month, I rearranged my local systems for our collaboration 
environment. The essence of the work is to combine employee identities (defined 
in AD) with identities for external users (defined in FreeIPA), massage them so 
that they look the same, and export them to every posix desktop and web 
application I support.

Defining cross-domain posix groups is included, and was successfully performed, 
but sssd doesn't have a vocabulary to describe a merged domain (one identity 
provider, multiple auth providers). Still trying to figure out if I can force 
this to work somehow.

The activity may shine a light on some of the things views might be required 
to do.

http://www.freeipa.org/page/V4/Use_Case_for_Views:_Collaboration

Enjoy,
Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
-- 
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] about AD trusts and passthrough authentication

[Nordgren, Bryce L -FS]

I’ve got a prototype setup for cross-realm operations. I don’t know if that’s 
useful for you or not. I don’t have control over “my” AD, and I’m managing this 
during our CIO’s migration from one AD realm to another (so duplicate users 
having distinct DNs and Kerberos principals are the norm, rather than the 
exception). I have three upstreams: FreeIPA, and Corporate AD A and B.

My non-FreeIPA users setup is in two stages, meaning two separate OpenLDAP 
servers. I couldn’t squash them down onto one server, but you might be smarter 
than me:

1] A “remapping” metadirectory server, which combines all of the foreign users 
from all three upstreams into one DIT (although each upstream gets its own OU). 
This server’s job is to make sure that a single LDAP query can return results 
from any of the upstream servers. It stores nothing locally and masks out most 
of the upstream info. LDAP binds are passed thru to upstream.
2] A “translucent proxy” server, which does no remapping, but lets me 
add/override attributes. Also have RFC2307 group stored here.

FWIW, I don’t have a trust between any AD and FreeIPA. The metadirectory server 
binds as me against AD (via a keytab and k5start). You can get pretty far 
without a trust, and without the ability to create groups on the AD side.

My goal is to set myself up to take advantage of “views” when they make it into 
FreeIPA. The real objective, though, is to propagate the cross realm 
functionality enjoyed for the last four years with my ldap/padl setup into a 
freeipa/sssd environment. Long term, I want FreeIPA to internalize my sketchy 
prototype setup and manage uid/uidNumber/gidNumber/loginShell/homeDirectory 
overrides for my linux domain in some sensible and convenient way.

I’m trying to implement the “umich_schema” (man idmapd.conf) to enable cross 
realm NFS, eventually, if I ever get a trust. Ideally, this could also be used 
by sssd to map GSSAuthName to username, particularly if a person has more than 
one GSSAuthName.

Dumb and persistent sometimes trumps smart. ☺
Bryce


From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Daniel Shown
Sent: Monday, August 11, 2014 3:04 PM
To: Alexander Bokovoy
Cc: freeipa-users
Subject: Re: [Freeipa-users] about AD trusts and passthrough authentication

Right, that's what I've got at this point. I just wanted to make sure I wasn't 
missing something. Unfortunately, that architecture won't work for me (mostly 
for political reasons instead of technical ones). I guess I'll be digging into 
pass through auth to see if I can get that working.

thx.

===
Daniel Shown,
Linux Systems Administrator
Advanced Technology Group
Information Technology Serviceshttp://www.slu.edu/its
at Saint Louis Universityhttp://www.slu.edu/.

314-977-2583
===
The aim of education
is the knowledge,
not of facts,
but of values.
— William S. Burroughs

I’m supposed to be
a scientific person
but  I use intuition
more than logic
in making basic
decisions.
— Seymour R. Cray

[Image removed by sender.]

On Mon, Aug 11, 2014 at 3:08 PM, Alexander Bokovoy 
aboko...@redhat.commailto:aboko...@redhat.com wrote:
On Mon, 11 Aug 2014, Daniel Shown wrote:
I'm fairly new to FreeIPA, so can someone give me a sanity check? Should I
be able to map AD users in an AD trust to to corresponding FreeIPA users?
i.e. Users can auth with their AD credentials and get a FreeIPA uidnumber,
gidnumber, home, etc.?
Users from a trusted forest are treated as separate users. They have
their own identities and get IDs from either Active Directory (if POSIX
compatibility is enabled at AD) or from special ID range allocated for
them in IPA.

You can include these users (and groups, it doesn't matter what is what)
into special type of groups in IPA, called external groups. These
groups, in turn, can be members of existing POSIX groups from IPA. If
done so, your AD users will become members of appropriate POSIX groups
from IPA by means of nested membership.

These POSIX groups then can be used to apply SUDO or HBAC rules against
AD users.

--
/ Alexander Bokovoy





This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
-- 
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] FreeIPA and FQDN requirements

[Nordgren, Bryce L -FS]

 Assume that FQDN is constructed as static hostname.domainname from
 DHCP or via reverse DNS lookup. What happens if the machine (laptop)
 moves from one network to another? What if the machine have multiple
 interfaces?

 As a result, any change in FQDN will break your Kerberos setup.

The machine's host keytab (/etc/krb5.keytab) retains a reference to whatever 
principal was used when the host was added to ipa. The Kerberos setup shouldn't 
break unless:

A] You can't contact your KDC because a firewall's in the way.
B] The KDC moved and DNS has not caught up.






This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

-- 
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] Adding cross realm trust principals

[Nordgren, Bryce L -FS]

  Let me elaborate. We haven't had time to work on this but it would be
  really valuable if you could experiment with it a little bit.
 
  Simo, Alexander, could you propose some dirty tricks to try?
  The thread mentioned above has all needed information already.
 Should we turn it into a HOWTO page then?

Yes, I would appreciate that.




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

-- 
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] Centos7, selinux, certmonger, and openldap

[Nordgren, Bryce L -FS]

Hey all,

On CentOS 7 (presumably RHEL7 too), the tutorial on 
http://www.freeipa.org/page/PKI breaks (when applied to installing a 
certificate in /etc/openldap/certs). The offending line is ipa-getcert request 
-d /etc/openldap/certs ..., and the failure message is /etc/openldap/certs 
must be a directory.

SELinux is enforcing, and there was an AVC. Audit2allow suggests that I enable 
the boolean authlogin_nsswitch_use_ldap. Works like a champ after that. 
Thought I'd bring it up because the name of the boolean doesn't scream out let 
certmonger manage openldap's certificates.

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
-- 
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] Centos7, selinux, certmonger, and openldap

[Nordgren, Bryce L -FS]

Spoke too soon. I needed the following extra selinux policy module to make 
all the AVCs go away.

BTW: the instructions on http://www.freeipa.org/page/PKI really only work if 
you leave the password blank when you create a new database with certutil. 
Otherwise, the ipa-getcert request command creates tracking requests which 
get stuck. Databases with passwords cause certmonger to error with a Cert 
storage slot still needs user PIN to be set.. This took me a couple of hours 
to track down.

O, and don't use /etc/pki/nssdb as a test to see if you can make the 
instructions work there. It'll work, but your shiny new service certificate 
will clobber your host certificate because the subject is the same. Urgh. If 
that happens to you, you can ipa-getcert list to get the tracking ID of the 
clobbered certificate, then ipa-getcert resubmit -i CLOBBERED ID to get it 
back.

Ignorance really was bliss.

Bryce

SELinux module:
==
module certmonger_openldap 1.0;

require {
type slapd_cert_t;
type certmonger_t;
class file write;
}

#= certmonger_t ==
allow certmonger_t slapd_cert_t:file write;






This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

-- 
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] Local users/groups to IPA Transition

[Nordgren, Bryce L -FS]

 Well, the users are definitely going to be in IPA (or AD via IPA).  However,
 they *will* exist in both IPA and locally during the migration period.  If 
 they
 have the same UID/GIDs in both places (local and IPA), then I will need to
 prefer IPA to 'files' in nsswitch.conf.  The main reason I want to duplicate 
 the
 local UID/GID's in IPA is to retain file permissions.

The initial state and final state of your domain is identical to the initial 
and final states of each individual machine. The transition period is composed 
of some machines being migrated and some machines not migrated yet. Those which 
are not migrated yet have the users in /etc/passwd and have no knowledge of 
ipa. Those which are migrated should get users from ipa and the duplicate users 
purged out of /etc/passwd. Setting up a machine with ipa and forgetting to 
delete the users out of /etc/passwd is probably asking for trouble.

This is a separate problem from keeping UIDs the same or not. If you've got NFS 
set up, you need to either simultaneously migrate all the machines which share 
files, or you need to keep UIDs/GIDs the same so you can migrate individual 
machines at your leisure. Separately, you need to tradeoff how much work it is 
to configure FreeIPA to just continue with your current scheme (set it up to 
allocate UIDs picking up where you left off) vs. find and chown files on all 
your machines as part of the migration process. If neither option sounds 
attractive to you, perhaps you may find it acceptable to have the pre-FreeIPA 
block of UIDs separate from the block of UIDs FreeIPA uses after it takes over.

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

-- 
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] Local users/groups to IPA Transition

[Nordgren, Bryce L -FS]

 We are evaluating RHEL7 IdM (FreeIPA 3.3) for identity management for our
 UNIX infrastructure.  All of our Linux hosts currently have standard and
 consistent UID/GIDs for at least all of our administrative users.  I'm looking
 for advice on how to migrate these users into IPA.
...
 Eventually we plan to configure a kerberos trust with our AD domain where
 we could configure these UID/GIDs via AD's POSIX UID/GID settings.

So if I understand this right, you're planning on two back to back user 
migrations? First is local-FreeIPA, then eventually FreeIPA-AD? Are your 
current local users coincidentally the same as your current AD users?

I'm probably a bad example. I centralized authentication for web apps about 
four years ago. I'm adopting FreeIPA because my desktops are every machine for 
itself. I have the same username everywhere, but UIDs/GIDs are uncoordinated. 
More important to me is the fact that my passwords are related to whatever was 
in vogue when I set up the machine, and the machines were set up any time from 
this month to ten years ago. Converting to FreeIPA happened because I started 
thinking of my little domain as a place to manage collections of desktops 
instead of just collections of web applications.

I'm also feverishly trying to setup an isolation layer between myself and AD, 
because my CIO is migrating from an agency directory to a department 
directory, with users migrating in batches not aligned to the projects I 
support. The isolation layer also allows me to continue to form groups composed 
of both AD and FreeIPA users, allows me to supplement or override user 
attributes for the local environment, and (cross-fingers) will allow for NFS 
file sharing with kerberos authenticated principals from more than one realm 
(assuming the Kerberos trust comes thru). Four birds with one stone.

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

-- 
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] 4.0.0 password migration trouble

[Nordgren, Bryce L -FS]

 I will work with DS team to backport the switch option to Fedora 20 389-ds-
 base and to release FreeIPA 4.0.1 with appropriate patch to fix this problem
 ASAP, ideally this week.


Thanks much, Martin!




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

-- 
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] 4.0.0 password migration trouble

[Nordgren, Bryce L -FS]

DNS is fixed, 4.0.0 is installed, and my external users have been migrated from 
an LDAP store via the migrate-ds script.

The password migration page keeps telling me that the password or username I 
entered is incorrect. (username: test.user, password: test) I did not mistype 
this. I did set the minimum password length to 0, but not until after migrating 
my users.

IPA forced me to reset the password for test.user, then kinit (attempting to 
login via sssd failed), then change the password before sssd logins and ldap 
binds started working. This is not an appropriate migration path for those 
users who primarily interact with web apps, so I need that migration page to 
work.

The LDAP interface is also important to me, as I want to use this for web app 
authentication. As is, my migrated accounts are doing this:

[root@fislstore ~]#  ldapsearch -h ipa.usfs-i2.umt.edu -x -D 
'uid=my_peeps,cn=users,cn=accounts,dc=usfs-i2,dc=umt,dc=edu' -W 
'(objectClass=posixAccount)' dn
Enter LDAP Password:
ldap_bind: Inappropriate authentication (48)




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
-- 
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] 4.0.0 password migration trouble

[Nordgren, Bryce L -FS]

 Someone has reported an issue with password migration where 389-ds is
 rejecting the passwords with:  passwords with storage scheme are not
 allowed. That may be part of the problem.

That was me, but the context was 'ipa user-add' with a password hash rather 
than migrate-ds. Although it makes sense that 389 ds would act the same 
regardless of how I attempt to store the password. How can I check to see 
whether the passwords made it to freeipa? The migrate-ds script didn't 
complain, but I don't know where to look for logfiles.

Thanks,
Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

-- 
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 trust and NFS nobody issue

[Nordgren, Bryce L -FS]

 Hi Aron,

 the support case you referenced is linked to bugzilla
 https://bugzilla.redhat.com/show_bug.cgi?id=1066153 which is fully acked
 for RHEL-6.6, the state of the bugzilla is ON_QA, so currently it looks the
 patch will be released in 6.6..

username@domain is coded in the NFS spec as an NFS id which goes over the wire. 
It's unclear what allowing two @ signs means (which @ separates username 
from doman, and which is part of one of these components?) While I'm sure this 
patch is trivial and I'm certain the patch works, it breaks interoperability 
with everything not running the patch (all non-linux and any non RHEL/Centos 
6.6 linux). This is probably acceptable in certain closed environments, but I 
can never use it here.

However, patching the idmapper so that if the username already contains an @, 
it doesn't add another one should also be trivial and should also work. It has 
the added benefit of not trashing interoperability. Conceptually, it allows 
sssd to convey both username and domain with no extra overhead and upgrades the 
linux nfs idmapper to handle living on a system which understands more than a 
flat namespace. To do it right, sssd always needs to supply the nfs idmapper 
usernames of the form username@domain regardless of the regex used to parse 
out those components at the login prompt.

I'd have put that on the bugzilla, but I can't get at it.

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

-- 
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 trust and NFS nobody issue

[Nordgren, Bryce L -FS]

 Thing is, nfsidmap always adds and then substracts '@' plus domain,
 assuming that the part prior to '@' is what going to be mapped by the
 domain-specific idmap mapper.

That's the crux of the problem right there.  Sssd is not a domain-specific 
idmap mapper.  Sssd is a domain-aware, multidomain idmap mapper. Hence the 
first @.

 What you get here by not adding the '@' to
 the name which contains '@' already is that wrong domain will be classified
 and then wrong name is passed to the system to ask for.

The corollary of not adding the '@' is not subtracting it either.

If sssd is the system service that deals with multidomain issues, then let it. 
The NFS idmapper doesn't need to add or subtract the @ and should pass it on 
to sssd, if it's interacting with sssd. One flag to the mapper 
(domain-aware-system=true), the internal linux only problems are solved 
internally, and the over the wire traffic is not broken in ways that break 
other clients (e.g., your patched system emits traffic which looks _exactly_ 
like the traditional-read-conforming NFS case to unpatched systems and 
other ground-up implementations). Breaking the protocol in a self-consistent 
way which excludes other platforms is a very Microsoft-like approach and makes 
me feel all dirty. Sometimes (not now) it's necessary as a band-aid/workaround, 
but this time the band-aid doesn't have to break things. :)

I'd say the real solution, long term, is to point both sssd and the nfs 
idmapper at something like a umich_ldap server managed by freeipa. This has 
additional benefits like centralizing the idmapping in a way that's exportable 
to foreign organizations so they can be clients to my servers, being able to 
resolve uidNumber collisions when I'm not in control of the AD I'm trying to 
use, supporting bare Kerberos trusts, allowing multiple GSSAuthNames (e.g., my 
AD account, Kerberos credentials from my home network KDC, my SAML account) to 
be recognized as the same user, etc. Room for growth.





This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

-- 
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 4.0.0 Peer's certificate issuer has been marked as not trusted by the user.

[Nordgren, Bryce L -FS]

On a clean Fedora 20, minimal install, system using the netinstall iso, I'm 
getting an error all the way at the end of the ipa-server-install process (when 
it tries to run ipa-client-install). I put the fqdn of the hostname in 
/etc/hostname and ipaddr ipa.usfs-i2.umt.edu ipa in /etc/hosts and rebooted. 
Hostname returns the fqdn. DNS A, SRV, and TXT entries are in place. Reverse 
DNS works.

Copr repository installed, and fedora-updates-testing enabled (for required 
version of dirsrv). Yum refused to install freeipa-server for reason of 
unsatisfied dependencies, but dnf succeeded.

Tail end of ipa-server-install is here, followed by a successful kinit and a 
failed ipa command. I can fix the cert issue on the server by following 
http://www.iamlinux.com/2014/06/ipa-commands-fails-with-peers-certificate-issuer-has-been-marked-as-not-trusted-by-the-user-error/.
 This allows ipa commands on the server to work. However, ipa-client-install on 
the client fails with the same Peer's certificate issuer has been marked as 
not trusted by the user.
Is this a dorky new user problem or should I file a bug?

Bryce

...
Done configuring the web interface (httpd).
Applying LDAP updates
Restarting the directory server
Restarting the KDC
Restarting the certificate server
Sample zone file for bind has been created in /tmp/sample.zone.dr0fFP.db
Restarting the web server
Configuration of client side components failed!
ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' 
'--on-master' '--unattended' '--domain' 'usfs-i2.umt.edu' '--server' 
'ipa.usfs-i2.umt.edu' '--realm' 'USFS-I2.UMT.EDU' '--hostname' 
'ipa.usfs-i2.umt.edu'' returned non-zero exit status 1
[root@ipa yum.repos.d]# kinit admin
Password for ad...@usfs-i2.umt.edu:
[root@ipa yum.repos.d]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: ad...@usfs-i2.umt.edu

Valid starting   Expires  Service principal
07/16/2014 13:29:51  07/17/2014 13:29:45  krbtgt/usfs-i2.umt@usfs-i2.umt.edu
[root@ipa yum.repos.d]# ipa user-find
ipa: ERROR: cert validation failed for 
CN=ipa.usfs-i2.umt.edu,O=USFS-I2.UMT.EDU ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's 
certificate issuer has been marked as not trusted by the user.)
ipa: ERROR: cannot connect to 'https://ipa.usfs-i2.umt.edu/ipa/json': 
(SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not 
trusted by the user.




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
-- 
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] FreeIPA 4.0.0 Peer's certificate issuer has been marked as not trusted by the user.

[Nordgren, Bryce L -FS]

 On Wed, 16 Jul 2014, Nordgren, Bryce L -FS wrote:
  DNS A, SRV, and TXT
 entries are in place. Reverse DNS works.

My text DNS entry is possibly hosed, as it's in lowercase. I put in a request 
to capitalize it.

[root@ipa yum.repos.d]# host -t TXT _kerberos.usfs-i2.umt.edu
_kerberos.usfs-i2.umt.edu descriptive text usfs-i2.umt.edu.


 Check /var/log/ipaclient-install.log first, as your IPA client install did 
 not finish,
 thus certificates store wasn't created properly and does not contain IPA CA
 certificate yet.

For someone on vacation you sure spend a lot of time geeking out. :)

 From the below, I think my next thing to try is to wipe the machine and 
ipa-server-install --realm=USFS-I2.UMT.EDU to override DNS until it gets fixed. 
Would you concur? Thanks for pointing me at the logfile.

2014-07-16T19:28:16Z WARNING Using existing certificate '/etc/ipa/ca.crt'.
2014-07-16T19:28:16Z DEBUG [IPA Discovery]
2014-07-16T19:28:16Z DEBUG Starting IPA discovery with domain=usfs-i2.umt.edu, 
servers=['ipa.usfs-i2.umt.edu'], hostname=ipa.usfs-i2.umt.edu
2014-07-16T19:28:16Z DEBUG Server and domain forced
2014-07-16T19:28:16Z DEBUG [Kerberos realm search]
2014-07-16T19:28:16Z DEBUG Search DNS for TXT record of 
_kerberos.usfs-i2.umt.edu
2014-07-16T19:28:16Z DEBUG DNS record found: usfs-i2.umt.edu.
2014-07-16T19:28:16Z DEBUG Search DNS for SRV record of 
_kerberos._udp.usfs-i2.umt.edu.
2014-07-16T19:28:16Z DEBUG DNS record found: 0 100 88 ipa.usfs-i2.umt.edu.
2014-07-16T19:28:16Z DEBUG [LDAP server check]
2014-07-16T19:28:16Z DEBUG Verifying that ipa.usfs-i2.umt.edu (realm 
usfs-i2.umt.edu.) is an IPA server
2014-07-16T19:28:16Z DEBUG Init LDAP connection to: ipa.usfs-i2.umt.edu
2014-07-16T19:28:16Z DEBUG Search LDAP server for IPA base DN
2014-07-16T19:28:16Z DEBUG Check if naming context 'dc=usfs-i2,dc=umt,dc=edu' 
is for IPA
2014-07-16T19:28:16Z DEBUG Naming context 'dc=usfs-i2,dc=umt,dc=edu' is a valid 
IPA context
2014-07-16T19:28:16Z DEBUG Search for (objectClass=krbRealmContainer) in 
dc=usfs-i2,dc=umt,dc=edu (sub)
2014-07-16T19:28:16Z DEBUG Found: 
cn=USFS-I2.UMT.EDU,cn=kerberos,dc=usfs-i2,dc=umt,dc=edu
2014-07-16T19:28:16Z WARNING Skip ipa.usfs-i2.umt.edu: cannot verify if this is 
an IPA server
2014-07-16T19:28:16Z DEBUG Discovery result: REALM_NOT_FOUND; server=None, 
domain=usfs-i2.umt.edu, kdc=ipa.usfs-i2.umt.edu, basedn=dc=usfs-i2,dc=umt,dc=edu
2014-07-16T19:28:16Z DEBUG Validated servers:
2014-07-16T19:28:16Z ERROR Failed to verify that ipa.usfs-i2.umt.edu is an IPA 
Server.





This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

-- 
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] Migrating from a hybrid web/posix LDAP

[Nordgren, Bryce L -FS]

Hi guys,

I set up freeipa 4.0.0 on a brand new Fedora 20 box, from your copr repos. 
Install and config went fine. Kinit: fine. Trying to migrate from my old ldap 
setup: problem.  Old ldap setup primarily had accounts for web apps 
(inetOrgPerson) and a few accounts with everything needed for login 
(posixAccount).

Ipa migrate-ds for the existing posixAccounts: works fine.

Migrating the web only accounts requires a bit more manual labor, and isn't 
working yet. I extracted a csv of my web-only accounts and made a script to 
upgrade them with posix attributes and add them to freeipa. Each line looks 
like:

ipa user-add bill.mathews --last=Mathews --first=William --email=blah 
--phone=xxx-yyy- --setattr userpassword={SHA}bunchajunka --setattr 
o=University of Tweedle --gidnumber=65534 --uid=263

And I get:

ERROR: Constraint violation: invalid password syntax - passwords with storage 
scheme are not allowed

I was inspired to include the password this way from:  
http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords

Is there any password preserving way to migrate my web-only accounts using ipa 
user-add? If there's no easy answer, I'll probably just add the attributes in 
the current ldap, then let ipa migrate-ds work its magic. But I want to see 
user-add work if its possible.

Thanks,
Bryce
PS: I believe all instances of service dirsrv restart on 
http://www.freeipa.org/docs/master/html-desktop/index.html#finding-excluding-entries
 need to be changed to systemctl restart dirsrv.target, since there is no 
dirsrv.service.





This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
-- 
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 trust and NFS nobody issue

[Nordgren, Bryce L -FS]

 The second @ is not provided by kerberos, it is rpcimapd making false
 assumptions, it does a getpwuid and gets back adt...@ad.example.org as
 the username, to which it decides to slap on the local REALM name with an @
 sign in between.

 I think this is something that may be handled with imapd.conf configuration.

Muchas gracias. This makes sense.

Found an old presentation on the topic [1]. Slide 15 is particularly relevant. 
Slide 4, however, taught me something I didn't know: NFS wants to deal with 
NFSv4 domain names (slide 3), which can be different than GSS principal names 
(Kerberos principals). There is only one NFS domain, but there can be multiple 
security realms and multiple DNS domains (slide 2).

The crux of this is on slide 14: Need to add posixAccount with GSSAuthName for 
UID/GID mapping of remote user.  Is this another use case for views?

What I'm not quite clear on is the interaction between idmapd and ldap (slides 
15,16,18). Does idmapd want to see this NFSv4RemoteUser schema on the LDAP 
server? Is this schema something that FreeIPA would have to support for NFS to 
work with cross-realm trusts? Or has the landscape changed since this 2005 
presentation?

Bryce

[1] 
http://www.citi.umich.edu/projects/nfsv4/crossrealm/ASC_NFSv4_WKSHP_X_DOMAIN_N2ID.pdf




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

-- 
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] Add'tl use case for views

[Nordgren, Bryce L -FS]

Inconsistently managed AD user entries.

Many accounts in my AD are posixAccounts, but I encountered one today (created 
in 2013) which had no posix information whatsoever. This crumpled my assumption 
that I could leverage posix information from the institutional source. Under my 
current system, I had to create an external account for him. With views, I 
could've provided the missing attributes.

Dunno why just is.

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
--
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] External collaboration edits

[Nordgren, Bryce L -FS]

 -Original Message-
 From: Sumit Bose [mailto:sb...@redhat.com]
 Sent: Tuesday, June 17, 2014 3:27 AM
  Case one would represent vanilla Kerberos trusts, or the quite likely
 scenario where an external collaboration domain is separated from corporate
 AD by a firewall. (e.g., institutional AD can provide authentication via 
 trust for
 users on the corporate network, but not attributes).

 I think this can be done. It is about how the reference key is evaluated. 
 E.g. if
 the key is ':KRB5:u...@example.com' in the default view SSSD can create a
 user object in its cache with the data given in the view and where the user
 name is equal to the Kerberos principal name (so far we said that we do not
 want to allow to overwrite the user name in views to avoid confusion). Since
 the object is now in the SSSD cache it is available in the IPA server, on IPA
 clients with SSSD via extdom plugin and to legacy clients via the compat tree.

I hate to appear too stupid, but google isn't getting me where I need to be 
fast enough. What's the extdom plugin? Also I think I'm losing track of the 
flow. Is the above talking about SSSD on one of the domain clients, or on the 
FreeIPA server? I'm not sure I understand how an object in the (client's?) SSSD 
cache becomes available to FreeIPA, and hence to all domain clients...

I think you may have to allow overwriting the username in views, unless there 
is some other mechanism to allow the domain admin to resolve username 
collisions. I don't think views should ever touch the user's real name fields, 
or email, or things which actually apply to the human behind the identity. 
However, I'm thinking of views as the means by which an externally defined 
identity is adapted to the local computational environment. Overriding 
username, uidNumber, group membership, and other stuff relevant to using the 
remote identity in the local context is all fair game.

Individual cross-realm principals may be the norm for onsey-twosy logins from 
foreign domains where its impractical to establish trusts. These will have the 
form:

USER/external@example.com

Which in my case would be:

bnordgren/ds.fs.fed...@firelab.org

That's awful long, and the slash in the middle means that the home directory 
can't just be the username. Principals from foreign technologies may be longer, 
and also full of stuff that can't be in a directory name. We don't know what 
those will look like yet, but the username may have three components and 
contain a URL. Say this is the Kerberos version of my SAML principal:

bnordgren@fs/SAMLv2.0/https://www.eauth.usda.gov/Login/login.a...@firelab.org

Long story short, don't worry about how the nasty principals get generated, but 
do assume that they are too ugly for words. Please please please overwrite my 
username. :)

  Case two would represent authentication sources such as SAML. Views
 would need to be the mechanism by which the gateway caches attributes in
 FreeIPA (after inspecting SAML assertions).

 I think we are already doing similar things with the MS-PAC. If configured
 SSSD will intercept the PAC, decode it and store data from the PAC in the
 cache. This currently happens during authentication on the client hence this
 data is directly available on the IPA client and is not distributed by the IPA
 server. Would this work for you use case or do you need the data on IPA
 clients where the user never authenticated as well?

I think that if FreeIPA intends to provide infrastructure which offers clients 
the option setting up file sharing via nfsv3 or v4 using host-based auth, the 
uidNumbers all have to be the same for all domain clients. I'd vote for 
supporting filesharing. NFSv4 with Kerberos auth may tolerate the uidNumbers 
being different, at the cost of making sssd manage the idmapper.

If there's no file sharing (users log into isolated workstations and touch only 
local files or scp/sftp/sshfs files back and forth), then each machine needs to 
allocate a persistent identifier which lasts from session to session. Is the 
SSSD cache persistent between logins?

However, this won't recognize that me logging in via Kerberos is the same as me 
logging in via SAML. (see below) So I guess this is a very longwinded no, it 
won't work for me. Sorry. :) Needs to be consistent in the domain.

  Finally, one functional requirement for views may be that the view needs
 to support a many-to-one authentication method to identity attributes
 mapping. For instance, an employee sitting at their desk may log into their
 server in the collaboration network via SSO (hence, their AD account). Soon
 this same user may also walk over to the console on the collaboration
 network and need to use some other Ipsilon-gateway-enabled credentials.
 These two credentials may need to be mapped to a single user identity. This
 may not be functionality which needs to be implemented first, but it does
 perhaps suggest that krbPrincipal may not always be single valued. 

[Freeipa-users] Ipsilon and WebAthena

[Nordgren, Bryce L -FS]

When thinking about gateways and what Ipsilon may do, I came across this thesis:

https://davidben.net/thesis.pdf

and source

https://github.com/davidben/webathena

His approach to unifying web and non-web technologies was to build gateways for 
non-web services such that browser based clients could be written without 
changing the server side.

I'm not sold on that approach. However, the source repository includes a 
browser-based javascript implementation of the Kerberos protocol and a python 
gateway to a KDC. Users can kinit from the browser the way Kerberos intended 
(password does not go over the wire).

Is it possible to do a pure-javascript, all browser based kinit/spnego so that 
users don't have to pop out to the command line to kinit? One still would not 
have the ability to ssh into a console after doing an in-browser kinit, but all 
the websites in the target domain should recognize the credentials.

Worthwhile or dumb?

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] External collaboration edits

[Nordgren, Bryce L -FS]

[...talking about views...]

 It's not only about AD, but use-case and examples in the design page
 currently all refer to AD. The key is to find a unique reference to the
 upstream object which in the AD case is obviously the SID. In a previous
 version of the page there were a bit more details who the original/upstream
 objects can be referenced, e.g. it can a fully qualified name or Kerberos
 principal.

Can views handle the case when there is no upstream object? Or when the 
upstream attribute store is not published as a searchable database (which is 
almost no upstream object)? I'd very much like to see these as explicit use 
cases for views.

Case one would represent vanilla Kerberos trusts, or the quite likely scenario 
where an external collaboration domain is separated from corporate AD by a 
firewall. (e.g., institutional AD can provide authentication via trust for 
users on the corporate network, but not attributes).

Case two would represent authentication sources such as SAML. Views would need 
to be the mechanism by which the gateway caches attributes in FreeIPA (after 
inspecting SAML assertions).

Finally, one functional requirement for views may be that the view needs to 
support a many-to-one authentication method to identity attributes mapping. 
For instance, an employee sitting at their desk may log into their server in 
the collaboration network via SSO (hence, their AD account). Soon this same 
user may also walk over to the console on the collaboration network and need to 
use some other Ipsilon-gateway-enabled credentials. These two credentials may 
need to be mapped to a single user identity. This may not be functionality 
which needs to be implemented first, but it does perhaps suggest that 
krbPrincipal may not always be single valued. This may be something which 
deserves an honorable mention on the RFE page as it impacts the assumptions 
coders can make.

Thanks,
Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

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

Re: [Freeipa-users] External collaboration edits

[Nordgren, Bryce L -FS]

Dimitri, thanks for the reply! Pls forgive my lateness.

I fear I am not currently up to fighting with MS Outlook to convince it to let 
me respond inline. It wants to block quote your entire message and if I type in 
the middle it keeps the quoted style.

In any case:

#1] Making small things work first and accumulating functionality is definitely 
the way to go. If it were simple and straightforward, everyone would be doing 
it already.

#2] I looked at views (Ticket 3979 as well as 
http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust). I 
think I follow most of it (a default view which applies to the whole domain, 
custom views which may be applied to particular targets). +1 +1 +1. One concern 
I have is that the design page seems to be written around a single upstream 
source (trust with AD). What happens if there are many upstreams?  All in 
all, though, it sounds like my current RFE is a duplicate of views. If we could 
add in my use case to the Views ticket/design, we can close mine out.

#3] Kerberos based auto provisioning will fall apart if the authentication path 
cannot be walked by the client (not the FreeIPA server). When I'm sitting in my 
office, I can see my KDC as well as the collaboration environment, and I can 
walk the path. However, if I cannot convince my CIO to poke a hole in the 
firewall so that FreeIPA in the collaboration domain can get to the internal AD 
(to query attributes, etc), then an AD trust is not possible and a vanilla 
Kerberos trust is all that is available. Kerberos-trust based auto-provisioning 
may be able to handle situations that AD trusts can't. By and large, I need my 
boxes to know my username, and could care less if they know my givenName, sn, 
mail, telephoneNumber, etc. As long as FreeIPA can synthesize a uidNumber for 
me in the absence of an SID, the rest is gravy.

#4] One user/Many Accounts. This is an unavoidable reality. Also, there's a 
namespace collision issue here. My Kerberos cname@crealm is 
bnordg...@ds.fs.fed.usmailto:bnordg...@ds.fs.fed.us as issued from my AD. My 
SAML uid is bnordgren@fs from https://www.eauth.usda.gov/Login/login.aspx. My 
Google OpenID is bnordgren from wherever. There is also a bnordgren from a 
university out of SLC, Utah. I occasionally get mis-addressed email for him. 
Typically spam, but once from his mom. Fundamentally, whenever multiple domains 
are consolidated into a single namespace (as is already a use case for views), 
one typically tries to avoid username collisions just as vigilantly as they try 
to avoid uidNumber collisions. What is needed here is a method for the users to 
override the default collision avoidance such that they allow all of their 
accounts to be mapped onto their One True Username for the domain. In the 
spirit of point #1, implementing collision avoidance will be required for 
views, so it needs to happen now even without external collaboration. Figuring 
out how to let users override it can happen in the future.


Bryce


From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal
Sent: Wednesday, May 14, 2014 4:13 PM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] External collaboration edits

On 04/19/2014 07:46 PM, Nordgren, Bryce L -FS wrote:
I've run out of time for today, but the external collaboration pages are slowly 
evolving.


http://www.freeipa.org/page/External_Users_in_IPA

Dimitri observed that my RFE page was too long. I observe it also has too much 
stuff unrelated to the actual meat of the RFE. So I factored out most of the 
Kerberos stuff into a different page. I also tried to focus the RFE to just 
creating entries in LDAP for external users so they can: a] participate in 
POSIX groups; and b] have locally-defined POSIX attributes.

http://www.freeipa.org/page/Collaboration_with_Kerberos

This is where all the Kerberos stuff went. I also added  in Option A from 
Petr's email. Option B will come along later, when I pick this up again. 
Mechanism three has more to do with Ipsilon than IPA, and basic functions 
required of the Ipsilon gateway server are articulated there (regardless of the 
particular authentication method.)

Send comments to the list. I really appreciate Option A! Send more stuff I 
didn't think of.

Hello,


I finally read the pages, sorry for the delay. great writeup!

Here are some comments.

1) You are right that we need to have a record in IPA to be able to have a DN 
and take over some of the posix attributes. We already have this use case and 
this is a high priority. We call it views: 
https://fedorahosted.org/freeipa/ticket/3979
Once this is implemented we will have mechanism to have a local entry without 
credential for the external user.
2) The second issue is provisioning as automatic as possible. And this is where 
there will be some issues.
If we want to leverage Kerberos trusts then two things should happen:
a) the trust should first be established
b) the home

[Freeipa-users] External collaboration edits

[Nordgren, Bryce L -FS]

I've run out of time for today, but the external collaboration pages are slowly 
evolving.


http://www.freeipa.org/page/External_Users_in_IPA

Dimitri observed that my RFE page was too long. I observe it also has too much 
stuff unrelated to the actual meat of the RFE. So I factored out most of the 
Kerberos stuff into a different page. I also tried to focus the RFE to just 
creating entries in LDAP for external users so they can: a] participate in 
POSIX groups; and b] have locally-defined POSIX attributes.

http://www.freeipa.org/page/Collaboration_with_Kerberos

This is where all the Kerberos stuff went. I also added  in Option A from 
Petr's email. Option B will come along later, when I pick this up again. 
Mechanism three has more to do with Ipsilon than IPA, and basic functions 
required of the Ipsilon gateway server are articulated there (regardless of the 
particular authentication method.)

Send comments to the list. I really appreciate Option A! Send more stuff I 
didn't think of.

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] External Collaboration Domains

[Nordgren, Bryce L -FS]

  Variant (A) - IdP + PKINIT:
  A1) User authenticates to his SAML/OpenID provider (external domain)
  A2) User locally generates CSR
  A3) User contacts IdP (gssapi/saml ; gssapi/openid) and sends CSR to
  the IdP
  A4) IdP returns short-lived certificate (validity period matches
  policy for TGT)
  A5) User presents certificate issued by IdP to KDC
  A6) KDC authenticates user via PKINIT and issues TGT as usual
 
  This variant doesn't require any change to Kerberos protocol. It needs
  IdP with CA + some client software automating described steps.
 
 
  Variant (B) - IdP without PKINIT is almost the same, just uses symmetric
 crypto:
  A1) User authenticates to his SAML/OpenID provider (external domain)
  A2) User contacts IdP (gssapi/saml ; gssapi/openid) and sends
  authentication request
  A4) IdP changes principal password to some random value and sends
  keytab back to the user (via GSSAPI-secured connection)
  A5) User uses keytab to get TGT from KDC
 
  Obvious problem 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.

Interesting notion. My understanding of B is that KDC would need an entry for 
the user in order to store the shared secret. This may interact with the 
principal name mapping in some hard-to-understand-right-now ways. For instance:

KDC manages EXAMPLE.ORG.

User is coming in from google openID account. Pretend mapped Kerberos 
principal is: username@OPENID:www.google.com/openid/provider/url

Can the KDC for EXAMPLE.ORG store that? I can see approach A working because 
the user principal doesn't have to exist in the KDC. Seems like case B 
involves a shared secret between external user and the local KDC, whereas 
approach A doesn't.

I would vote for making the lifetime of the shared secret be derived from the 
lifetime of the credential the person used to get it. (if the openID session is 
good for 12 hours, the keytab should be too.) I don't see a need to null out 
the keytab after one minute.

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


+1
+1

Perhaps the NSCA MyProxy CA also has some ideas worth implementing? It seems to 
be geared to a full-on PKI environment, where it issues derived (proxy) 
certificates for users to use in a login session. It appears that it could make 
kx509 certs as it is configurable w.r.t. what fields appear in the generated 
certificates and how identities are mapped. Also, it has client side programs 
for certificate storage and retrieval. Some concepts may be worth stealing. :)

Overall, it appears to me that short-lived certs (approach A) have a certain 
time-tested feel to them earned by many years of regular use captured in 
RFC3820. Approach A, in the parlance of RFC3820, could potentially be expressed 
as External users delegate to a local Kerberos session the right to use their 
non-Kerberos identity by causing a proxy kx509 certificate to be issued. The 
cross-technology aspect makes the wording weird, since you rarely consider 
self-delegation to be delegation. The only real addition here is the use of the 
proxy certificates to gain entry to the local Kerberos universe.

Short-lived long term secrets don't have this pedigree. Also, not real fond 
of transmitting the shared secret over the network, as required by B (even if 
it is a one-time-use thing. Makes me twitchy.) For that reason I might lean 
towards approach A, but would be happy with either.

Approach A has the client map the identities to generate the CSR. The IdP 
un-maps them to verify before issuing credentials. Seems this requires mapping 
strategy to be coordinated, perhaps standardized? Approach B, I presume, puts 
control of the mapping in the hands of the IdP? I assume this mapping would 
need to be coordinated with any realms to which this IPA is connected by trust, 
regardless of whether A or B is chosen? Things to think about...

  Is seems that variant (B) should be really simple to code/script when
  we have SAML/OpenID capable IdP.

 It can be done indeed.

I need to rework my RFE with diagrams to capture either A or B. Do you have a 
preference? Should I put both in as options?

One comment/question: in both A and B, step 1 seems superfluous? Gssapi/saml 
and gssapi/openid both support initial authentication, if no cached creds 
exist, I think. Could step one be dropped and/or integrated into step A3 or B2?

I'm still not understanding why transferring a TGT via a browser is more 
difficult than linking to a file-based representation of it and ensuring 
there's a helper application ready to handle that mime type on the client. 
(By handle, I mean store in the local cache.)  Presumably, the IdP could 
communicate the reply key to the client securely, but that's more or less the 
same as transmitting the shared secret over the 

Re: [Freeipa-users] External Collaboration Domains

[Nordgren, Bryce L -FS]

 There is a groups pf people that belong to different organizations, for
 example universities that launch a project together. They have the identities
 in their own home organization (domains). There is a hosting organization
 that some of the members of the group might belong to. Jointly all the users
 want to be able to access the systems that belong to the project, this
 includes login into the systems accessing file shares and web applications 
 that
 constitute the joint project. They also want to be able to SSO as much as
 possible without creating additional identities and having a separate
 password. The home organization in this case would have trust relations with
 the hosting organization.
 The goal is to make it possible for the home organization to understand
 external identities accessing resources on the file system level thus POSIX
 attributes need to be generated, assigned and managed for those users.


 Does it sound about right? It this the problem we are solving?

Perfect. I'll make a new wiki page with that text and pictures tomorrow. :)


  Collaboration is not limited to web services. Actually, if you asked me to
 come up with a real world example where collaboration happened only via
 web based services, I wouldn't be able to do it.

 Any Saas application.
 Google docs for enterprise, SFDC etc.

True. However, I've never been part of a project where these are all you need. 
These things do play a role, but aren't comprehensive.

 OK, note taken. I wonder though how common is this scenario/use case.
 The fact that we hear about it for the first time and having hard time
 understanding the use case makes me think that it is yet not that common.
 We would need to see what is the dynamics though and whether the world
 is moving towards or away from this case becoming a popular one.
 But assume it is.

I think it's common at the small scale and typically addressed by individual 
projects renting dedicated servers at hosting farms. New accounts local to the 
machines are usually created.

However, over the past ten years I've found that if I've set up 
infrastructure, there's no shortage of people who want to leverage it. This 
tends to cause my tiny solution to scale up and out beyond what I'm willing to 
support. I suspect that if CIOs were given a notion of what kind of support to 
offer their users, you may see more demand for something like this.

 OK. Let be paraphrase so that I understand (referring to the use case I
 mentioned above).

 Home organization will set a special IPA based domain for every external
 organization. It will be one way trusted but the hosting organization.
 This special collaboration domain will be the one where the entries are
 automatically created when external user comes in, right?

Essentially. I was thinking home organization would set up a single IPA based 
domain with a one-way trust from the internal corporate infra. As you mention, 
this domain would be where the automatically created external users appear. 
This single collaboration domain would be the connection point for 
inter-organizational trusts (vanilla Kerberos/IPA/AD) and would host the 
identity gateway (Ipsilon).

Is there a need for one domain per organization you want to collaborate with?

 b) There is a Kerberos SSO - but then his home domain needs to be
 trusted by his hosting domain. If it is possible the solution based on
 trusts exists. But I suspect CIOs do not like it ;-) so it is unlikely
 would be done in real life.

Thinking 5 years down the line, if multiple participating organizations had 
collaboration domains, CIOs may be a little more promiscuous with the vanilla 
Kerberos trusts between them. Don't rule out Kerberos SSO just yet. :)

 There is no option to use SAML or OpenID with SSH but to get to the
 system on the system level you need to SSH.
 So until SSH supports SAML or similar the whole idea would not fly.

I wouldn't try to make all domain services aware of all identity technologies.

Option d is use case 3 in the RFE. (Ipsilon obtains TGT for external user and 
forwards to client). The method of forwarding is what needs to be explored. It 
seemed to me that the method of getting the ticket from the KDC was fixed on 
s4u2user / s4u2proxy.

However, the RFE is structured such that IPA is prepared to service foreign 
user requests from an Ipsilon-like HTTP gateway, or an RFC6595-like gssapi/saml 
acceptor or a RFC6616-like gssapl/openid acceptor. The resolution of the 
technical approach to use case three is not a blocker.


 There is where I see a leap of faith. SAML - SSH. It is not possible.
 And I am not sure OpenSSH would be interested to support it. They had
 hard time supporting Certs.

No SAML-SSH. Even if it were possible, it would involve configuring every host 
in the domain individually. Ick.

Browser-Gateway-TGT-Service TKT-SSH. Like normal.
GSSAPI/OpenID-GSSAPI acceptor-TGT-Service TKT-SSH. Like normal. or
GSSAPI/SAML-GSSAPI acceptor-TGT-Service 

Re: [Freeipa-users] External Collaboration Domains

[Nordgren, Bryce L -FS]

  Close. The problem is to expose kerberized services in the local realm to
 users holding foreign credentials, supporting SSO wherever possible. This
 includes file sharing via NFS, kerberized web apps, ssh logins, and anything
 else the local realm has to offer. SSSD can handle ssh logins (if one 
 considers
 it handled to transmit the password over the wire and abandon SSO), but
 cannot handle the former two.

 This is already handled with the trusts feature with AD. It is handled by SSO
 and using Kerberos ticket renegotiation between two domains.
 The similar approach would work for IPA to IPA and IPA to Kerberos. In the
 IPA to IPA case we will have authorization data in the ticket that would help
 with this.
 I am sorry I fail to see a driver and use case here. But may be I am missing
 something obvious.

Trusts are only feasible between tightly coordinated realms and with the 
involvement of admins. The use case is a collaboration realm, where users (not 
admins) drive the connections between realms. This precipitates everything in 
the proposal. If the user is coming from an AD realm, there may not be a trust, 
and it may be inappropriate to have an admin form one if there are only three 
or four users binding the two realms together. The AD realm may be behind the 
institutional firewall and the KDC inaccessible, making PKINIT a good choice. 
Perhaps kx509 certificates are not available from the home realm, making OpenID 
or SAML a good choice.

A theme in your previous message was that some use case is already covered 
because the admin can explicitly take some action to handle it, and each 
instance (each new trust) needs to be individually created and then managed. 
The point of this RFE is that the admin can set  up a realm which responds to 
how users travel from realm to realm, offering both flexibility for the manner 
in which users authenticate and consistency for the services offered by the 
realm.

It's a different mindset that makes the use case invisible. :)

Bryce








This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.


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

Re: [Freeipa-users] External Collaboration Domains

[Nordgren, Bryce L -FS]

 I think it does not really differ from what I described, conceptually.
 It is, however, requiring much more work than what I described.

 FreeIPA has flat LDAP DIT. Adding support for separate OUs is in itself a non-
 trivial task.

Ah. Well since that's the case, separate OUs are gone. (You may have to hit 
reload in your browser to get the new figure.) It does require that the RDN 
of all external entities encode both the name and the realm of the external 
Kerberos principal in order to avoid collisions. Is the current external user 
provisioning method able to handle the same name coming from two domains or 
does it assume that collisions will never happen?

 PKINIT use in Kerberos is a big issue. Right now certificates produced by
 FreeIPA do not include special extension that Kerberos KDC requires to have
 PKINIT working. We have a ticket to solve this but it depends on few items
 missing in FreeIPA, Dogtag, and nss. Solving it is required for full OTP use, 
 so
 we might gain this feature sooner or later.

The proposal actually doesn't involve producing kx509 certificates, only 
consuming them. :) I think these are two issues which can be handled in 
parallel rather than having one block the other. ;)

 What's reasonable and can be relatively easily pulled in from your proposal is
 a mechanism to get users automatically provisioned in FreeIPA based on
 their cross realm identities. For example, for cross realm trust with AD we
 have means to selectively block certain SIDs from being imported from the
 AD. The rest is recognized and accepted but no local external groups created
 for them. We simply can automate creating the groups on login attempt if
 SIDs involved aren't blocked. This automation should solve majority of
 administrative load.

From my cursory examination of the code, I proposed auditing the KDC's AS and 
TGS conversations to trigger this automatic provisioning. Is this an approach 
worth keeping?

I understand that IPA's bread and butter is to attach itself to a pre existing 
AD domain to simplify the administration of Linux machines within the same 
administrative boundaries.  This is a subset of Use Case 1. I just want to make 
sure that there's a plan in place for situations where the domain of origin is 
not AD, and no SID is exported  (the rest of Use Case 1, and Use Cases 2  3.) 
This is just a generalization of the procedure to allow AD users access to 
services such that users from non-AD realms can also be included.

Use Case 1 could be named Intra-organizational cross-realm operation, Use 
Case 2 could be named Inter-organizational cross realm operation, and Use 
Case 3 could be named Multi-technology cross-realm operation. 23 involve 
independent administrative entities with a fair amount of autonomy. Traditional 
enterprise approaches are not valid for 23. :)

Thanks for the review!
Bryce






This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.


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

[Freeipa-users] External Collaboration Domains

[Nordgren, Bryce L -FS]

Collaboration can be in different ways. It all depends on the use case. It can 
be OpenID, SAML, Kerberos, etc. There are different technologies and they suit 
better different use cases.

Can you please share under what circumstances such inversion would actually 
be needed?

Console logins in a domain specifically created for collaboration with external 
entities. Expect that there is a one-way trust from the organization's 
internal domain (providing users) to the collaboration domain (providing 
services). The collaboration domain would host services and devices necessary 
for the execution of various projects. Project members are NOT from a small set 
of closely knit organizations, where it is feasible to establish cross domain 
trusts. As this is a large organization, many projects are starting, 
in-progress, and ending at all times. New projects do not necessarily require 
trusts to the same set of organizations as existing or finishing projects. 
Services may be web services, shared filesystems, standalone processing 
machines, and high performance computing assets. The services have service or 
host principals in the collaboration domain's domain controller. From an IT 
perspective, this is similar to interacting with customers, except the customer!
 s deploy and/or access stuff on your network.

Much of the horsepower in this domain will probably be some variant of Linux. 
There are instances of high-horsepower Windows and Mac devices/clusters, but 
they are not common.  Source code control, issue trackers, networked 
filesystems, datafiles, and metadata development webapps have a presence here. 
Esoteric scientific equipment may be connected to the network, but will 
probably not be Kerberized (i.e., Gas Chromatograph Mass Spectrometer). 
Terminals may be Mac, Windows, Linux, Android or iOS and may belong to guests. 
This is just in my building in Montana. Nationwide the situation is likely to 
be more chaotic. The big reason everything is here: it either violates 
enterprise policy or needs to be accessible by external users (which violates 
enterprise policy).

System administration responsibilities in this collaboration domain are largely 
distributed to the system owners and not centralized in the IT organization. 
There is no or little commonality in purpose, intent, authorization roles, 
characteristics, or business case for the systems, inter-project. Similarities 
may exist between multiple resources associated with a common project, or 
projects with a common theme. Many semi-autonomous fiefdoms ensue, most with a 
limited lifetime, composed of people none of whom want to manage user accounts, 
and none of whom want new passwords. Few want to monkey with security at all.

If such a domain were to exclusively contain web services, one wouldn't need  a 
domain controller at all. Something like gluu or openam would suffice. But I 
need to share files and support console access in addition to web access. Using 
the same credentials. Which I don't want to manage.

Your Google account does not use Kerberos that means that your password goes 
over the wire. The whole point of Kerberos that password does not go the wire.

Me thinks your flow is reversed. Posit an HTTP version of the AS exchange with 
the KDC, where users who are not present in the domain controller obtain TGTs 
for the local domain via their browser. The user doesn't provide a password to 
the KDC, nor does it provide a signed public key, but they do demonstrate they 
are recognized by a foreign IdP via a browser workflow defined by (SAML|OpenID 
Connect|OpenID|other). Conceptually, this is no different than PKINIT, in that 
the KDC puts its trust in (a presumably configurable) list of identity 
providers utilizing a varied patchwork of HTTP identity technologies. When the 
KDC's external identity webpage is satisfied that the remote IdP is happy 
with the user's  identity, it can return a TGT to the browser using a TBD 
encoding which the browser stores in the local ticket cache. The user in 
control of the browser session can then ssh into a machine via gssapi, or mount 
an NFSv4 filesystem, or connect to any of the realm's webservic!
 es using gssapi/spnego. Of course, the web services could also allow the 
native use of the foreign identity technologies.

If the KDC is bundled as part of a larger directory solution like IPA/AD, then 
some extra overhead (SID/UID) needs to be synthesized for use within the 
domain when the identity is first encountered. This is not more work than 
offering your realm's services to Kerberos users (from IPA? AD? Kerberos+LDAP? 
Just Kerberos?) who arrive from a foreign realm (via PKINIT or trust) when you 
have no way to access this non-kerberos information in the user's home realm. 
Letting the local domain controller do it guarantees it's harmonized within the 
realm.

There has to be a standardized method for encoding these foreign user principal 
names and realms. You want subsequent 

Re: [Freeipa-users] About Windows client

[Nordgren, Bryce L -FS]

I’m not, in general, in favor of solutions which promiscuously sling Kerberos 
passwords around the net. ☺ pGina + Kerberos authenticating directly off of IPA 
would be the way to go, I think.

Presumably Dimitri’s statement about the user being “foreign” and having 
limited access to windows services would apply equally well to a user with a 
SID from a foreign domain in a large Kerberos federation. This, and the 
uncertainty concerning what type of directory service the foreign KDC is paired 
with, is probably responsible for keeping Kerberos-based federations small.

That being said, the collaboration use case (not to mention “home networks”) is 
what makes “foreign” logins interesting. There’s hardly anything in common 
between two collaboration projects, so it’s hard to define far-reaching 
policies (i.e., you’re not missing out on much). Most all authorization 
decisions are delegated out to some project member responsible for the 
server/asset. Constructing authorization sets having members defined by text 
based principals makes a certain amount of sense. Hence the LDAP “member”  
attribute in RFC4519.

What would really be cool is the “inverse” of gluu or openam. Kerberos 
preauthentication data which allows the KDC to authenticate off of an OpenID 
Connect, SAML, or LDAP authentication source, caching the provided password and 
provisioning a Kerberos principal. Future AS exchanges would start out as 
“normal” Kerberos. Sort of like migration mode does now. If the KDC could then 
signal IPA that a new principal was provisioned, IPA could allocate and 
harmonize an SID and a UID for the principal in the domain.


Poof. Console logins for Windows (pGina) and Linux (sssd) using IPA backed by 
your google account.  That just eliminated 98% of the external accounts you 
would have had to create and manage.

Food for thought.

Bryce

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal
Sent: Saturday, March 22, 2014 5:55 PM
To: Will Sheldon
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] About Windows client

On 03/22/2014 05:47 PM, Will Sheldon wrote:

I’d be curious to see how well a solution that combines pGina using RADIUS 
against some middleware like the Gluu server 
(www.gluu.orghttp://www.gluu.org)  backed by IPA would work.

This is not an interesting scenario. This would would probably work right now 
but the machine would still not know who the user is because it will not know 
user SID so he would be foreign and no Windows policies would apply to him. I 
suspect such user would have no or very limited read only access to Windows 
resources because all Windows ACLs are based on knowing the user SIDs and SIDs 
of the groups the user is a member of.
The value of native IdM integration would be to get user SID and SIDs of the 
groups from IdM and then get the right kerberos ticket(s) for Windows resources 
using cross realm kerberos trusts and put these tickets into the right place so 
that windows system can use them automatically when user navigates to the 
corresponding resource. Something like this.



It strikes me that getting domain federation between IPA and Gluu would tick a 
lot of boxes as it seems to offer a host of authentication and accounting 
interfaces including oAuth, SAML, OpenID and of course RADIUS.


Kind regards,

Will Sheldon
+1.778-689-1244


On Saturday, March 22, 2014 at 2:17 PM, Dmitri Pal wrote:
On 03/22/2014 01:18 PM, Arthur wrote:
Dmitri Pal wrote:
On 03/20/2014 11:15 PM, Arthur Faizullin wrote:
HI!
I've got some thoughts on 4-th point: there is a http://pgina.org/
pgina
project, may be them are able to do such thing.

Yes pgina is one of the options.
Someone would have to take it and integrate with MIT Kerberos for
Windows if it is not already doing so.
But I suspect that it would be more a project in itself that would
leverage code from MIT and may be pgina to integrate different parts.
The biggest part figuring out the domain affiliation. I mean the use
cases like this:
a) The system is domainless but user authentictaes with user name and
password against IPA
b) The system is domainless but user authentictaes with user name and
OTP against IPA
c) The system is in an AD domain trusted by IdM domain but user
authenticates with user name and password against IPA because he is
in IdM domain.
d) The system is in an AD domain trusted by IdM domain but user
authenticates with user name and password against IPA because he is
in IdM domain.

More to research. We can help with guidance if someone wants to run
with it.

Thanks
Dmitri


20.02.2014 04:23, Dmitri Pal пишет:
Hello,

I want to summarize our position regarding joining Windows systems
into IPA.

1) If you already have AD we recommend using this system with AD and
using trusts between AD and IPA.
2) If you do not have AD then use Samba 4 instead of it. It would be
great when Samba 4 grows capability to establish trusts. Right now it
can't but there 

Re: [Freeipa-users] Using external KDC

[Nordgren, Bryce L -FS]

I'm jumping in kind of late, but I may have a way for you to eliminate your 
current man in the middle password proxy.

  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.
 

First, I understand you to be saying that the University provides Kerberos 
authentication, but the associated id_provider either does not exist, is 
irrelevant to your situation, or you need to override/replace some values. If 
this is not correct, the remainder is unlikely to be applicable. Furthermore, 
some users allowed on your HPC cluster do not exist in the University system, 
so you need to be able to add users.

  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
 

First thing: emphasize in your deployment plan that you intend to eliminate 
your current password proxy. Gold star for you.

Second thing: you need two IPA instances because you have two realms. The first 
IPA instance manages the users from the University realm (for your machines 
only). The second IPA instance manages the extra users you plan on adding. The 
second instance also contains the machine entries for the nodes in your HPC 
cluster. For each user you intend to permit to use your cluster, you need to 
create an account in one of these IPAs.

Third: Configure sssd on your HPC nodes with a University realm. Your 
University realm should point auth_provider and chpass_provider 
krb5_server, and krb5_kpasswd  to your university's KDC, id_provider 
should be ipa, and should point to your very own HPC IPA. This will replace 
any id_provider information your university supplies, or create it if it does 
not exist.

Fourth: Configure sssd with an HPC Realm. Everything 
(auth_provider/id_provider) points to your HPC IPA instance.

Your University IPA instance manages a KDC. Ignore it. Never have your 
clients connect to it. You are interested in creating accounts having the same 
username as in the University's KDC. Just make it so that those users can't 
login using the IPA instance you set up. Give them random passwords which never 
expire. SSSD should take care of authenticating against the University.

You may also have to manually create the one-way Kerberos trust with the 
university using the MIT tools. This trust goes to the KDC managed by your 
HPC ipa instance.

It's probably not necessary to mess with a trust relationship between the two 
IPAs. Trust is a Kerberos thing, and only one of your IPAs has an important 
Kerberos store.

It may be useful to maintain the [capaths] section of krb5.conf on all your 
login appliances. It may not. Try it and let me know.

Your login node(s) will require network connectivity to the University's KDC. 
Other nodes will not. Once your users get a forwardable TGT from your HPC IPA 
(which they should get on login), they can directly authenticate to your 
cluster. Both of your IPA instances will need to be accessible from all nodes 
on your cluster.

This is just hypothetical. YMMV. I've been mulling over a similar problem for a 
long time, and I can't claim to have a perfect solution.

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.


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

Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites

[Nordgren, Bryce L -FS]

 But let me say I am not at all against having thesis' that explore some of 
 these
 theoretical questions, however one need to understand that the deliverable
 may end up being something that cannot be implemented or that it would
 require a long time to do so. As long as that is clear everything is game.

If it was a lock, it wouldn't make a good research topic. ;)

Deliverable could be an I-D which could eventually turn into an RFC at worst. 
At best, the student could adapt topology discovery algorithms from IP routers, 
adding in directionality and bindings between realm and dns names.

Bryce





This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

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

Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites

[Nordgren, Bryce L -FS]

 In the default case IPA, will automatically allocate a non conflicting range 
 to
 AD SIDs and pa SIDs to UIDs automatically. however if you want to use posix
 Ids stored in AD then yes, you will have to take care manually to avoid
 conflicts.

A perhaps doable, more applied thesis still requiring a substantial bit of work:

Posit a successful collaboration ecosystem that organizations are free to join 
or leave at will. Each realm must be free to use UID/GID of their choice 
without coordinating with all potential collaborators. The combination of 
UIDs/GIDs presented to individual machines still must not collide.

I think this could happen in IPA, assuming that all local machines and services 
authenticate with Kerberos. IPA would have to allocate a foreign principal 
record whenever the KDC was presented with a cross-realm TGT for a local 
service from a new foreign client (that may be tricky). IPA could manage the 
UID space for its own realm. Sssd would no longer need multiple realm entries 
and all relevant id_provider info could be synthesized at the realm level by 
IPA.

Effectively, the unique identifier for all external principles is 
username@REALM, with all the previously mentioned renaming problems. Local 
principals have their numeric id. But admins still shouldn't rename principals 
because they will cause problems for their collaborators.

Or, each machine could do it. It's a matter of deciding what the integration 
point is for cross-realm operation. That's pretty well defined for Kerberos 
(the KDC), and for the id provider (sssd). Trouble is, they're different 
integration points.


 Actually the solution to avoid capaths on clients is already planned, and it 
 is to
 stop having clients try to discover topology on their own at all. Clients 
 should
 always communicate with their KDC, and the KDC will issue referrals as
 appropriate. Once you do this capaths can be dismantled for the clients, the
 KDC will care for handling topology information.

I take it this is a reading assignment for RFC6806. :) I shall dive in.

 One small problem remains: how do I find the KDC if the realm name of the
 realm does not match the DNS domain name ? That is something that can be,
 perhaps resolved with some additional PA-DATA on the referrals if there is
 no other way.

Yeah. Also, the DNS domain name of a service may not match the DNS domain name 
of it's home KDC...

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

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

Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites

[Nordgren, Bryce L -FS]

  UID/GID solution
  https://fedorahosted.org/sssd/ticket/1715
  
  Chaining access providers:
  https://fedorahosted.org/sssd/ticket/1326
  I'm not sure these two are enough for a thesis..
 
  I think at least the first one is.
  You change UID and/or GID on the server. And then you need a
 mechanism
  to signal to the clients that they need to do cleanup. I was thinking
  about OpenLMI integration in this case and this sounds like a research
  topic to me.

 I see, this might be an interesting topic. I was initiall only thinking about 
 the
 change of the ID itself.

Something perhaps more worthy of thesis attention may be an examination of what 
it would take to start treating UID/GID as a completely internal machine 
representation which does not need to be shared. That is, it is important to 
have a common set of principal names for users, hosts and services in the 
Kerberos store; within an organization, it's important to have common groups of 
these principals in an LDAP store; but the importance of having all UIDs and 
GIDs be identical seems to be dwindling.

Authentication via Kerberos doesn't require it.
Authorization using Kerberos principals doesn't require it.
Moving files back and forth with SCP doesn't require it.
An NFSv4 fileserver w/krb5 security doesn't require it.
A CIFS fileserver doesn't require it.

What still requires that UID/GIDs need to be synchronized?

(I'm not necessarily asking you all right now. I think it might be a good 
thesis question, along with the follow-on: how much work would it take to 
migrate off of UID/GID synchronization for good?)

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.


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

Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites

[Nordgren, Bryce L -FS]

 You *could* build a system that can work w/o synchronization, if you
 carefully restrict what protocols and applications you use (think about
 distributed filesystems) although you'd still need a local persistent map at
 least. Backups and restore to other machines would need to be done
 carefully though, and so on.

I'm not suggesting that POSIX machines stop using UIDs internally. The local 
persistent map to a machine dependent representation will be necessary. It will 
also be necessary on Windows machines. And on mobile platforms. And within web 
applications. The shared items (principal names) would be common to all OSes 
and platforms though.

People trying to create heterogeneous environments are already carefully 
restricting protocols and applications to those which don't require sharing a 
UID map. File sharing via: Samba/CIFS, NFSv4, WebDAV, sftp (and 
sshfs(linux)/swish(Windows)). Logging into multiple machines has never involved 
knowing your UID, and ssh key pairs makes it more or less effortless to execute 
commands on another machine whether or not your username is the same, much less 
your UID. Kerberos SSO is more or less the same, but ensures that a common set 
of identities are recognized.

Ideally, if realm admins delegate authorization to the individual machines, the 
machines (regardless of OS) should be capable of functioning with only Kerberos 
authentication and without any centralized directory services. Minimal 
directory services could add group definitions via LDAP. A full AD/IPA solution 
would be needed to centralize authorization and/or enforce policy. Yet I still 
am not seeing the requirement for new deployments of cross-platform 
environments to manage internal user representations for a single os.

 However there are also issues with operations like 'renames', what happen
 when you change a user name or a group name ? You do not want to lose
 access to files when that happen, so you still need a unique identifier that 
 is
 not the everyday name (or forbid renames).

Presumably, you also would not want your Windows users to lose access to files 
after a rename, and Windows doesn't use UIDs. You also would not want to lose 
access to web apps, which do not use UIDs. You also don't want stale usernames 
to be sitting in access control lists (filesystem based or web app based). 
Retaining UIDs does nothing to make renaming more acceptable, because principal 
names are a realm-wide platform independent property, and UIDs are not.

 This is not an exhaustive list of course, and every problem can be probably
 worked around one way or another, however at the moment it is till easier
 to synchronize IDs than not ...

As I see it, for a cross-platform environment, every problem must be worked 
around regardless of whether you have to synchronize UIDs. Managing UIDs is 
just more work at the end, and it might be busywork. Determining whether it's 
busywork or not may make a good thesis topic. :)

It makes a good thesis topic because the central question is paradigm shifting: 
Draw a line between realm-wide properties and local machine representations of 
those properties, and ask Can each machine be made responsible for performing 
their own localizations for internal bookkeeping purposes? This would seem to 
be of particular interest to the type of crowd which would download and use a 
FreeIPA/sssd solution, but it may not be something they have the time to pursue.

:)
Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

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

Re: [Freeipa-users] local root can su to any IPA user

[Nordgren, Bryce L -FS]

 Caching credentials is disabled by default[1]. Even when credential caching is
 enabled, the cache is only ever readable by root, the hashes are
 *never* exposed to the system. FYI, the hash is a salted sha512.

Ah. Much better.

 What leads you to believe the cached credentials can be retrieved?

--- RedHat sssd documentation from [2] ---
Using a single user account. Remote users frequently have two (or even more) 
user accounts, such as one for their local system and one for the 
organizational system. This is necessary to connect to a virtual private 
network (VPN). Because SSSD supports caching and offline authentication, remote 
users can connect to network resources simply by authenticating to their local 
machine and then SSSD maintains their network credentials.
---End RedHat sssd documentation from [2] ---

Presumably VPN does not accept a hash. Even if it does, gaining access to the 
hash gains you admission to the network as someone else.

[2] 
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/SSSD.htm

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.


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

Re: [Freeipa-users] local root can su to any IPA user

[Nordgren, Bryce L -FS]

  Offline password caching is also optional and a different method.
  In this case the actual password is maintained in the kernel keyring
  in locked memory until the machine goes online and can acquire a TGT.
  On success it is deleted.
 
  however it doesn't really matter from an evil-root scenario, because
  evil-root will have already snatched the password from the PAM stack
  at authentication time.

Ah. My evil root scenario was that my AS exchange happened on my trusted 
machine and I used SSO to sign in to Evil root's machine. No password in Evil's 
pam stack. Evil can log into an Evil-compromised machine all he wants. Can't 
steal a password from yourself.

Please shoot holes in this design for me: :)

A domain uses Kerberos for authentication. The domain does not allow LDAP or 
other forms of authentication.

A domain has trusted, domain-administrated machines for initial sign on. Users 
are not given root access on these machines. Alternatively, users who have been 
given root access to a machine can initiate an AS exchange from machines they 
control, but others cannot and/or are strongly discouraged from doing so. 
Hence, a user can be granted control over their own workstation/laptop.

Users are given permissions on machines as needed to configure whatever it is 
that they need to do. Say there is some sort of project with specialized 
requirements which affects ~10-50 participants or so. Someone in the project 
stands up a machine to address the project's needs, but this person is not part 
of the Organization, so he could be Evil.

Users would be expected to perform their initial sign on using their own 
workstation/terminal, then connect to the project resource. Ideally, the 
project resource is a website of some type, so only a Kerberos service ticket 
is needed. In the case that project members need command line access, but no 
access to domain-wide services (like NFS server), they can just get a service 
ticket for host/evil.example@example.org.

So far, Evil is boxed in. Evil has not been given credentials which allow him 
to impersonate another user to the domain. Evil's box is a black hole. 
Identities go in, but they can't get out.

A problem occurs when users need to access domain-wide services from Evil's 
machine. The user (Innocent) can forward their TGT to Evil's machine, giving 
Evil full use of Innocent's identity, or Innocent can use their own, trusted 
workstation to individually request proxy tickets for the services Innocent 
intends to access.

Evil can now impersonate Innocent. In the case where Evil received proxy 
tickets, it can only impersonate Innocent to specific services on specific 
hosts. In the case where Evil received a TGT, Evil can impersonate innocent at 
will to any domain service.

This suggests that it should be a security requirement for 
non-organization-wide projects to provide their own services. This permits 
encouraging/mandating the use of service tickets with project resources. For 
instance, if the project needs file storage, they should provide file storage. 
Alternatively, if the organization wishes to provide storage, they may want to 
allocate servers (and Kerberos principals) individually for each project.

This seems to me to be a way to compartmentalize groups of cooperating users in 
a way that tends to prevent Evil in one group from spreading to another group, 
while allowing users to leverage the organization's identity store...It seems 
to me that this is even more effective at stopping the spread of Evil than 
establishing hierarchical cross-realm trusts underneath the main organization...

Am I overlooking something, or is this likely to be an effective means of 
delegating small project support while sideboarding potential Evil?

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.


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

Re: [Freeipa-users] local root can su to any IPA user

[Nordgren, Bryce L -FS]

 On Wed, Feb 26, 2014 at 04:24:54PM -0500, Steve Dainard wrote:
  Would it not be possible for root to disable selinux enforcement?

It should also be possible to copy private keys out of ~user/.ssh and login to 
other machines as user, assuming no password on the ssh key pair.

It's probably best to assume that all your client machines are under the 
control of knowledgeable, malicious admins, and to put your important 
information somewhere other than your client machines. The only real way to 
take back the night is to force your users to connect to a service you 
control using an authentication mechanism you control. (e.g., Kerberos service 
tickets: accept no substitute. :) ) Prohibiting them from making any changes 
makes you responsible for every last customization. Delegating frees you up, 
but requires trust. Probably a good rule of thumb is to be generous doling out 
permissions when only one person will ever use the machine. Giving someone 
control over someone else's workspace should require consent of the controlled.

One thing that is nagging at me: I read that sssd caches your credentials in a 
form such that they can be retrieved and provided to your organizational 
system. [1] This seems like a vector for a knowledgeable, malicious admin to 
break out of the client machine and impersonate someone else to any domain 
service. Is there a safeguard against this?

Bryce

[1] 
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/SSSD.html






This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.


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

Re: [Freeipa-users] local root can su to any IPA user

[Nordgren, Bryce L -FS]

 But I
 would argue that in this case root can just add some other module to the
 pam stack that would dump passwords for any user who uses pam stack
 regardless whether SSSD is in the picture or not so it is not SSSD problem and
 I do not think it can be generally solved with the software. It is the point
 where you cross the line into physical security and organization's security 
 and
 trust policies.

In a Kerberos/IdM/AD environment, the password isn't available except at 
initial sign on. If I sign on using my machine, then ssh to user Evil's 
machine, the worst user Evil can do is steal my TGT, which has a much shorter 
life than a password. If Evil is quick, he can get at my files on the main 
server. But I never give my password to user Evil in this situation, and user 
Evil is not an admin on my box, where he can affect the pam stack.

Thinking this through...This is definitely not a physical security thing: the 
machine was issued to user Evil and Evil must have physical access to it. These 
factors are not amenable to change. The problem is that risk and granting 
power are two sides of the same coin.  The challenge is to grant useful 
amounts of power while mitigating risk to others. For instance: the above 
description suggests that one way to mitigate risk is to not delegate 
administrative control over machines which handle other people's passwords. 
Whether this is policy or just good practice is perhaps a matter of 
semantics. Either way: Training the users to do the initial signon on their own 
box will go a long way to eliminating the need for a technical 
control...Definitely not a software problem...






This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.


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

Re: [Freeipa-users] Kerberized NFS Mount Issues

[Nordgren, Bryce L -FS]

I don't know if this is your issue, but I noticed this:

Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create krb5 
context for user with uid 0 for server nfs-server.example.local
Feb 15 23:43:23 nfs-client rpc.gssd[1123]: WARNING: Failed to create machine 
krb5 context with credentials cache

Who are you kinited as? Is your idmapper working on both client and server?

Bryce

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of re...@mccleary.me.uk
Sent: Sunday, February 16, 2014 4:49 AM
To: freeipa-users@redhat.com
Cc: re...@mccleary.me.uk
Subject: [Freeipa-users] Kerberized NFS Mount Issues

Hi,

I'm really stuck trying to get kerberized NFS configured via IPA and would be 
very grateful for any comments or advice based on the info I've provided below. 
 I'm sure this is a very popular kerberized service configured under IPA and I 
must be missing something obvious.

Thanks, Paul

### Background ###
I've configured IPA (3.0.0-37.el6) on CentOS 6.5 (2.6.32-431.3.1.el6.x86_64) 
and have an NFS server and an NFS client (both also CentOS 6.5) configured and 
working as IPA clients, e.g. can login as an IPA LDAP user.

I have tested plain NFSv4 and that works fine:
Code:

Testing Non-Kerberized NFS v4:
#
#
Client:
[root@nfs-client ~]# mount -v -t nfs4 -o rw,sec=sys nfs-server.example.local:/ 
/mnt
mount.nfs4: timeout set for Sat Feb 15 23:58:23 2014
mount.nfs4: trying text-based options 
'sec=sys,addr=10.50.0.18,clientaddr=10.50.0.11'
nfs-server.example.local:/ on /mnt type nfs4 (rw,sec=sys)
[root@nfs-client ~]# df -h /mnt
FilesystemSize  Used Avail Use% Mounted on
nfs-server.example.local:/  50G  14G  33G  30% /mnt
[root@nfs-client ~]# mount|grep nfs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
nfs-server.example.local:/ on /mnt type nfs4 
(rw,sec=sys,addr=10.50.0.18,clientaddr=10.50.0.11)

#
#
Server:
[root@nfs-server ~]# cat /etc/exports
/pmtest10.50.0.0/24(rw,sec=sys,fsid=0)

[root@nfs-server ~]# exportfs -v
/pmtest
10.50.0.0/24(rw,wdelay,root_squash,no_subtree_check,fsid=0,sec=sys,rw,root_squash,no_all_squash)

When I try to mount using kerberos it fails. I've searched for a number of days 
and tried many things, but am still stuck. The key error I think is in the NFS 
server syslog:
Code:

Feb 15 23:43:24 nfs-server rpc.svcgssd[6446]: ERROR: GSS-API: error in 
handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS 
failure.  Minor code may provide more information) - Wrong principal in request
Feb 15 23:43:24 nfs-server rpc.svcgssd[6446]: ERROR: GSS-API: error in 
handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS 
failure.  Minor code may provide more information) - Wrong principal in request

I don't understand how I have the wrong principal in the krb5.keytab. The 
various guides I've seen all have a similar keytab config as me, but I really 
hoped my first attempt using kerberos was going to be very easy as IPA would do 
all the hard stuff :-)

###
Output and Config Info From Failed Kerberized NFS mount:

Both client and server have secure NFS set to yes and name resolution is fine:
Code:

[root@nfs-client ~]# nslookup nfs-server
Server:10.50.0.20
Address:10.50.0.20#53

Name:  nfs-server.example.local
Address: 10.50.0.18

[root@nfs-client ~]# nslookup nfs-client
Server:10.50.0.20
Address:10.50.0.20#53

Name:  nfs-client.example.local
Address: 10.50.0.11


[root@nfs-server ~]# nslookup nfs-server
Server:10.50.0.20
Address:10.50.0.20#53

Name:  nfs-server.example.local
Address: 10.50.0.18

[root@nfs-server ~]# nslookup nfs-client
Server:10.50.0.20
Address:10.50.0.20#53

Name:  nfs-client.example.local
Address: 10.50.0.11

Code:

#
#
Client:
[root@nfs-client ~]# service iptables status;getenforce
iptables: Firewall is not running.
Disabled

Attempted mount:
[root@nfs-client ~]# mount -v -t nfs4 -o rw,sec=krb5 nfs-server.example.local:/ 
/mnt
mount.nfs4: timeout set for Sat Feb 15 23:45:23 2014
mount.nfs4: trying text-based options 
'sec=krb5,addr=10.50.0.18,clientaddr=10.50.0.11'
mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting nfs-server.example.local:/

/var/log/messages:
Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 
0x7fffaf4fac70 data 0x7fffaf4fab40
Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 
0x7fffaf4fac70 data 0x7fffaf4fab40
Feb 15 23:43:23 nfs-client rpc.gssd[1123]: dir_notify_handler: sig 37 si 
0x7fffaf4fac70 data 0x7fffaf4fab40
Feb 15 23:43:23 nfs-client 

Re: [Freeipa-users] Kerberized NFS Mount Issues

[Nordgren, Bryce L -FS]

You raise a good point regarding kinit - do I have to be kinit'ed in as anybody
before trying to mount the share?  I thought as the host and service principals
are in the /etc/krb5.keytab I didn't need to specifically authenticate against
 the IPA server? - I might be showing a fundamental lack of knowledge on how
 this all works, so would be good if someone could confirm or clarify this.

The big feature of NFSv4 w/krb security is per-user 
authentication/authorization. NFSv4 with sec=sys (and all NFS 4) use 
host-based authorization. I'm pretty sure you should be able to mount the NFS 
export without 'kinit'ing, but I'm also pretty sure it should look empty (or 
even give you permission denied until you kinit to someone authorized to 
access it.

I see you kinited to admin@EXAMPLE.LOCAL. If I'm not mistaken, this means 
that when you create files, NFS communicates the owner as 
admin@example.local. Your idmappers are probably trying to translate this to 
a local account called admin whenever evaluating permissions. If nfs-client 
and nfs-server can both getent passwd admin successfully, then you're 
probably OK. Otherwise, sssd may need some work...

But that shouldn't interfere with just mounting the share. (I just checked on 
my little test setup.) My little test setup doesn't involve IPA, it's just a 
couple of fedora20 VMs with mit krb5 and an nfs server. I did google this: 
http://www.cs.indiana.edu/~robh/nfsv4+rhel6.html

Note the part about the campus windows AD admins setting the 
NO_AUTH_DATA_REQUIRED flag for the machine accounts in AD. Is preauth turned 
off for your nfs/nfs-client and nfs/nfs-server... principals? I fear I'm 
ignorant of how this is done in IPA.

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.


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

Re: [Freeipa-users] One way trusts

[Nordgren, Bryce L -FS]

I think that the requirement is to have two distinct sets of users
while you don't have control over one set (AD users) but you have to
manage the other set (IPA users) somehow.

Yup.

I'm yet to see what is the benefit over having only IPA users. Given single 
sign-on wasn't a concern, it makes no difference then to specify IPA's user 
name during logon from AD machines, so no integration would really be needed.

Difference #1 (user experience): Users in AD do not have a new password to 
remember and/or manage.
Difference #2 (administration overhead): I don't have to create users which are 
already in AD.
Difference #3 (political): I'm not duplicating effort of our IT division, I'm 
serving an un-served community, so there's less turf violation.

An attempt to keep users in AD but use IPA features is really asking for 
collaboration between the two infrastructure setups.

Well, part of the confusion may lie in the fact that much of the functionality 
in IPA and AD is unfamiliar to me, particularly at the beginning. First and 
foremost, I'm viewing both AD and IPA as identity stores which can provide 
Authentication services and store some information about the users which can be 
used by clients for various purposes: access decisions being a big one. I've 
been using the LDAP interface to AD because it's easier to understand, and 
because I can graft in my external users via an LDAP metadirectory. This can 
be done without any infrastructure collaboration, and it provides support for 
applications which do not allow you to configure more than one domain.

Then I started looking at trying to authenticate using Kerberos. Didn't know 
much about Kerberos when I started. It's supposed to have all sorts of good 
features. But it also seems to be the layer that introduces the need to 
collaborate, where before there was none. Early testing seems to indicate that 
I can in fact kinit against AD using a machine not joined to the domain. This 
gets me a no-address, forwardable TGT, and should suffice to tell the machine 
that the AD server believes I'm me. I suspect I will run into problems if I 
then try to use my TGT to get a login ticket for this host-unknown-to-AD. I'm 
in the middle of trying to configure sssd on my test VM to use krb5/ldap 
authentication. It appears I cannot have sssd bind against AD's LDAP interface 
using Kerberos, or I just haven't figured out how, so the next step is to type 
my DN and password into another plain text file. Once this works, I'll 
configure IPA as a second domain on this host.

If machines on my research network (which does not share DNS namespace with AD) 
are joined to any domain, it would be to the FreeIPA domain. I do not quite 
understand the implications of this with regard to user principles from AD. It 
seems like it should be possible for me to make groups in FreeIPA which name 
members from other directories. It also seems like sssd should be capable of 
making access decisions based on a user principle from one domain and a group 
from another. But if I understand Kerberos correctly, it will be impossible for 
the FreeIPA TGS to issue a cross-realm ticket without the required cross realm 
trust and the associated remote principle entries in both directories.

I think my ability to make use of FreeIPA's extra (beyond authentication) 
functionality may depend on exactly where the access control decision is made, 
and how the information to support that decision is gathered. I'm hoping that 
sssd can be convinced to make these decisions based on information returned 
from an LDAP query on the freeIPA server and the TGT from the AD server. 
Contrary-wise, I'm hoping that I don't need a cross-realm Kerberos ticket from 
either domain.

Thanks for your patience. Sorry its taking so long to come up to speed.

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.


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

Re: [Freeipa-users] One way trusts

[Nordgren, Bryce L -FS]

 Both AD integration solutions we have (synchronization and
 cross-forest domain trusts) assume having higher level access
 privileges at the time integration is set up.

My problem here is that I'm too ignorable. :) There's over 15000 users in our 
AD; I'm in Montana, the admins are in DC. Worse, our agency's AD is being 
absorbed into the next level up the chain (Forest Service AD is going to become 
a part of the overall USDA AD). Then I'm an even smaller fish, relatively 
speaking.

 I'm unaware of other
 mechanisms that would give you the same flexibility and level of
 privilege separation between the AD and IPA domains.

?? The current solution using the LDAP interface to AD (and a metadirectory to 
merge external users) provides privilege separation and the flexibility to 
add external users. I don't need more; I just need it to be less clunky. It 
weakens security, of course, as my AD password is stored in various plaintext 
configuration files for each application needing binding credentials to search 
for users in AD. I also have an index to which files contain my password, as it 
forms a password-change-checklist which I need to run thru every 60 days.

If I might try to repeat the problem back to you to see if I got it right...the 
factor which requires access to the corporate AD is setting up a Kerberos cross 
realm trust. This is required so that machines in IPA can connect directly to 
AD for authentication. This in turn is necessary so that identities in the AD 
Kerberos Realm are correctly and consistently identified as being sourced from 
AD. And of course, this requirement is necessary for services in AD to 
recognize users and groups in AD.

Let me ask what is probably a series of dumb questions: What do I lose if my 
FreeIPA server is set up as one of the 10 machines I can join to the network as 
a regular user, and all the machines in IPA connect directly to IPA? Could 
FreeIPA (current or future) be configured to relay the credentials to AD either 
via Kerberos or using AD's LDAP interface (binding as itself because it's 
joined to the AD domain)?  If AD accepts the provided credentials can FreeIPA 
issue the user a ticket in the FreeIPA realm? Would this look to AD like a 
bunch of users are logging into the FreeIPA server machine?

I know this arrangement would sacrifice access to any of the AD services by 
AD-users-on-the-IPA network. That's fine. If it's technically feasible, tho, it 
gives me one server that can authenticate both corporate users and external 
users, and a central administration point for the external network. It also 
plainly differentiates between corporate users logged in on the corporate 
network, and corporate users logged in on the external network. I'd consider 
that a good thing. Finally, if this is possible, it seems to me that this 
stands a chance of reducing the number of places my password is stored in 
plaintext.

Bryce






This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.


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

[Freeipa-users] One way trusts

[Nordgren, Bryce L -FS]

Hello,

I manage a suite of machines and services which are used for collaborative 
projects with external partners. I want to allow users within our organization 
to authenticate with their existing Active Directory accounts, and I have set 
up an External Users LDAP directory to establish identities for our partners. 
I have an LDAP server set up which merges the two directories and which 
forwards requests on to the correct directory.

I like the idea of FreeIPA, however, I need support for a one-way trust. I 
don't have the ability to modify any entries in our AD server, but I do have a 
normal user account (hence I can bind to AD's LDAP interface). However, I think 
this is kind of  a moot point since external users should under no 
circumstances be allowed access to our internal network/services. Read-only 
access to AD is just peachy. I found this old message (June 2012) on your 
mailing list which suggests one-way trusts may be on your radar. [1] However, I 
looked through your Trac tickets and didn't see any follow up. Did I miss 
something? Is this already implemented, or are plans in place?

Thanks much,
Bryce

[1] https://www.redhat.com/archives/freeipa-users/2012-June/msg00206.html




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] One way trusts

[Nordgren, Bryce L -FS]

Hi Dimitri,

Just to be sure I understand.
You have internal users - they are in AD. You have external users - they are 
in LDAP.
You merge two directories and you want to replace this setup with IPA.

Yes.

It seems that to support your use case you would need to make the external 
users be IPA users and make AD and IPA trust each other.

I think I concur about migrating my external users into IPA and making IPA 
trust AD. I may be ignorant of some AD nuance, but I do not see why AD needs to 
trust IPA. AD does not need to trust my LDAP clients currently.

Also if external users do not authenticate using Kerberos (for example they 
always use a special portal) then it does not matter what trust is between AD 
and IPA because those users will not have kerberos tickets that are leveraged 
in SSO in trust case.

I want to be able to point either an LDAP or a Kerberos client at IPA, and have 
it authenticate my enterprise and external users for me. I'm not going to 
tangle with SSO at the moment. Right now, we're just establishing an identity 
store.

IPA can trust AD. Formally it is a mutual trust but in reality IPA does not 
have global catalog support for users in IPA to be able to access the 
resources in AD.

In many of the tutorials/HOWTOs, I see that there is a requirement to provide 
credentials having the permission to add a computer to the domain, or being a 
member of an AD administration group. I'm a lowly standard User in the AD. I 
don't know if that means I can add a computer to the domain or not. I know I 
lack the ability to edit AD entries that aren't mine, so I really need a 
solution that does not require creating a trust relationship inside AD.

Is there a way for me to comment out the AD-IPA trust creation, or would that 
break the IPA-AD trust?

Thanks much,
Bryce







This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.


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

[Freeipa-users] FreeIPA and abfab?

[Nordgren, Bryce L -FS]

In my previous message, I asked about one-way trust with AD to provide a means 
of extending our corporate AD with accounts for external cooperators. I 
expect this is just a technical matter: either FreeIPA supports it or not, and 
there's no conceptual obstacles. So, my password is the same, and everyone else 
needs a new account. Not ideal, but it's achievable fairly easily with existing 
tools.

But what I really really want is an identity provider for the edge of the 
enterprise, where I live. My password is the same and external users can also 
use their normal password. Essentially, I want a software suite which 
interfaces between the enterprise environment where everything is centrally 
managed, and a federated environment where there are too many organizations to 
shake a stick at.

I've been reading about Application Bridging for Federated Access Beyond Web 
(abfab). https://datatracker.ietf.org/wg/abfab/ It appears to me that the draft 
architecture document and the recently published RFCs (7055, 7056, 7057) 
defines a mechanism for enterprises to federate and opens up  a whole new 
application space. The big question is, should enterprise-centric management 
apps expand to include federation, or will a whole new crop of solutions pop 
up? Or, more pointedly, could this gap be filled by augmenting an enterprise's 
existing AD deployment with a federation-aware FreeIPA? Has FreeIPA considered 
moving into this space?

I can see several areas where a federation aware, AD compatible solution could 
add value to an organization:

Use case 1: Synchronizing enterprise IDs with IDs exposed to the federation. 
(Currently, we have AD credentials and SAML credentials, and they are not 
synched. And our SAML IdP does not participate in a federation.)

Use case 2:  Software can use SAML credentials for workstation logins (if the 
workstations are on the research net); and allow only internal users to use 
internal services.

Use case 3: Software provides access to internal + federated identities using 
LDAP, SAML, Kerberos, etc.


Food for thought. I know this isn't near term, but at this point, I'm just 
curious if people are even thinking along these lines?

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users