[Freeipa-users] Limiting group/user visibility

2011-11-30 Thread Lassi Pölönen
Hi,

I'm looking for implementing FreeIPA in an environment where there are
multiple customers in multiple organizations and a single organization
that manages the users, sets the access rights etc.

We don't have a centralized system currently so I will be starting from
the scratch in that sense. The first concern I've had so far is that we
don't want different customers to be able to find information about each
other. Currently in my test setup any user can find out every user in a
group if they know the group name and all the groups for each user if
they know the username. In some cases this might reveal information the
customer is not willing to share.

So are there ways to limit that e.g certain hosts/hostgroups or
users/usergroups see some defined subset of the directory? Or are there
some other suggested approaches? As the current setup relies on local
authentication, users naturally are able to find users/groups only on
servers they are able to log in and that is the level of confidentiality
we are looking for if possible


-Lassi Pölönen


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

Re: [Freeipa-users] Limiting group/user visibility

2011-11-30 Thread Lassi Pölönen

Hi,

that could be one option as well, not completely ruled out. But in some 
cases it is a bit too much overhead though. If there are multiple small 
organizations with only a handful of account and servers, setting up a 
dedicated HA instance for each one doesn't feel very cost effective as 
it would mean tens of those. Currently a single installation can't 
handle multiple realms, am I right?


-Lassi Pölönen

On 30.11.2011 21:01, Steven Jones wrote:

Hi,

I would have thought this was a case/design of separate realm's.

regards

Steven Jones

Technical Specialist - Linux RHCE

Victoria University, Wellington, NZ

0064 4 463 6272


From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on 
behalf of Lassi Pölönen [lassi.polo...@iki.fi]
Sent: Thursday, 1 December 2011 12:18 a.m.
To: freeipa-users@redhat.com
Subject: [Freeipa-users] Limiting group/user visibility

Hi,

I'm looking for implementing FreeIPA in an environment where there are
multiple customers in multiple organizations and a single organization
that manages the users, sets the access rights etc.

We don't have a centralized system currently so I will be starting from
the scratch in that sense. The first concern I've had so far is that we
don't want different customers to be able to find information about each
other. Currently in my test setup any user can find out every user in a
group if they know the group name and all the groups for each user if
they know the username. In some cases this might reveal information the
customer is not willing to share.

So are there ways to limit that e.g certain hosts/hostgroups or
users/usergroups see some defined subset of the directory? Or are there
some other suggested approaches? As the current setup relies on local
authentication, users naturally are able to find users/groups only on
servers they are able to log in and that is the level of confidentiality
we are looking for if possible


-Lassi Pölönen


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

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


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


Re: [Freeipa-users] manual client join

2011-11-30 Thread Rob Crittenden

Stephen Ingram wrote:

Looking at section 3.1 of the documentation I see the process for what
happens during a client setup. In cases where there is no ipa-client
support, this is likely the best option. Is there any more specific
documentation that details the exact procedure (i.e. how to import the
CA certificate, obtain services principals) of what happens during the
ipa-join process? I seem to remember this from version 1 and even
earlier versions of 2.x, but I can't find anywhere now.


Retrieve the CA certificate for the FreeIPA CA.

# wget -O /etc/ipa/ca.crt http://ipa.example.com/ipa/config/ca.crt

Create a separate Kerberos configuration to test the provided 
credentials. This enables a Kerberos connection to the FreeIPA XML-RPC 
server, necessary to join the FreeIPA client to the FreeIPA domain. This 
Kerberos configuration is ultimately discarded.


- Basically just copy a working krb5.conf to /etc/krb5.conf and set up 
sssd or nss_ldap as documented.


# kinit admin
# ipa-join -s ipa.example.com -b dc=example,dc=com

Or if using a one-time password you can skip the kinit and do

# ipa-join -s ipa.example.com -b dc=example,dc=com -w Secret123

ipa-join lets IPA know a host is enrolled and retrieves a host principal 
and stores it into /etc/krb5.keytab.


Enable certmonger, retrieve an SSL server certificate, and install the 
certificate in /etc/pki/nssdb.


# service messagebus start
# service certmonger start
# certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /etc/ipa/ca.crt
# ipa-getcert request -d /etc/pki/nssdb -n 'IPA Machine Certificate - 
client.example.com' -N 'cn=client.example.com,O=EXAMPLE.COM; -K 
host/client.example@example.com


Disable the nscd daemon.

# service nscd stop
# chkconfig nscd off

rob

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


Re: [Freeipa-users] manual client join

2011-11-30 Thread Stephen Ingram
Rob-

On Wed, Nov 30, 2011 at 12:04 PM, Rob Crittenden rcrit...@redhat.com wrote:
 Retrieve the CA certificate for the FreeIPA CA.

 # wget -O /etc/ipa/ca.crt http://ipa.example.com/ipa/config/ca.crt

 Create a separate Kerberos configuration to test the provided credentials.
 This enables a Kerberos connection to the FreeIPA XML-RPC server, necessary
 to join the FreeIPA client to the FreeIPA domain. This Kerberos
 configuration is ultimately discarded.

 - Basically just copy a working krb5.conf to /etc/krb5.conf and set up sssd
 or nss_ldap as documented.

 # kinit admin
 # ipa-join -s ipa.example.com -b dc=example,dc=com

 Or if using a one-time password you can skip the kinit and do

 # ipa-join -s ipa.example.com -b dc=example,dc=com -w Secret123

 ipa-join lets IPA know a host is enrolled and retrieves a host principal and
 stores it into /etc/krb5.keytab.

 Enable certmonger, retrieve an SSL server certificate, and install the
 certificate in /etc/pki/nssdb.

 # service messagebus start
 # service certmonger start
 # certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /etc/ipa/ca.crt
 # ipa-getcert request -d /etc/pki/nssdb -n 'IPA Machine Certificate -
 client.example.com' -N 'cn=client.example.com,O=EXAMPLE.COM; -K
 host/client.example@example.com

 Disable the nscd daemon.

 # service nscd stop
 # chkconfig nscd off

Thanks, but aren't some of these steps assuming that ipa-client has
been installed on the system? For instance, instead of # ipa-join -s
ipa.example.com -b dc=example,dc=com -w Secret123, can't I instead
use kadmin to retrieve the keytab and then securely copy it over to
the client system? And, in the case of the ca.crt, if there if IPA
itself is not installed, the ca would not go to /etc/ipa/ca.crt, no? I
realize that I will lose functionality by not having ipa-client, but
just trying to build a case for supporting legacy systems that I would
never want to take the time to adapt ipa-client for.

Steve

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


[Freeipa-users] winsync: only synchronize existing user accounts?

2011-11-30 Thread Aram J. Agajanian

Is is possible to configure an AD synchronization with IPA but only
for existing IPA accounts?  Our AD has a lot of user accounts that the
IPA won't need for now.  I don't want to automatically add all of the
additional user accounts to IPA.

I can set up new IPA user accounts with the ipa user-add command.
I would like to synchronize passwords from AD to IPA.

I am setting up RHEV 3 for Desktops and would like to try IPA for
authentication.

-- 
Aram J. Agajanian
Computer Science/UNIX Support
Academic Computing
State University of New York at New Paltz

Support the Free Software Foundation - www.fsf.org

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


Re: [Freeipa-users] ipa-client stall on 'args=getent passwd admin'

2011-11-30 Thread Craig T
brilliant! 

I checked /var/log/messages and found; 

Nov 30 10:33:58 chtvm-centos-6 sssd[be[teratext.saic.com.au]]: Starting up
Nov 30 10:33:58 chtvm-centos-6 kernel: sssd_be[1516]: segfault at 10 ip 
003a12a13eee sp 7fffdb5e3b60 error 4 in 
libldap-2.4.so.2.5.2[3a12a0+43000]
Nov 30 10:33:58 chtvm-centos-6 kernel: abrt-hook-ccpp[1598]: segfault at 0 ip 
0039fea800d2 sp 7fff4a1fc5f8 error 4 in libc-2.12.so[39fea0+175000]
Nov 30 10:33:58 chtvm-centos-6 kernel: Process 1598(abrt-hook-ccpp) has 
RLIMIT_CORE set to 1
Nov 30 10:33:58 chtvm-centos-6 kernel: Aborting core


I then upgraded openldap to openldap-2.4.23-19.el6.x86_64 and now the 
ipa-client-install script works perfectly ;)


Regards,

Craig




On Wed, Nov 30, 2011 at 12:39:38PM +0100, Jakub Hrozek wrote:
 On Tue, Nov 29, 2011 at 09:43:55PM -0500, Rob Crittenden wrote:
  Craig T wrote:
  Hi,
  
  I tried letting the client install go and it does eventually finish, 
  however SSSD_NSS queries don't work.
  See errors below;
  
  --
  [root@chtvm-centos-6 /]# ipa-client-install
  Discovery was successful!
  Hostname: chtvm-centos-6.example.com
  Realm: example.com
  DNS Domain: example.com
  IPA Server: chtvm-389.example.com
  BaseDN: dc=example,dc=com
  
  Continue to configure the system with these values? [no]: yes
  User authorized to enroll computers: admin
  Password for ad...@example.com:
  
  Enrolled in IPA realm example.com
  Created /etc/ipa/default.conf
  Configured /etc/sssd/sssd.conf
  Configured /etc/krb5.conf for IPA realm example.com
  SSSD enabled
  Kerberos 5 enabled
  Unable to find 'admin' user with 'getent passwd admin'!
  Recognized configuration: SSSD
  NTP enabled
  Client configuration complete.
  
  -
  File: /var/log/sssd/sssd_nss.log
  (Wed Nov 30 10:34:16 2011) [sssd[nss]] [nss_dp_reconnect_init] (0): Could 
  not reconnect to example.com provider.
  (Wed Nov 30 10:34:46 2011) [sssd[nss]] [nss_dp_reconnect_init] (0): Could 
  not reconnect to example.com provider.
  (Wed Nov 30 10:35:16 2011) [sssd[nss]] [nss_dp_reconnect_init] (0): Could 
  not reconnect to example.com provider.
  (Wed Nov 30 10:35:46 2011) [sssd[nss]] [nss_dp_reconnect_init] (0): Could 
  not reconnect to example.com provider.
  -
  File: /var/log/sssd/sssd_pam.log
  (Wed Nov 30 10:34:16 2011) [sssd[pam]] [pam_dp_reconnect_init] (0): Could 
  not reconnect to example.com provider.
  (Wed Nov 30 10:34:46 2011) [sssd[pam]] [pam_dp_reconnect_init] (0): Could 
  not reconnect to example.com provider.
  (Wed Nov 30 10:35:16 2011) [sssd[pam]] [pam_dp_reconnect_init] (0): Could 
  not reconnect to example.com provider.
  (Wed Nov 30 10:35:46 2011) [sssd[pam]] [pam_dp_reconnect_init] (0): Could 
  not reconnect to example.com provider.
  -
 
 Also the {nss,pam}_dp_reconnect_init functions are only called when the
 back end crashes and the other processes are reconnecting to a new back
 end instance.
 
 Can you check logs (/var/log/messages should have the info) if there are
 any messages indicating a crash?
 
 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users

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


[Freeipa-users] Solaris 10 as IPA Client?

2011-11-30 Thread Craig T
Hi,

Anyone had any success using Solaris 10 as a IPA client (using 
ipa-server-2.1.1-4.el6.x86_64)?
Does anyone have any more detailed documentation on the topic? I find that 
Section 3.3.1. Configuring Solaris 10 from the Identitiy Management Guide 
very light. 


#Solaris 10 (Newest Edition)
 Oracle Solaris 10 8/11 s10x_u10wos_17b X86
Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved.
  Assembled 23 August 2011


bash-3.2# ldapclient -v init chtvm-389.teratext.saic.com.au
Arguments parsed:
defaultServerList: chtvm-389.teratext.saic.com.au
Handling init option
About to configure machine by downloading a profile
No profile specified. Using default
Proxy DN: NULL
Proxy password: NULL
Authentication method: 0
No proxyDN/proxyPassword required
Shadow Update is not enabled, no adminDN/adminPassword is required.
About to modify this machines configuration by writing the files
Stopping network services
Stopping sendmail
stop: sleep 10 microseconds
stop: network/smtp:sendmail... success
Stopping nscd
stop: sleep 10 microseconds
stop: sleep 20 microseconds
stop: system/name-service-cache:default... success
Stopping autofs
stop: sleep 10 microseconds
stop: sleep 20 microseconds
stop: sleep 40 microseconds
stop: sleep 80 microseconds
stop: sleep 160 microseconds
stop: sleep 320 microseconds
stop: system/filesystem/autofs:default... success
ldap not running
nisd not running
nis(yp) not running
file_backup: stat(/etc/nsswitch.conf)=0
file_backup: (/etc/nsswitch.conf - /var/ldap/restore/nsswitch.conf)
file_backup: stat(/etc/defaultdomain)=0
file_backup: (/etc/defaultdomain - /var/ldap/restore/defaultdomain)
file_backup: stat(/var/nis/NIS_COLD_START)=-1
file_backup: No /var/nis/NIS_COLD_START file.
file_backup: nis domain is teratext.saic.com.au
file_backup: stat(/var/yp/binding/teratext.saic.com.au)=-1
file_backup: No /var/yp/binding/teratext.saic.com.au directory.
file_backup: stat(/var/ldap/ldap_client_file)=-1
file_backup: No /var/ldap/ldap_client_file file.
Starting network services
start: /usr/bin/domainname teratext.saic.com.au... success
start: sleep 10 microseconds
start: sleep 20 microseconds
start: sleep 40 microseconds
start: sleep 80 microseconds
start: sleep 160 microseconds
start: sleep 320 microseconds
start: sleep 640 microseconds
start: sleep 1280 microseconds
start: sleep 2560 microseconds
start: sleep 5120 microseconds
 start: sleep 1770 microseconds 
 start: network/ldap/client:default... timed out
 start: network/ldap/client:default... offline to disable   
 stop: sleep 10 microseconds
stop: sleep 20 microseconds
stop: sleep 40 microseconds
stop: sleep 80 microseconds
stop: sleep 160 microseconds
stop: sleep 320 microseconds
stop: sleep 640 microseconds
stop: sleep 1280 microseconds
stop: sleep 2560 microseconds
stop: sleep 890 microseconds
stop: network/ldap/client:default... timed out
start: sleep 10 microseconds
start: system/filesystem/autofs:default... success
start: sleep 10 microseconds
start: system/name-service-cache:default... success
start: sleep 10 microseconds
start: sleep 20 microseconds
start: network/smtp:sendmail... success
 restart: sleep 10 microseconds 
 restart: milestone/name-services:default... success
 Error resetting system.
 Recovering old system settings.
 Stopping network services  
Stopping sendmail
stop: sleep 10 microseconds
stop: network/smtp:sendmail... success
Stopping nscd
stop: sleep 10 microseconds
stop: sleep 20 microseconds
stop: system/name-service-cache:default... success
Stopping autofs
stop: sleep 10 microseconds
stop: sleep 20 microseconds
stop: sleep 40 microseconds
stop: sleep 80 microseconds
stop: sleep 160 microseconds
stop: sleep 320 microseconds
stop: system/filesystem/autofs:default... success
Stopping ldap
stop: sleep 10 microseconds
stop: sleep 20 microseconds
stop: sleep 40 microseconds
stop: sleep 80 microseconds
stop: sleep 160 microseconds
stop: sleep 320 microseconds
stop: sleep 640 microseconds
stop: sleep 1280 microseconds
stop: sleep 2560 microseconds
stop: sleep 890 microseconds
stop: network/ldap/client:default... timed out
Stopping ldap failed with (7)
Error (1) while stopping services during reset
recover: stat(/var/ldap/restore/defaultdomain)=0
recover: open(/var/ldap/restore/defaultdomain)
recover: read(/var/ldap/restore/defaultdomain)
recover: old domainname teratext.saic.com.au
recover: stat(/var/ldap/restore/ldap_client_file)=-1
recover: stat(/var/ldap/restore/ldap_client_cred)=-1
recover: