Re: [Freeipa-users] Apple OpenDirectory Integration

[Rob Crittenden]

"Răzvan Corneliu C.R. VILT" wrote:

Hi Guys,

I've done a small scale demo of using FreeIPA instead of an Open
Directory Server to serve Apple OS X clients. This is based on my
experiences from one year ago (Ticket #4813). I've also attached some
screenshots.


This is very cool and excellent work!

Currently the FreeIPA wiki points to 
http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 
for instructions on configuring MacOS. Are these sufficient to match 
what you've accomplished?



*Here's what works:*

  * Host sees the IPA Server
  * Host is able to register to the IPA server
  * Host creates a computer account (needs a bit of help here)
  * Host sets it's own random password (including kerberosPrincipalKey
and kerberosExtraData)
  * Host can see the users and other computers in the LDAP
  * Host can use TLS registration with FreeIPA's own root certificate as
found in cn=CACert,cn=ipa,cn=etc
  * Host can use just Kerberos for authentication and doesn't need an
Apple Password Server


*Here's what needs to be done to get there:*

  * Create a cn=config,$baseDN entry (attached example ldif). This can
be created automatically based on a template.
  * Create and ACI that gives anonymous read access to cn=config,$baseDN
(SNIP #3)
  * Modify an existing ACI to give altSecurityIdentities and description
to anonymous/public consumption (SNIP #4)
  * Extend the schema to include apple-configuration (SNIP #1)
  * Extend the schema to include apple-user (should be renamed to
apple-account since it applies also to hosts) (SNIP #2)
  * Add PLAIN to the supported SASL mechanisms (I don't know why it's
missing anyway because it's restricted to TLS by default). For me,
without further investigation of the reasons, I had to also disable
CRAM-MD5 and DIGEST-MD5 on the 389 DS.
  * Make sure (if you upgraded from a v3) that you have OCSP and/or CRL
working
  * Add an _ldap._tcp entry in avahi and/or server the LDAP server via
DHCP and/or serve the search domain via DHCP and make the DNS-SD
service entries for it.


*Here's what's missing from FreeIPA:*

A 389 Directory Server plugin that generates altSecurityIdentities and
AuthAuthority values automatically for an objectClass=apple-account.
This would automatically present the following entries (user admin used
as an example):
--
altSecurityIdentitites: Kerberos:ad...@example.org 
AuthAuthority: ;Kerberosv5;;ad...@example.org
;EXAMPLE.ORG ;
--
AuthAuthority is interesting because it supports not only basic LDAP
authentication, but also Kerberos, Netlogon and Apple Password Server
and you can specify multiple authentication authorities (including an
Active Directory).


Is this generally static data set once during user-creation? If so them 
the framework can manage it w/o requiring a 389-ds plugin which means it 
would be far easier to do.



A better way to specify homes for users. Not everyone uses automount and
automount maps (although OS X can use them). We need to be able to
specify not the assumably mounted home directory, but the protocol (afp,
nfs, cifs, etc.), server and share/directory. Furthermore, most Mac
Admins will have a heart-attack if they see an auto-mounted
/home/$username instead of the usual /Users/$username.


Not sure what you mean. Do you mean having a way to map it by client 
type? You may be able to do it by having client-type-based automount maps.



*Here's what's missing from OS X:*
A way to request OS X to do GSS-TSIG registration to the DNS. We may
have an MCX method to do that, but I haven't investigated. NSUpdate is
available and has support for gss-tsig. I think that for Active
Directory it does this automatically, and if so, we should be able to
reproduce it.

A way to specify that the fqdn argument should actually be an FQDN. We
might have to write a 389 DS plugin to take the CN without the final "$"
and add the domain name after it.

SUDO Map support. Currently, the only way to specify if an account has
sudo rights is to make it an admin. This makes it clear that without
Password Server support (partly implemented in the LPWS project), the
usage scenarios are limited to normal users and SSO to servers. OTOH, OS
X only knows admin and non-admin accounts, so it's not that bad.

*Steps to produce my demo install before the patches below:*
ipa-server-install -r EXAMPLE.ORG  -n example.org
 -p deadbeef -a deadbeef -P
deadbeef --hostname=ipa.example.org 
--ip-address=172.16.23.138 --ssh-trust-dns -U --setup-dns --no-forwarders

Is anyone from Red Hat willing to pick this up? It would be a nice
addition. If so, I am offering to do the testing and fine-tuning for all
post-Tiger releases. I can also share virtual machines for server and
client configuration.


I'd open one or more RFE tickets on 

Re: [Freeipa-users] Apple OpenDirectory Integration

[Alexander Bokovoy]

On Thu, 04 Feb 2016, "Răzvan Corneliu C.R. VILT" wrote:



On 4 feb. 2016, at 12:16, Rob Crittenden  wrote:
This is very cool and excellent work!


Thanks. I've done most of the R 1 year ago for a client that has a
medium Mac-only network. Since a year passed, I wanted to share my
results in order make sure that the information won't be lost or
obsoleted. Furthermore, FreeIPA is a wonderful piece of software that
is making the life of admins around the world easier and due to BYOD
policies Macs should get more love.


Currently the FreeIPA wiki points to
http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8
for instructions on configuring MacOS. Are these sufficient to match
what you've accomplished?


Nope, what I've accomplished is different. I've managed to get OS X
clients to register to the IPA server like it's an Open Directory
Server. No command line interaction on the clients at all. No need for
manual keytabs or manual file editing or PAM modules or Apple scripts.
Just click join in the System Preferences -> Users Preferences Pane.


A 389 Directory Server plugin that generates altSecurityIdentities and
AuthAuthority values automatically for an objectClass=apple-account.
This would automatically present the following entries (user admin used
as an example):
--
altSecurityIdentitites: Kerberos:ad...@example.org 
AuthAuthority: ;Kerberosv5;;ad...@example.org
;EXAMPLE.ORG ;
--



Is this generally static data set once during user-creation? If so
them the framework can manage it w/o requiring a 389-ds plugin which
means it would be far easier to do.


It's static data. It's a concatenation of multiple strings: a
hard-coded one, the uid and the realm. It only changes if you rename
the user account. It is used to route the authn phase to the Kerberos
account (no PAM configuration!!!).

I wonder if we should use CoS plugin to get this data added to user
entries instead of storing it in every single user's LDAP entry -- the
only thing that is different is uid but the rest is the same, right?




A better way to specify homes for users. Not everyone uses automount and
automount maps (although OS X can use them). We need to be able to
specify not the assumably mounted home directory, but the protocol (afp,
nfs, cifs, etc.), server and share/directory. Furthermore, most Mac
Admins will have a heart-attack if they see an auto-mounted
/home/$username instead of the usual /Users/$username.


Not sure what you mean. Do you mean having a way to map it by client
type? You may be able to do it by having client-type-based automount
maps.


OK. So on Linux you do an automount map for the file server with the
homes and state that the user home directory is in /home/$userName

On Windows, you give the home folder as \\server\share\folder, but
assume that the protocol is SMB/CIFS.

On Mac OS X, you give the protocol, the server and the share\folder.
You could use automount, but I've never seen any OS X admin do that.
Mainly because you loose the roaming ability (they call it file
synchronization). Mac OS X can use roaming profiles just like Windows.
They don't have to be mounted except at logon time which is important
for road-warriors. Since most Macs are laptops, the road-warrior
scenario is assumed. Otherwise, you just get local homes.

If you don't provide any share details, what happens? Will Mac OS X
would fill-in the defaults based on the user name?


I'd open one or more RFE tickets on https://fedorahosted.org/freeipa/newticket


One was already opened (https://fedorahosted.org/freeipa/ticket/4813)
and I'm in CC. Since nothing happened for 1 year after my offer to
document it, I've decided to start this thread.

It mostly boils down to IPA developers not really having access to Mac
OS X devices. And load of other tickets to solve, of course.


The Apple schemas are included in Apple's GPL code-drops for OpenLDAP if
anyone is wondering about licensing. We don't need the full schemas
because we can map most stuff to our own schema and it works brilliantly.


It is probably best to stick with the Apple schema otherwise there
could be pain later if something changes, requiring additional
mapping.


I wouldn't encourage it for two reasons:
1) The Apple schema is designed to be remapped to any other schema.
That's the point of cn=config. That's what I did. It describes the
attribute mappings to internal data structures. I've identified a
minimal number of apple-schema items that have no direct mapping to
freeIPA datastructures and documented them in the two schema expansions
in the email.
2) Using the Apple schema without remapping would duplicate a most of
the data and would make account maintenance and LDAP Browsing more
difficult in the future. Since Apple is flexible about the schema, why
shouldn't we use that?

Good points. Remapping is better from our perspective too.

--
/ Alexander Bokovoy

--
Manage 

Re: [Freeipa-users] Apple OpenDirectory Integration

[Răzvan Corneliu C.R. VILT]

>> It is probably best to stick with the Apple schema otherwise there could be 
>> pain later if something changes, requiring additional mapping.
> 
> I wouldn't encourage it for two reasons:
> 1) The Apple schema is designed to be remapped to any other schema. That's 
> the point of cn=config. That's what I did. It describes the attribute 
> mappings to internal data structures. I've identified a minimal number of 
> apple-schema items that have no direct mapping to freeIPA datastructures and 
> documented them in the two schema expansions in the email.
> 2) Using the Apple schema without remapping would duplicate a most of the 
> data and would make account maintenance and LDAP Browsing more difficult in 
> the future. Since Apple is flexible about the schema, why shouldn't we use 
> that?

If you open up the ldif file from the first email and base64 decode the entries 
you will see clear configuration directives such as below. These mean that you 
don't need to stick with Apple's schema and neither does Apple (for forward and 
backward compatibility):

OD Policy:
==

Denied SASL Methods


DIGEST-MD5
CRAM-MD5

Configured Security Level

Advisory Client Caching


Binding Required


Man In The Middle


No ClearText Authentications


Packet Encryption


Packet Signing



Directory Binding


LDAP Servers:
=
Here you list the replicas, read-only or read-write. For registration a r/w 
replica will be used, preferably the primary master.

IPaddresses

172.16.23.138

PrimaryMaster
ipa.example.org
ReplicaName
Master
Replicas


Kerberos KRB5.conf:
===
Since you can register to multiple realms at one on a Mac, you need to modify 
(and not replace) the krb5.conf file so they are including the information as 
opposed to the file.
edu.mit.kerberos

domain_realm

.example.org
EXAMPLE.ORG
example.org
EXAMPLE.ORG

libdefaults

default_realm
EXAMPLE.ORG

realms

EXAMPLE.ORG

KADM_List

ipa.example.org
172.16.23.138  

KDC_List

ipa.example.org
172.16.23.138





OD Config snipplets:

Server information used for LDAP binding.

Delay Rebind Try in seconds
0
Enable Use

Map Search Base
cn=config,dc=example,dc=org
OpenClose Timeout in seconds
15
Port Number
389
SSL

Search Timeout in seconds
120
Server
172.16.23.138
Server Mappings

Template Name
FreeIPA Server
Template Search Base Suffix
dc=example,dc=org
Template Version
1.0
UI Name
Example.ORG

OD Config Attribute Type Maps snipplet:
===
Open Directory also includes them, but they map to different attributes.

Attribute Type Map


Native Map

fqdn

Standard Name
dsAttrTypeStandard:RecordName


Native Map

ipaUniqueId

Standard Name
dsAttrTypeStandard:GeneratedUID


Native Map

sambaSID

Standard Name
dsAttrTypeStandard:SMBSID


Native Map


Group Object Classes
OR
Object Classes


ipaHost
krbPrincipal
krbPrincipalAux
apple-user
ieee802Device


Search Base

Re: [Freeipa-users] Apple OpenDirectory Integration

[Răzvan Corneliu C.R. VILT]

> On 4 feb. 2016, at 12:16, Rob Crittenden  wrote:
> This is very cool and excellent work!

Thanks. I've done most of the R 1 year ago for a client that has a medium 
Mac-only network. Since a year passed, I wanted to share my results in order 
make sure that the information won't be lost or obsoleted. Furthermore, FreeIPA 
is a wonderful piece of software that is making the life of admins around the 
world easier and due to BYOD policies Macs should get more love.

> Currently the FreeIPA wiki points to 
> http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 
> for instructions on configuring MacOS. Are these sufficient to match what 
> you've accomplished?

Nope, what I've accomplished is different. I've managed to get OS X clients to 
register to the IPA server like it's an Open Directory Server. No command line 
interaction on the clients at all. No need for manual keytabs or manual file 
editing or PAM modules or Apple scripts. Just click join in the System 
Preferences -> Users Preferences Pane.

>> A 389 Directory Server plugin that generates altSecurityIdentities and
>> AuthAuthority values automatically for an objectClass=apple-account.
>> This would automatically present the following entries (user admin used
>> as an example):
>> --
>> altSecurityIdentitites: Kerberos:ad...@example.org 
>> AuthAuthority: ;Kerberosv5;;ad...@example.org
>> ;EXAMPLE.ORG ;
>> --
>> 
> 
> Is this generally static data set once during user-creation? If so them the 
> framework can manage it w/o requiring a 389-ds plugin which means it would be 
> far easier to do.

It's static data. It's a concatenation of multiple strings: a hard-coded one, 
the uid and the realm. It only changes if you rename the user account. It is 
used to route the authn phase to the Kerberos account (no PAM configuration!!!).

> 
>> A better way to specify homes for users. Not everyone uses automount and
>> automount maps (although OS X can use them). We need to be able to
>> specify not the assumably mounted home directory, but the protocol (afp,
>> nfs, cifs, etc.), server and share/directory. Furthermore, most Mac
>> Admins will have a heart-attack if they see an auto-mounted
>> /home/$username instead of the usual /Users/$username.
> 
> Not sure what you mean. Do you mean having a way to map it by client type? 
> You may be able to do it by having client-type-based automount maps.

OK. So on Linux you do an automount map for the file server with the homes and 
state that the user home directory is in /home/$userName

On Windows, you give the home folder as \\server\share\folder, but assume that 
the protocol is SMB/CIFS.

On Mac OS X, you give the protocol, the server and the share\folder. You could 
use automount, but I've never seen any OS X admin do that. Mainly because you 
loose the roaming ability (they call it file synchronization). Mac OS X can use 
roaming profiles just like Windows. They don't have to be mounted except at 
logon time which is important for road-warriors. Since most Macs are laptops, 
the road-warrior scenario is assumed. Otherwise, you just get local homes.


>> Is anyone from Red Hat willing to pick this up? It would be a nice
>> addition. If so, I am offering to do the testing and fine-tuning for all
>> post-Tiger releases. I can also share virtual machines for server and
>> client configuration.
> 
> I'd open one or more RFE tickets on https://fedorahosted.org/freeipa/newticket

One was already opened (https://fedorahosted.org/freeipa/ticket/4813) and I'm 
in CC. Since nothing happened for 1 year after my offer to document it, I've 
decided to start this thread.

>> The Apple schemas are included in Apple's GPL code-drops for OpenLDAP if
>> anyone is wondering about licensing. We don't need the full schemas
>> because we can map most stuff to our own schema and it works brilliantly.
> 
> It is probably best to stick with the Apple schema otherwise there could be 
> pain later if something changes, requiring additional mapping.

I wouldn't encourage it for two reasons:
1) The Apple schema is designed to be remapped to any other schema. That's the 
point of cn=config. That's what I did. It describes the attribute mappings to 
internal data structures. I've identified a minimal number of apple-schema 
items that have no direct mapping to freeIPA datastructures and documented them 
in the two schema expansions in the email.
2) Using the Apple schema without remapping would duplicate a most of the data 
and would make account maintenance and LDAP Browsing more difficult in the 
future. Since Apple is flexible about the schema, why shouldn't we use that?


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

[Prasun Gera]

On Thu, Feb 4, 2016 at 4:23 PM, Nordgren, Bryce L -FS 
wrote:

> 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?
>
>
>
Yes, that would be OK. I think all I need is that the files touched inside
the container look consistent permissions-wise to files that you see on the
host, and vice-versa. As such, I don't need authentication inside the
container since we don't need to host any services in the container. I just
need 1:1 mapping for uid:gid for regular users.


> 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.
>
>
>
Yes, I've just got started with Docker, and trying to use it as a way to
isolate development environment. We have a tool which has some weird
toolchain dependencies (old versions of gcc, boost, bison, and possibly a
few others), which would make it very hacky to compile/run it natively on
all systems. I think docker solves that problem such that whenever the use
wants to use that tool, they can just drop into the docker container and
work there.


> 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] ca install fails upgrading to 4.2.0

[Robert van Veelen]

I reran the replica-install and interrupted the script to set debug=1. The
debug log didn't change very much at startup since the failure seems to
occur already in the pre-start selftest. So it is still the same
"java.lang.Exception: SystemCertsVerification: system certs verification
failure"

[04/Feb/2016:13:19:45][localhost-startStop-1]: SignedAuditEventFactory:
create()
message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Success][CertNickName=auditSigningCert
cert-pki-ca] CIMC certificate verification

java.lang.Exception: SystemCertsVerification: system certs verification
failure
at
com.netscape.cms.selftests.common.SystemCertsVerification.runSelfTest(SystemCertsVerification.java:198)
at
com.netscape.cmscore.selftests.SelfTestSubsystem.runSelfTestsAtStartup(SelfTestSubsystem.java:861)
at
com.netscape.cmscore.selftests.SelfTestSubsystem.startup(SelfTestSubsystem.java:1797)
at
com.netscape.cmscore.apps.CMSEngine.startupSubsystems(CMSEngine.java:1701)
at com.netscape.cmscore.apps.CMSEngine.startup(CMSEngine.java:1148)
at com.netscape.certsrv.apps.CMS.startup(CMS.java:200)
at com.netscape.certsrv.apps.CMS.start(CMS.java:1602)
at
com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114)
at javax.servlet.GenericServlet.init(GenericServlet.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
at
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
at
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
at
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
at
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123)
at
org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at
org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672)
at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
[04/Feb/2016:13:19:45][localhost-startStop-1]: SignedAuditEventFactory:
create()
message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure]
self tests execution (see selftests.log for details)

Where can I manually check the certificates that were imported from the
existing master?

-rob

On Tue, 2 Feb 2016 at 11:20 Martin Kosek  wrote:

> On 02/02/2016 11:51 AM, Robert van Veelen wrote:
> > Unfortunately not. I saw that thread and grabbed the patch and updated
> spec
> > to give it a try. Same issue.
> > cheers,
>
> Ah, pity. Let me CC Endi in this thread then. I suspect he will be
> interested
> in the same log files as in the referred thread.
>
> > On Tue, 2 Feb 2016 at 08:46 Martin Kosek  wrote:
> >
> >> On 02/02/2016 02:18 AM, Robert van Veelen wrote:
> >>> Hi,
> >>> I'm trying to create an ipa replica from
> >>> ipa-server-3.0.0-47/pki-ca-9.0.3-45 to
> >> ipa-server-4.2.0-15/pki-ca-10.2.5-6
> >>> and cannot get the install to complete. The CS is configured 

[Freeipa-users] Using external certificate in IPA 4.1

[Ossi Ahosalmi]

I'm trying to use our organizations wildcard certificate in IPA. 
Certificate is signed by a trusted CA.


Running:
ipa-server-certinstall -w -d 

with next combinations:

- separate .key, .crt and ca chain, all in PEM format
- .crt and ca bundled into one file, .key as a separate file
- everything bundled together into one .p12 pkcs12 file

I always end up with this error:

"The full certificate chain is not present in ."

My CA file contains the whole chain and works in all other programs, 
just not in IPA.



--
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] Apple OpenDirectory Integration

[Răzvan Corneliu C.R. VILT]

>> It's static data. It's a concatenation of multiple strings: a
>> hard-coded one, the uid and the realm. It only changes if you rename
>> the user account. It is used to route the authn phase to the Kerberos
>> account (no PAM configuration!!!).
> I wonder if we should use CoS plugin to get this data added to user
> entries instead of storing it in every single user's LDAP entry -- the
> only thing that is different is uid but the rest is the same, right?

Right. At least for single realms with no trust domains. If you have an 
identity from another realm, you need to use the KRB5 principal from that 
realm. So instead of mapping to the UID, we should map to the krbPrincipal.

The format for altSecurityIdentities is:
===
"Kerberos:" + $krbPrincipal
Or for certificate logon:
"X509:" + "CN=" + $issuerRDN + "CN=" + $subject. Such as:
"X509:CN=Apple Root CA,OU=Apple Certification Authority,O=Apple 
Inc.,C=USCN=com.apple.idms.appleid.prd.deadbeefdeadbeefdeadbeefdeadbeef"

It's identical to the altSecurityIdentities from MSDN and was adopted by Apple 
from Microsoft. See https://msdn.microsoft.com/en-us/library/cc220106.aspx
In theory it can also be used for SC Certificate logons (see above example). It 
is also used by iCloud for certificate logons.


The format for authAuthority is:
=
Kerberos

Minimal Kerberos:
";Kerberosv5;;" + $krbPrincipal + ";" + $realm + ";"

Fully compliant Kerberos:
";Kerberosv5;" + "0x"$GUID_HEX + ";" + $krbPrincipal + ";" + $realm + ";" + 
"Realm Public Key"
Documented on: 
https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-CH3-68599

Basic Authentication

Of no interest, just crypt(). Documented on:
https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-CH3-68270

Apple Password Server Authentication:
-
;ApplePasswordServer;0xfc001e291a400254ba69508,1024 65537 
1073536022652669667510124737971525265977003458292838259662475941942339637701783031842665637489899899968013535474647377427038990743911664412758698759306606987798849786426049586039725915353359580583450027978985802381494661566820916379229460639580871881869418576860074704243214464804408968770344748232621
 r...@ipa.example.com:172.23.36.138
Documented on: 
https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-CH3-68312
Partly implemented in https://code.google.com/archive/p/lpws but without an IPA 
Bridge.

Shadow Hash Authentication (used by local accounts):

;ShadowHash;HASHLIST:
Documented on:
https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-CH3-68474

Local Cached User Authentication (used by road-warrior scenarios on the local 
systems):
---
Documented on:
https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-CH3-68528

Netlogon Authentication (used by Active Directory)
--
;Netlogon;razvan.vilt;MYDOMAIN

iCloud Authentication (obvious)
---
;AppleID;razvan.v...@me.com

Disabled Authentication (this needs attention)
--
Basically put ";DisabledUser;;" in front of the previous authentication method.


>> OK. So on Linux you do an automount map for the file server with the
>> homes and state that the user home directory is in /home/$userName
>> 
>> On Windows, you give the home folder as \\server\share\folder, but
>> assume that the protocol is SMB/CIFS.
>> 
>> On Mac OS X, you give the protocol, the server and the share\folder.
>> You could use automount, but I've never seen any OS X admin do that.
>> Mainly because you loose the roaming ability (they call it file
>> synchronization). Mac OS X can use roaming profiles just like Windows.
>> They don't have to be mounted except at logon time which is important
>> for road-warriors. Since most Macs are laptops, the road-warrior
>> scenario is assumed. Otherwise, you just get local homes.
> If you don't provide any share details, what happens? Will Mac OS X
> would fill-in the defaults based on the user name?

It would create a local profile in /Users/$userName. Which in reality is what 
most Mac admins do anyway. Roaming profiles are not 

[Freeipa-users] what is the sudo rule runasuser local user account

[Rob Verduijn]

Hello,

I've noticed that the sudorule-add-runasuser no longer has en --external option

What is the current method to add a local service account to a sud
rule list so that users may run sudo as that service account (ie
apache or jboss)

Cheers
Rob Verudijn

-- 
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 Host isn't picking up the idduseroverrides

[Jakub Hrozek]

On Wed, Feb 03, 2016 at 11:10:50PM +, Simpson Lachlan wrote:
> When my users log into the IPA server, the id user over rides work.
> 
> But they don't when we log into a client host?
> 
> What are we doing wrong?
> 
> The overrides are in the "Default Trust View" so should be applied to all 
> hosts.
> 
> We are trying to find *why* and *where* this is failing, but without much 
> success.
> 
> >From what I've read, this should be controlled by the sssd service on the 
> >host, but if we run sssd -I to watch what happens during a failed login or a 
> >login that doesn't successfully get the id user over ride applied, we don't 
> >see any errors or log entries that would indicate why.
> 
> We see this:
> 
> [root@vmts-linux1 ~]# /usr/sbin/sssd -i
> [sssd[be[unix.example.org]]] [krb5_auth_store_creds] (0x0010): unsupported 
> PAM command [249].
> [sssd[be[unix.example.org]]] [krb5_auth_store_creds] (0x0010): password not 
> available, offline auth may not work.

This is unrelated.

> 
> But there isn't anything in any logs that would indicate there's a 
> communication happening between the host and the server that we can see.
> 
> We have tried sss_cache -E on the host to clear cache, but we still aren't 
> getting the over rides.

If you changed the client override to a non-default one, then you would
have to restart the client.

Can you enable sssd debugging as per:
https://fedorahosted.org/sssd/wiki/Troubleshooting
and either send it to the list or if there are confidential information,
send it to me directly? (Just note we're attending a conference now, so
answers might lag..)

-- 
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] what is the sudo rule runasuser local user account

[Rob Verduijn]

On Centos7.2 all patches applied I used the command:
ipa-client-install --enable-dns-updates

Rob

2016-02-04 16:45 GMT+01:00 Jakub Hrozek :
> On Thu, Feb 04, 2016 at 03:52:25PM +0100, Rob Verduijn wrote:
>> Hello,
>>
>> I've noticed that the sudorule-add-runasuser no longer has en --external 
>> option
>>
>> What is the current method to add a local service account to a sud
>> rule list so that users may run sudo as that service account (ie
>> apache or jboss)
>>
>> Cheers
>> Rob Verudijn
>
> I know I'm not answering your question but how did you configure the
> client side earlier? Did you use the native/legacy sudo ldap driver?
>
> The reason I'm asking this is that sssd only supports users it handles,
> so in the IPA case it only supports IPA users anyway..
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] what is the sudo rule runasuser local user account

[Rob Verduijn]

That does seem to work for me as well,
however I can only add the external user via the web-gui

Any idea how to do this with the command line tools ?

Rob Verduijn

2016-02-04 17:00 GMT+01:00 Baird, Josh :
> Actually, I use local (external) users in my sudo rules in IPA 4.2 with no 
> problem.
>
> Example:
>
>   Rule name: TestDBAs
>   Description: access for members of the TestDBAs group
>   Enabled: TRUE
>   Command category: all
>   User Groups: testdbas
>   Host Groups: corp_oracle
>   RunAs External User: oracle
>
> In this example, 'oracle' is a local user on the server (not in IPA).  I hope 
> this functionality does not go away.
>
> Thanks,
>
> Josh
>
>> -Original Message-
>> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
>> boun...@redhat.com] On Behalf Of Rob Verduijn
>> Sent: Thursday, February 04, 2016 10:54 AM
>> To: Jakub Hrozek
>> Cc: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] what is the sudo rule runasuser local user
>> account
>>
>> On Centos7.2 all patches applied I used the command:
>> ipa-client-install --enable-dns-updates
>>
>> Rob
>>
>> 2016-02-04 16:45 GMT+01:00 Jakub Hrozek :
>> > On Thu, Feb 04, 2016 at 03:52:25PM +0100, Rob Verduijn wrote:
>> >> Hello,
>> >>
>> >> I've noticed that the sudorule-add-runasuser no longer has en
>> >> --external option
>> >>
>> >> What is the current method to add a local service account to a sud
>> >> rule list so that users may run sudo as that service account (ie
>> >> apache or jboss)
>> >>
>> >> Cheers
>> >> Rob Verudijn
>> >
>> > I know I'm not answering your question but how did you configure the
>> > client side earlier? Did you use the native/legacy sudo ldap driver?
>> >
>> > The reason I'm asking this is that sssd only supports users it
>> > handles, so in the IPA case it only supports IPA users anyway..
>> >
>> > --
>> > Manage your subscription for the Freeipa-users mailing list:
>> > https://www.redhat.com/mailman/listinfo/freeipa-users
>> > Go to http://freeipa.org for more info on the project
>>
>> --
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] IPA-AD Login

[Alan P]

Hi, 

I just configured a trust between an IPA and an Active Directory to 
authenticate IPA users in Windows machines joined in AD domain. The login is 
successfull, but only after several minutes (nearly 25 minutes) in the first 
attempt; in the next attempts, the required time goes from 5 to 10 min. So, 
what can I do to reduce the time to something more acceptable? (For reference, 
when an AD user authenticates it only takes 10 seconds or less).

My environment is:

IPA server 4.2.0-15 in a RHEL 7.2
IPA domain is a subdomain of AD (like ad.example.com and ipa.ad.example.com)
There are, right now, a few users but is planed to manage more than 10,000
The trust was configured as "two way"

AD is in a Windows Server 2012
It has the root domain
I  made a domain delegation, so AD is authoritative for ad.example.com and IPA, 
for ipa.ad.example.com
All windows client machines are joined here
There are a few users, but they are only for test purposes

The authentication in a windows client is:
user: IPA.AD.EXAMPLE.COM\ipa.user
pass: ipa user pass

>From IPA console I can make kinit user...@ad.example.com with no problem.

Thanks.
Alan
  -- 
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-users] How to manage Linux attributes for AD users (e.g. how do I set a shell for an AD User)

[Jon]

Hello,

How does one manage linux attributes for AD users.  Primarily in my case,
I'm looking to change the default shell to either Bash or KSH depending on
the user.

I can create a .profile that either sources bash or ksh rcs... e.g.:

>> $ cat ~/.profile
>> bash ./.bashrc

This is really less than ideal and just seems like the wrong way to do it,
especially considering we have a tool like FreeIPA.

According to Microsoft
,
they are no longer supporting Identity Management for Unix.  Does FreeIPA
honor the attributes set by IDMU?  Even if it's deprecated, I suppose we
could continue to use it...
This previous FreeIPA thread
 seems
to indicate you can force the shell for anyone in the domain logging into
that machine, but we have some users who prefer one shell over the other.

I did what I believe to be standard, I created a security group in AD,
added that group to a group an external group in FreeIPA, then made an
internal group and added the external group as a member to the internal
group.  Unfortunately, this doesn't seem to expose any of the AD attributes
for management.  Or maybe I'm just misunderstanding...

Any thoughts?  How are you managing individual AD user settings?

Thanks,
Jon A
-- 
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-users] How to manage Linux attributes for AD users (e.g. how do I set a shell for an AD User)

[Baird, Josh]

For AD users, I believe you have two options.

1) Set the POSIX value on the user in AD for the shell
2) Set the following in your client's sssd.conf:

[nss]
override_shell = /bin/bash

This would obviously be global per IPA client.

Josh

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Jon
Sent: Thursday, February 04, 2016 2:25 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] [freeipa-users] How to manage Linux attributes for AD 
users (e.g. how do I set a shell for an AD User)

Hello,

How does one manage linux attributes for AD users.  Primarily in my case, I'm 
looking to change the default shell to either Bash or KSH depending on the user.

I can create a .profile that either sources bash or ksh rcs... e.g.:

>> $ cat ~/.profile
>> bash ./.bashrc

This is really less than ideal and just seems like the wrong way to do it, 
especially considering we have a tool like FreeIPA.

According to 
Microsoft,
 they are no longer supporting Identity Management for Unix.  Does FreeIPA 
honor the attributes set by IDMU?  Even if it's deprecated, I suppose we could 
continue to use it...
This previous FreeIPA 
thread 
seems to indicate you can force the shell for anyone in the domain logging into 
that machine, but we have some users who prefer one shell over the other.

I did what I believe to be standard, I created a security group in AD, added 
that group to a group an external group in FreeIPA, then made an internal group 
and added the external group as a member to the internal group.  Unfortunately, 
this doesn't seem to expose any of the AD attributes for management.  Or maybe 
I'm just misunderstanding...

Any thoughts?  How are you managing individual AD user settings?

Thanks,
Jon A

-- 
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] what is the sudo rule runasuser local user account

[Rob Verduijn]

hi all,

I tried and figured it out..

ipa sudorule-add-runasuser  --users=

Is the command syntax I was looking for.
I guess that if the --users isn't an ipa user it is automatically
flagged as an external user.

Cheers
Rob Verduijn




2016-02-04 17:33 GMT+01:00 Jakub Hrozek :
> On Thu, Feb 04, 2016 at 04:00:50PM +, Baird, Josh wrote:
>> Actually, I use local (external) users in my sudo rules in IPA 4.2 with no 
>> problem.
>>
>> Example:
>>
>>   Rule name: TestDBAs
>>   Description: access for members of the TestDBAs group
>>   Enabled: TRUE
>>   Command category: all
>>   User Groups: testdbas
>>   Host Groups: corp_oracle
>>   RunAs External User: oracle
>
> ipaSudoRunAsExtUser, ipaSudoRunAsExtGroup and ipaSudoRunAsExtUserGroup
> -- that's the user you want to run sudo as. That's still supported.

-- 
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] Using external certificate in IPA 4.1

[Martin Kosek]

On 02/03/2016 06:02 PM, Ossi Ahosalmi wrote:
> I'm trying to use our organizations wildcard certificate in IPA. Certificate 
> is
> signed by a trusted CA.
> 
> Running:
> ipa-server-certinstall -w -d 
> 
> with next combinations:
> 
> - separate .key, .crt and ca chain, all in PEM format
> - .crt and ca bundled into one file, .key as a separate file
> - everything bundled together into one .p12 pkcs12 file
> 
> I always end up with this error:
> 
> "The full certificate chain is not present in ."
> 
> My CA file contains the whole chain and works in all other programs, just not
> in IPA.
> 
> 

CCing Jan, but I think you are hitting
https://fedorahosted.org/freeipa/ticket/5603

-- 
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] Apple OpenDirectory Integration

[Mauricio Tavares]

I have a few Macs with 10.7 (mini) and 10.9 (MB air). Let me know if I
can help using them as guinea piggies

On Thu, Feb 4, 2016 at 11:57 AM, Alexander Bokovoy  wrote:
> On Thu, 04 Feb 2016, "Răzvan Corneliu C.R. VILT" wrote:
>>
>>
 It's static data. It's a concatenation of multiple strings: a
 hard-coded one, the uid and the realm. It only changes if you rename
 the user account. It is used to route the authn phase to the Kerberos
 account (no PAM configuration!!!).
>>>
>>> I wonder if we should use CoS plugin to get this data added to user
>>> entries instead of storing it in every single user's LDAP entry -- the
>>> only thing that is different is uid but the rest is the same, right?
>>
>>
>> Right. At least for single realms with no trust domains. If you have an
>> identity from another realm, you need to use the KRB5 principal from
>> that realm. So instead of mapping to the UID, we should map to the
>> krbPrincipal.
>
> Yep.
>
> I've moved the ticket 4813 to needs triage basket and referenced this
> thread.
>
>
>>
>> The format for altSecurityIdentities is:
>> ===
>> "Kerberos:" + $krbPrincipal
>> Or for certificate logon:
>> "X509:" + "CN=" + $issuerRDN + "CN=" + $subject. Such as:
>> "X509:CN=Apple Root CA,OU=Apple Certification Authority,O=Apple
>> Inc.,C=USCN=com.apple.idms.appleid.prd.deadbeefdeadbeefdeadbeefdeadbeef"
>>
>> It's identical to the altSecurityIdentities from MSDN and was adopted by
>> Apple from Microsoft. See
>> https://msdn.microsoft.com/en-us/library/cc220106.aspx
>> In theory it can also be used for SC Certificate logons (see above
>> example). It is also used by iCloud for certificate logons.
>>
>>
>> The format for authAuthority is:
>> =
>> Kerberos
>> 
>> Minimal Kerberos:
>> ";Kerberosv5;;" + $krbPrincipal + ";" + $realm + ";"
>>
>> Fully compliant Kerberos:
>> ";Kerberosv5;" + "0x"$GUID_HEX + ";" + $krbPrincipal + ";" + $realm + ";"
>> + "Realm Public Key"
>> Documented on:
>> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-CH3-68599
>>
>> Basic Authentication
>> 
>> Of no interest, just crypt(). Documented on:
>>
>> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-CH3-68270
>>
>> Apple Password Server Authentication:
>> -
>> ;ApplePasswordServer;0xfc001e291a400254ba69508,1024 65537
>> 1073536022652669667510124737971525265977003458292838259662475941942339637701783031842665637489899899968013535474647377427038990743911664412758698759306606987798849786426049586039725915353359580583450027978985802381494661566820916379229460639580871881869418576860074704243214464804408968770344748232621
>> r...@ipa.example.com:172.23.36.138
>> Documented on:
>> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-CH3-68312
>> Partly implemented in https://code.google.com/archive/p/lpws but without
>> an IPA Bridge.
>>
>> Shadow Hash Authentication (used by local accounts):
>> 
>> ;ShadowHash;HASHLIST:
>> Documented on:
>>
>> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-CH3-68474
>>
>> Local Cached User Authentication (used by road-warrior scenarios on the
>> local systems):
>>
>> ---
>> Documented on:
>>
>> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-CH3-68528
>>
>> Netlogon Authentication (used by Active Directory)
>> --
>> ;Netlogon;razvan.vilt;MYDOMAIN
>>
>> iCloud Authentication (obvious)
>> ---
>> ;AppleID;razvan.v...@me.com
>>
>> Disabled Authentication (this needs attention)
>> --
>> Basically put ";DisabledUser;;" in front of the previous authentication
>> method.
>>
>>
 OK. So on Linux you do an automount map for the file server with the
 homes and state that the user home directory is in /home/$userName

 On Windows, you give the home folder as \\server\share\folder, but
 assume that the protocol is SMB/CIFS.

 On Mac OS X, you give the protocol, the server and the share\folder.
 You could use automount, but I've never seen any OS X admin do that.

[Freeipa-users] client/authentication inside a docker container

[Prasun Gera]

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] what is the sudo rule runasuser local user account

[Baird, Josh]

Actually, I use local (external) users in my sudo rules in IPA 4.2 with no 
problem.

Example:

  Rule name: TestDBAs
  Description: access for members of the TestDBAs group
  Enabled: TRUE
  Command category: all
  User Groups: testdbas
  Host Groups: corp_oracle
  RunAs External User: oracle

In this example, 'oracle' is a local user on the server (not in IPA).  I hope 
this functionality does not go away.

Thanks,

Josh

> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Rob Verduijn
> Sent: Thursday, February 04, 2016 10:54 AM
> To: Jakub Hrozek
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] what is the sudo rule runasuser local user
> account
> 
> On Centos7.2 all patches applied I used the command:
> ipa-client-install --enable-dns-updates
> 
> Rob
> 
> 2016-02-04 16:45 GMT+01:00 Jakub Hrozek :
> > On Thu, Feb 04, 2016 at 03:52:25PM +0100, Rob Verduijn wrote:
> >> Hello,
> >>
> >> I've noticed that the sudorule-add-runasuser no longer has en
> >> --external option
> >>
> >> What is the current method to add a local service account to a sud
> >> rule list so that users may run sudo as that service account (ie
> >> apache or jboss)
> >>
> >> Cheers
> >> Rob Verudijn
> >
> > I know I'm not answering your question but how did you configure the
> > client side earlier? Did you use the native/legacy sudo ldap driver?
> >
> > The reason I'm asking this is that sssd only supports users it
> > handles, so in the IPA case it only supports IPA users anyway..
> >
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
> 
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] OS migration from Fedora to CentOS?

[Christophe TREFOIS]

Hi all,

We are currently running a 3-replica (all are setup with the —setup-ca flag) 
cluster on Fedora 21, with FreeIPA 4.1.4.

We would like to slowly upgrade to the new version and move away from Fedora to 
CentOS 7.2.

We were thinking of the following:

- Create 3 CentOS machines with —setup-ca flag so that our current cluster is 6.
The first CentOS VM would then probably update the DB schema to the new FreeIPA 
version.
- Remove the Fedora VMs 1 by 1 from the cluster using ipa-replica-manage del 

- Be happy?


1. Could you please advise if this is considered the safest practise?
2. Do we have to update to intermediate versions and if so how?

Could we do anything else?

Thank you for any hints,

Kind regards,

—
Christophe
-- 
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-users] Configuring Automount on Ubuntu Clients

[Jon]

Hello,

How do I configure automount for Ubuntu 14.04 clients?  My procedure on
CentOS has been: install free-ipa client, run ipa-client-install (auto
configures with dns discovery), run ipa-client-automount.  However, when I
run this on the ubuntu client, I receive the following errors:

>> root@ubuntu-1404-x8664:~# ipa-client-automount -U
>> Searching for IPA server...
>> IPA server: DNS discovery
>> Location: default
>> Configured /etc/nsswitch.conf
>> Configured /etc/default/nfs-common
>> Configured /etc/idmapd.conf
>> rpcidmapd failed to restart: Command '/usr/sbin/service rpcidmapd
restart ' returned non-zero exit status 1
>> rpcgssd failed to restart: Command '/usr/sbin/service rpcgssd restart '
returned non-zero exit status 1

As these are not the names of these services on Ubuntu, this will never
work.

>> root@ubuntu-1404-x8664:~# service idmapd restart
>> idmapd stop/waiting
>> idmapd start/running, process 428
>> root@ubuntu-1404-x8664:~# service gssd restart
>> stop: Unknown instance:
>> gssd start/running, process 567

Unfortunately, this appears to be hardcoded values in the install script:

>> 290 if statestore.has_state('rpcidmapd'):
>> 291 enabled = statestore.restore_state('rpcidmapd',
'enabled')
>> 292 running = statestore.restore_state('rpcidmapd',
'running')
>> 293 rpcidmapd = ipaservices.knownservices.rpcidmapd
>> 294 if not enabled:
>> 295 rpcidmapd.disable()
>> 296 if not running:
>> 297 rpcidmapd.stop()
>> 298 if statestore.has_state('rpcgssd'):
>> 299 enabled = statestore.restore_state('rpcgssd', 'enabled')
>> 300 running = statestore.restore_state('rpcgssd', 'running')
>> 301 rpcgssd = ipaservices.knownservices.rpcgssd

Is Ubuntu not supported with FreeIPA?  Is there an updated install script?
I installed the freeipa-client from public repos.

>> ii  freeipa-client
 3.3.4-0ubuntu3.1amd64FreeIPA
centralized identity framework -- client
>> ii  python-freeipa
 3.3.4-0ubuntu3.1amd64FreeIPA
centralized identity framework -- python modules

Thanks,
Jon A
-- 
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] what is the sudo rule runasuser local user account

[Baird, Josh]

Yeah, this seems strange:

  --externaluser=STRExternal User the rule applies to (sudorule-find only)
  --runasexternaluser=STR
External User the commands can run as (sudorule-find
only)
  --runasexternalgroup=STR
External Group the commands can run as (sudorule-find
only)

I'm not sure why those commands would be limited to sudorule-find only.

Josh

> -Original Message-
> From: Rob Verduijn [mailto:rob.verdu...@gmail.com]
> Sent: Thursday, February 04, 2016 11:13 AM
> To: Baird, Josh
> Cc: Jakub Hrozek; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] what is the sudo rule runasuser local user
> account
> 
> That does seem to work for me as well,
> however I can only add the external user via the web-gui
> 
> Any idea how to do this with the command line tools ?
> 
> Rob Verduijn
> 
> 2016-02-04 17:00 GMT+01:00 Baird, Josh :
> > Actually, I use local (external) users in my sudo rules in IPA 4.2 with no
> problem.
> >
> > Example:
> >
> >   Rule name: TestDBAs
> >   Description: access for members of the TestDBAs group
> >   Enabled: TRUE
> >   Command category: all
> >   User Groups: testdbas
> >   Host Groups: corp_oracle
> >   RunAs External User: oracle
> >
> > In this example, 'oracle' is a local user on the server (not in IPA).  I 
> > hope this
> functionality does not go away.
> >
> > Thanks,
> >
> > Josh
> >
> >> -Original Message-
> >> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> >> boun...@redhat.com] On Behalf Of Rob Verduijn
> >> Sent: Thursday, February 04, 2016 10:54 AM
> >> To: Jakub Hrozek
> >> Cc: freeipa-users@redhat.com
> >> Subject: Re: [Freeipa-users] what is the sudo rule runasuser local
> >> user account
> >>
> >> On Centos7.2 all patches applied I used the command:
> >> ipa-client-install --enable-dns-updates
> >>
> >> Rob
> >>
> >> 2016-02-04 16:45 GMT+01:00 Jakub Hrozek :
> >> > On Thu, Feb 04, 2016 at 03:52:25PM +0100, Rob Verduijn wrote:
> >> >> Hello,
> >> >>
> >> >> I've noticed that the sudorule-add-runasuser no longer has en
> >> >> --external option
> >> >>
> >> >> What is the current method to add a local service account to a sud
> >> >> rule list so that users may run sudo as that service account (ie
> >> >> apache or jboss)
> >> >>
> >> >> Cheers
> >> >> Rob Verudijn
> >> >
> >> > I know I'm not answering your question but how did you configure
> >> > the client side earlier? Did you use the native/legacy sudo ldap driver?
> >> >
> >> > The reason I'm asking this is that sssd only supports users it
> >> > handles, so in the IPA case it only supports IPA users anyway..
> >> >
> >> > --
> >> > Manage your subscription for the Freeipa-users mailing list:
> >> > https://www.redhat.com/mailman/listinfo/freeipa-users
> >> > Go to http://freeipa.org for more info on the project
> >>
> >> --
> >> Manage your subscription for the Freeipa-users mailing list:
> >> https://www.redhat.com/mailman/listinfo/freeipa-users
> >> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] client/authentication inside a docker container

[Jan Pazdziora]

On Thu, Feb 04, 2016 at 10:19:16AM -0500, Prasun Gera wrote:
> 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.

Are the hosts IPA-enrolled?

> The goal is to run the
> docker container such that when the user calls docker run,

Is any user allowed to run docker run? That seems like a security
issue.

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

So you want bash started in the container, with the uid:gid of the
person invoking the command? If the users are trusted to do docker
run, they can do

docker run -u $UID container bash

themselves.

But you likely do not want to give every user a way to run any command,
why not just use sudo, and

docker run -u $SUDO_UID container bash

in the script invoked with the sudo (untested)?

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

-- 
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] what is the sudo rule runasuser local user account

[Jakub Hrozek]

On Thu, Feb 04, 2016 at 03:52:25PM +0100, Rob Verduijn wrote:
> Hello,
> 
> I've noticed that the sudorule-add-runasuser no longer has en --external 
> option
> 
> What is the current method to add a local service account to a sud
> rule list so that users may run sudo as that service account (ie
> apache or jboss)
> 
> Cheers
> Rob Verudijn

I know I'm not answering your question but how did you configure the
client side earlier? Did you use the native/legacy sudo ldap driver?

The reason I'm asking this is that sssd only supports users it handles,
so in the IPA case it only supports IPA users anyway..

-- 
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] what is the sudo rule runasuser local user account

[Jakub Hrozek]

On Thu, Feb 04, 2016 at 04:00:50PM +, Baird, Josh wrote:
> Actually, I use local (external) users in my sudo rules in IPA 4.2 with no 
> problem.
> 
> Example:
> 
>   Rule name: TestDBAs
>   Description: access for members of the TestDBAs group
>   Enabled: TRUE
>   Command category: all
>   User Groups: testdbas
>   Host Groups: corp_oracle
>   RunAs External User: oracle

ipaSudoRunAsExtUser, ipaSudoRunAsExtGroup and ipaSudoRunAsExtUserGroup
-- that's the user you want to run sudo as. That's still supported.

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

[Prasun Gera]

On Thu, Feb 4, 2016 at 10:56 AM, Jan Pazdziora 
wrote:

> On Thu, Feb 04, 2016 at 10:19:16AM -0500, Prasun Gera wrote:
> > 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.
>
> Are the hosts IPA-enrolled?
>
> Yes.


> > The goal is to run the
> > docker container such that when the user calls docker run,
>
> Is any user allowed to run docker run? That seems like a security
> issue.
>
> Well any user that can do sudo should be able to run docker. Is there a
security issue with that ?


> > 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.
>
> So you want bash started in the container, with the uid:gid of the
> person invoking the command? If the users are trusted to do docker
> run, they can do
>
> docker run -u $UID container bash
>
> themselves.
>
> Yes, this is similar to the 3rd point I mentioned. The problem though is
that directory listings will not show names inside the container. They'll
only show uids and gids. NIS solves this as a quick hack, but is there
something better ? Permissions would still work since NFS is not
kerberized. Another issue I haven't figured out is how the user can get
sudo inside the container. If you start docker with the user's uid, I don't
know if there is a safe way for that user to get sudo inside. If you start
docker in the root shell, you can create the user with the uid:gid, add it
to sudoers, and then change to the user's shell ?


> But you likely do not want to give every user a way to run any command,
> why not just use sudo, and
>
> docker run -u $SUDO_UID container bash
>
> in the script invoked with the sudo (untested)?
>
> I didn't follow this. Can you explain a bit more ? In the default setup,
you anyway need sudo to run docker. What is the -u string here ?

--
> Jan Pazdziora
> Senior Principal Software Engineer, Identity Management Engineering, Red
> Hat
>
-- 
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] IPA 4.2: pki-tomcatd in terrible shape

[Timothy Geier]

Greetings all,

For the record,this is a CentOS 7.2 box with all current patches. 
(ipa-server-4.2.0-15.el7.centos.3.x86_64, etc.)

The situation is that pki-tomcatd on the lone CA server in our IPA cluster 
refuses to start cleanly.  The issues started earlier this week after the certs
subsystemCert, ocspSigningCert, and auditSigningCert all simultaneously expired 
without warning; apparently, certmonger failed to renew them automatically.  We
attempted timeshifting and following instructions for what appeared to be 
similar issues, but nothing at all has worked.  

Today, we attempted removing the certificates in question (of course, the files 
in /etc/pki/pki-tomcat/alias were backed up beforehand) and using certutil to 
issue new  certificates.   This process worked but pki-tomcatd is still 
refusing to start.  We can get IPA to run on this server by manually starting 
pki-tomcatd, running ipactl start, and then ctrl-c’ing it when it gets to 
"Starting pki-tomcatd" but this is not a tenable long-term solution.

Relevant log entries/information:

/var/log/pki/pki-tomcat/ca/debug:
Could not connect to LDAP server host ipa01.X.net port 636 Error 
netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1)
Internal Database Error encountered: Could not connect to LDAP server host 
ipa01.X.net port 636 Error netscape.ldap.LDAPException: IO Error 
creating JSS SSL Socket (-1)
Internal Database Error encountered: Could not connect to LDAP server host 
ipa01.X.net port 636 Error netscape.ldap.LDAPException: Authentication 
failed (49)

/var/log/pki/pki-tomcat/localhost.2016-02-04.log:
org.apache.catalina.core.StandardContext loadOnStartup
SEVERE: Servlet /ca threw load() exception
java.lang.NullPointerException

# getcert list:

Number of certificates and requests being tracked: 8.
Request ID '20151015022737':
status: MONITORING
ca-error: Error setting up ccache for "host" service on client using 
default keytab: Generic error (see e-text).
stuck: no
key pair storage: 
type=NSSDB,location='/etc/dirsrv/slapd-X-NET',nickname='Server-Cert',token='NSS
 Certificate DB',pinfile='/etc/dirsrv/slapd-X-NET/pwdfile.txt'
expires: 2017-10-15 02:09:06 UTC
track: yes
auto-renew: yes
Request ID '20151015022949':
status: MONITORING
ca-error: Error setting up ccache for "host" service on client using 
default keytab: Generic error (see e-text).
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB'
expires: 2017-10-15 02:09:10 UTC
track: yes
auto-renew: yes
Request ID '20160127202548':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert 
cert-pki-ca',token='NSS Certificate DB'
expires: 2034-02-11 19:46:43 UTC
track: yes
auto-renew: yes
Request ID '20160127202549':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB'
expires: 2017-12-25 04:27:49 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
track: yes
auto-renew: yes
Request ID '20160127202550':
status: MONITORING
ca-error: Server at 
"http://ipa01.X.net:8080/ca/ee/ca/profileSubmit; replied: Profile 
caServerCert Not Found
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert 
cert-pki-ca',token='NSS Certificate DB'
expires: 2017-10-04 02:28:53 UTC
track: yes
auto-renew: yes
Request ID '20160204165453':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert 
cert-pki-ca',token='NSS Certificate DB',pin set
certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert 
cert-pki-ca',token='NSS Certificate DB'
expires: 2016-05-04 16:40:23 UTC
track: yes
auto-renew: yes
Request ID '20160204170246':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert 

Re: [Freeipa-users] [freeipa-users] How to manage Linux attributes for AD users (e.g. how do I set a shell for an AD User)

[Jon]

Hi Josh,

I think that's exactly the problem though, how does one set POSIX
attributes in AD from Linux guests?

The RedHat documentation has a big warning that the Microsoft IDMU has been
deprecated.

>>
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/ex.sssd-ad-posix.html

Surely you're not suggesting manually editing the AD Schema...?

Also, another use case is ssh keys.  I'm not even sure that IDMU has an
option for "authorized_keys"  (and FreeIPA doesn't seem to honor what's in
.ssh/authorized keys...  when that file exists I always get prompted for a
password then access denied).

I'm sure there are other per-user level attributes that are required, home
directory perhaps?, but the two big ones are shell and ssh keys.  I can't
be the only one who has a use case for managing these attributes for Active
Directory users.

Thanks,
Jon A

On Thu, Feb 4, 2016 at 1:30 PM, Baird, Josh  wrote:

> For AD users, I believe you have two options.
>
>
>
> 1) Set the POSIX value on the user in AD for the shell
>
> 2) Set the following in your client's sssd.conf:
>
>
>
> [nss]
>
> override_shell = /bin/bash
>
>
>
> This would obviously be global per IPA client.
>
>
>
> Josh
>
>
>
> *From:* freeipa-users-boun...@redhat.com [mailto:
> freeipa-users-boun...@redhat.com] *On Behalf Of *Jon
> *Sent:* Thursday, February 04, 2016 2:25 PM
> *To:* freeipa-users@redhat.com
> *Subject:* [Freeipa-users] [freeipa-users] How to manage Linux attributes
> for AD users (e.g. how do I set a shell for an AD User)
>
>
>
> Hello,
>
>
>
> How does one manage linux attributes for AD users.  Primarily in my case,
> I'm looking to change the default shell to either Bash or KSH depending on
> the user.
>
>
>
> I can create a .profile that either sources bash or ksh rcs... e.g.:
>
>
>
> >> $ cat ~/.profile
>
> >> bash ./.bashrc
>
>
>
> This is really less than ideal and just seems like the wrong way to do it,
> especially considering we have a tool like FreeIPA.
>
>
>
> According to Microsoft
> ,
> they are no longer supporting Identity Management for Unix.  Does FreeIPA
> honor the attributes set by IDMU?  Even if it's deprecated, I suppose we
> could continue to use it...
>
> This previous FreeIPA thread
>  seems
> to indicate you can force the shell for anyone in the domain logging into
> that machine, but we have some users who prefer one shell over the other.
>
>
>
> I did what I believe to be standard, I created a security group in AD,
> added that group to a group an external group in FreeIPA, then made an
> internal group and added the external group as a member to the internal
> group.  Unfortunately, this doesn't seem to expose any of the AD attributes
> for management.  Or maybe I'm just misunderstanding...
>
>
>
> Any thoughts?  How are you managing individual AD user settings?
>
>
>
> Thanks,
>
> Jon A
>
>
>
-- 
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] PKINIT support in FreeIPA 4.2.0

[Nik Lam]

On Wed, Feb 3, 2016 at 8:08 PM, Sumit Bose  wrote:

> On Wed, Feb 03, 2016 at 10:29:49AM +1100, Nik Lam wrote:
> > Hello,
> >
> > I installed ipa-server on Centos 7.1 and later did and upgrade of the
> whole
> > system to Centos 7.2.
> >
> > I think the FreeIPA version changed from 4.1.0 to 4.2.0 between these
> > Centos/RHEL minor releases.
> >
> > We'd now like to try integrating with a 2FA provider via a radius proxy
> and
> > want to use anonymous PKINIT to secure the initial communications between
> > the client and the KDC.
> >
> > We've tried following the MIT Kerberos PKINIT configuration documentation
> >
> > http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html
> >
> > generating our own certs manually with openssl but haven't had any luck.
> > We're seeing this in the kdc log:
> >
> > preauth pkinit failed to initialize: No realms configured correctly
> for
> > pkinit support
>
> Which changes did you apply to krb5.conf? Did you use the IPA CA to sign
> the certificate or some other CA?
>
> >
> > I've noticed there are many new pkinit-related options that have been
> added
> > to the ipa-server-install script in 4.2.0, so it looks like PKINIT is
> > available in this version of FreeIPA. Is that the case?
>
> Which options are you referring to?
>
> bye,
> Sumit
>
> >
> > And if it is, what is the recommended way to enable it given that it
> seems
> > to have been disabled in the original install that I did? Or would it
> just
> > be easier to start from scratch with a 4.2.0 ipa-server-install? (It's a
> > test instance that doesn't have too much in it - it will take a several
> > hours to rebuild from scratch.)
> >
> > Regards,
> >
> > Nik
>
>
>
Thanks Sumit.

It sounds like PKINIT is available but clearly I'm doing it wrong.

 > Which changes did you apply to krb5.conf? Did you use the IPA CA to sign
the certificate or some other CA?

Actually, I modified the kdc.conf file - placed the kdc.pem, kdckey.pem and
cacert.pem files in /var/kerberos/krb5kdc/ that I generated via openssl
commands in the MIT Kerberos documentation. The only change to kdc.conf
file was to append the location of the kdckey.pem file to pkinit_identity.

  pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem
  pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem

became

  pkinit_identity =
FILE:/var/kerberos/krb5kdc/kdc.pem,/var/kerberos/krb5kdc/kdckey.pem
  pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem

Should I have been modifying krb5.conf instead? It aslo sounds like I need
to use a certificate signed by the IPAs CA - is this something that should
be generated using ipa-getcert? Or do I just find the IPA CA's private key
and use openssl following the MIT Kerberos documentation?

 > Which options are you referring to?

When I looked at the --help text for 4.1.0 and 4.2.0 versions of
ipa-server-install, I noticed that 4.2.0 has these in the "certificate
system options":

--no-pkinit disables pkinit setup steps

--pkinit-cert-file=FILE
File containing the Kerberos KDC SSL certificate and
private key

--pkinit-pin=PINThe password to unlock the Kerberos KDC private key

--pkinit-cert-name=NAME
Name of the Kerberos KDC SSL certificate to install


Seeing that first one, I was a little hopeful that pkinit is enabled by
default in 4.2.0 but on a fresh install I just tried, I'm still seeing the
following in krb5kdc.log when IPA is started up, so clearly it isn't.

  (Error): preauth pkinit failed to initialize: No realms configured
correctly for pkinit support

Regards,

Nik
-- 
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] Obtaining certificate private keys for Apache/etc.

[Rob Crittenden]

Christopher Young wrote:

Thanks.  That's good advice and good to know.  I'm going to be trying
to work this into an Ansible role, so having a command listing helps
alot.

That leads to a curious question if anyone has thought about building
an Ansible module(s) for manipulating FreeIPA objects.  I'm going to
do some searching for that.


To close the loop, the dfault cert in IPA clients is stored in an NSS 
database and NSS doesn't give up its private keys willingly. The only 
way to get them is to export to a PKCS#12 file using pk12util then 
extract them using openssl pkcs12.


rob



On Wed, Feb 3, 2016 at 3:12 AM, Martin Kosek  wrote:

On 02/03/2016 12:42 AM, Christopher Young wrote:

I've been doing some reading and perhaps I'm confusing myself, but I
couldn't find any definitive guide on how to go about doing what I
think it a pretty simple thing.

My ipa-client installs appear to generate a new TLS/SSL/PKI cert for
each host when they are registered.  I'd like to utilize that
certificate with Apache/tomcat/etc..  I'm aware of how to obtain the
certificate itself, however I'm not clear on how to obtain the private
key (in a format that I can use as well) that was used to generate the
certificate.

Would someone kindly point me in the right direction or ideally just
educate me on the command/options needed to do this.  In particular,
I'm looking to create pem files for both the key and cert for use with
Apache, but it would be useful to understand how to do it for other
stores as well.  (Hint: this would be great to just have in a document
that makes it clear). :)


Hi Chris,

I do not think it is a good idea to do what you are doing :-) The host
certificate does not need to be the same as Web certificate. From FreeIPA 4.1
(IIRC), it is not even requested by default on all clients.

I would rather recommend generating a separate certificate for the Web UI, we
have some walkthrough here:

http://www.freeipa.org/page/PKI#Requesting_a_new_certificate


Thanks again to the freeipa team.  I love this product.


And I love to hear notes from the community like this, very rewarding!




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