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
Just to be sure I understand.
You have internal users - they are in AD. You have external users - they are
You merge two directories and you want to replace this setup with IPA.
It seems that to support your use case you would need to make the external
users be IPA
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
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.
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.
I'm yet to see what is the benefit over having only IPA users. Given single
sign-on wasn't a concern, it makes
I don't know if this is your issue, but I noticed this:
Feb 15 23:43:23 nfs-client rpc.gssd: 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: WARNING: Failed to create machine
krb5 context with
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
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.
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
Caching credentials is disabled by default. 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
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
Chaining access providers:
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
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
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
But let me say I am not at all against having thesis' that explore some of
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
In the default case IPA, will automatically allocate a non conflicting range
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
A perhaps doable, more applied thesis still
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
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
Console logins in a
Back again. Thanks for your responses so far.
OTP is interesting, but requires that an account be created in the local
domain, which is kind of opposed to the notion of federated identities.
Ipsilon is also interesting, from its description as a gateway to non-Kerberos
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-
Ah. Well since that's the case, separate OUs are gone. (You may
Sorry for the delayed reply. This is other duties as assigned and the day job
got in the way. :) However, the computer is busy running fits to data for the
next day or so. My electronic master is thus distracted.
First of all thanks for a nice pictures and sharing your ideas.
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
I guess we just do not see this scenario in practice yet.
What I've found in the last decade is that scientists and CIO types cannot talk
for lack of a common language. CIO types believe in closed systems over which
they have complete control. Scientists are funded to work with others from
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
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
A4) IdP returns short-lived certificate (validity period matches
I've run out of time for today, but the external collaboration pages are slowly
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
in the future.
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal
Sent: Wednesday, May 14, 2014 4:13 PM
Subject: Re: [Freeipa-users] External collaboration edits
On 04/19/2014 07:46 PM, 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
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.,
When thinking about gateways and what Ipsilon may do, I came across this thesis:
His approach to unifying web and non-web technologies was to build gateways for
non-web services such that browser based clients
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
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
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
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
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,
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
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
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
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
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
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.
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
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
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
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
Can you please open a selinux bug and attach info on how you fixed it ?
Presumably a corresponding bug could be opened for Fedora 19 and/or RHEL 7, but
I could be wrong.
This electronic message contains information generated by the USDA solely
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
As a result, any change in FQDN will break your Kerberos setup.
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
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,
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
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Monday, August 25, 2014 3:04 AM
To: Nordgren, Bryce L -FS
Cc: 'email@example.com'; 'sssd-us...@lists.fedorahosted.org'
Subject: Re: [Freeipa-users] A prototype of merged domains (views)
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
Sweet! Yes I am apparently talking about that. Consider this an independent
request for that. :)
You are talking about this, right?
This electronic message contains information generated by the USDA solely for
the intended recipients. Any
Overwriting certain attributes may be more directly addressed by:
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
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.
I went through this thread:
Since January, I've been turning this problem over and over. A good summary of
my functional requirements is here:
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
From: Alexander Frolushkin [mailto:alexander.frolush...@megafon.ru]
Sent: Sunday, April 12, 2015 9:27 PM
To: Nordgren, Bryce L -FS; 'Martin Kosek'; firstname.lastname@example.org
Subject: RE: [Freeipa-users] user account without password
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
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
My guess aligns with this response:
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Winfried de Heiden
Mail list logo