[Freeipa-users] Logging of Who does What on IPA Server

[Rajnesh Kumar Siwal]

IPA is going to be very critical Server for any environment.
Do we have proper logging of who as locked whom, Who has created a
sudo policy, who has allowed access to whom etc ?
-- 
Regards,
Rajnesh Kumar Siwal

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

Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC

[Steven Jones]

Hi,

However trusts open a whole nest of vipers...

The advantage of using winsync is you can control what happens in IPA, so if AD 
say gets hacked anything in IPA probably will survive.  

The reverse is of course also true

;]

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 Dmitri Pal [d...@redhat.com]
Sent: Thursday, 14 February 2013 11:24 a.m.
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and 
Solaris RBAC

On 02/13/2013 09:58 AM, Dag Wieers wrote:
> Hi,
>
> We are investigating whether IPA is an acceptable solution for our
> environment. One of the aspects that is not clear (from reading the
> documentation and testing it without AD) is whether the
> synchronization with AD can be limited to a subset.
>
>
> Since we would like to only synchronize certain user-accounts
> (conforming to a specific format) from AD unidirectionally, and we
> also want to manage functional/technical accounts on IPA, we need to
> make sure that we:
>
>  - can filter the stuff we pull from AD
>  - can avoid the synchronisation to remove other accounts managed in IPA
>
> Can someone confirm that this is possible ? Is there any indepth
> information on how this AD sycnhronization works (preferably about
> RHEL6 IPA) ?
>
>
> Also since we also require compatibility with Solaris, and roles
> (RBAC) is currently used on Solaris, does IPA support RBAC on Solaris
> ? (We noticed that RBAC mentioned in the IPA web interface only
> relates to IPA management).
>
>
> Thanks in advance,
If you are planning to use latest bits from upstream you also can
consider using trusts and PAM passthough instead of password
synchronization.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



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



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

Re: [Freeipa-users] Unable to enrol servers with principal

[Dmitri Pal]

On 02/13/2013 04:57 PM, Charlie Derwent wrote:
>
>
> On Sun, Feb 10, 2013 at 1:48 AM, Rob Crittenden  > wrote:
>
> Charlie Derwent wrote:
>
> Hi
> Whenever I attempt an unattended installation with a principal and
> password. The installation fails.
> I'm using the following syntax for my command
> ipa-client-install --domain=example.com 
> 
> --server=ipa.example.com 
>  --realm=EXAMPLE.COM 
>  --principal=user --password=pass -U
> --ntp-server=123.123.123.123 --mkhomedir
> --hostname=server1.example.com 
> 
>
> The error I get varies between (in order of frequency)
> Joining realm failed: /usr/sbin/ipa-join: symbol lookup error:
> /usr/sbin/ipa-join: undefined symbol: xmlrpc_server_info_set_user
> and
>
>
> This is the sort of thing that if you saw once, you should see
> every time. What version of xmlrpc-c-client is installed?
>
>  
>
> I agree I should be seeing it all the time it's very odd that I'm not,
> the package is xmlrpc-c-client-1.16.24-1206.1840.4.el5.x86_64.rpm 
>
>
> kinit(v5): Password incorrect while getting initial credentials
> and
> Password expired. you must change it now.
> kinit(v5): Cannot read password while getting initial credentials
> The password is 100% right as I can kinit on other servers and
> access
> the webgui with the same details.
> OTP's work flawlessly.
>
>
> The KDC log might have more information.
>
> I'm not in the office right now so I can't check the logs but I assume
> the KDC log is actually on the IPA server?

yes
and the DS access logs too
>  
> Thanks
> Charlie
>
>  
>
>
>  
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



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

Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC

[Dmitri Pal]

On 02/13/2013 09:58 AM, Dag Wieers wrote:
> Hi,
>
> We are investigating whether IPA is an acceptable solution for our
> environment. One of the aspects that is not clear (from reading the
> documentation and testing it without AD) is whether the
> synchronization with AD can be limited to a subset.
>
>
> Since we would like to only synchronize certain user-accounts
> (conforming to a specific format) from AD unidirectionally, and we
> also want to manage functional/technical accounts on IPA, we need to
> make sure that we:
>
>  - can filter the stuff we pull from AD
>  - can avoid the synchronisation to remove other accounts managed in IPA
>
> Can someone confirm that this is possible ? Is there any indepth
> information on how this AD sycnhronization works (preferably about
> RHEL6 IPA) ?
>
>
> Also since we also require compatibility with Solaris, and roles
> (RBAC) is currently used on Solaris, does IPA support RBAC on Solaris
> ? (We noticed that RBAC mentioned in the IPA web interface only
> relates to IPA management).
>
>
> Thanks in advance,
If you are planning to use latest bits from upstream you also can
consider using trusts and PAM passthough instead of password
synchronization.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



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

Re: [Freeipa-users] Unable to enrol servers with principal

[Charlie Derwent]

On Sun, Feb 10, 2013 at 1:48 AM, Rob Crittenden  wrote:

> Charlie Derwent wrote:
>
>> Hi
>> Whenever I attempt an unattended installation with a principal and
>> password. The installation fails.
>> I'm using the following syntax for my command
>> ipa-client-install --domain=example.com 
>> --server=ipa.example.com  --realm=EXAMPLE.COM
>>  --principal=user --password=pass -U
>> --ntp-server=123.123.123.123 --mkhomedir --hostname=server1.example.com
>> 
>>
>> The error I get varies between (in order of frequency)
>> Joining realm failed: /usr/sbin/ipa-join: symbol lookup error:
>> /usr/sbin/ipa-join: undefined symbol: xmlrpc_server_info_set_user
>> and
>>
>
> This is the sort of thing that if you saw once, you should see every time.
> What version of xmlrpc-c-client is installed?
>
>
>
I agree I should be seeing it all the time it's very odd that I'm not, the
package is xmlrpc-c-client-1.16.24-1206.1840.4.el5.x86_64.rpm

>
>  kinit(v5): Password incorrect while getting initial credentials
>> and
>> Password expired. you must change it now.
>> kinit(v5): Cannot read password while getting initial credentials
>> The password is 100% right as I can kinit on other servers and access
>> the webgui with the same details.
>> OTP's work flawlessly.
>>
>
> The KDC log might have more information.
>
I'm not in the office right now so I can't check the logs but I assume the
KDC log is actually on the IPA server?

Thanks
Charlie

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

Re: [Freeipa-users] Account Expiration

[Rob Crittenden]

James James wrote:

What is the IIRC docs ?


IIRC == If I Recall Correctly.

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html-single/Identity_Management_Guide/index.html#pwd-expiration

rob




2013/2/13 Rob Crittenden mailto:rcrit...@redhat.com>>

Petr Spacek wrote:

On 12.2.2013 20:21, John Dennis wrote:

On 02/12/2013 01:40 PM, Rob Crittenden wrote:

Is it possible to ipa to send a email to user when
his account is about
to expire (the current date is near
krbprincipalexpiration date) ?


Not currently. In 3.0+ we will provide a notice when one
logs into the
WebUI but that's it.

We can't be sure that an MTA is properly configured on
the IPA server at
install time so we have punted on this for a while. We
don't want to get
into the business of picking and configuring one. This
is one of those
things that seems really easy but gets complicated the
deeper you dig
into it. We're open to suggestions/patches.


Yeah, I don't think we want to be in the business of
installing and
configuring an MTA. However, we should be able to detect if
one is
available
and use it if it is. I think it would be reasonable to
restrict it to
LMTP
with a Unix domain socket (most MTA's support this). Then
our config
would
have a LMTP domain socket pathname, if that pathname exists
and we can
connect
to it we use, if not we fallback to not generating any mail.


In meanwhile, it should be relatively simple to code script
which does
ldapsearch from time to time and sends some e-mails. This script
doesn't
have to run on the same server as IPA, only access to LDAP and
some MTA
is required.


Yes, that is our current recommendation. There is a sample query in
the docs IIRC.

rob


_
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] Account Expiration

[James James]

thanks for your code. :)


2013/2/13 Jan-Frode Myklebust 

> On Wed, Feb 13, 2013 at 09:29:42AM +0100, Petr Spacek wrote:
> > >
> > >Yeah, I don't think we want to be in the business of installing and
> > >configuring an MTA. However, we should be able to detect if one is
> available
> > >and use it if it is. I think it would be reasonable to restrict it to
> LMTP
> > >with a Unix domain socket (most MTA's support this). Then our config
> would
> > >have a LMTP domain socket pathname, if that pathname exists and we can
> connect
> > >to it we use, if not we fallback to not generating any mail.
> >
> > In meanwhile, it should be relatively simple to code script which
> > does ldapsearch from time to time and sends some e-mails. This
> > script doesn't have to run on the same server as IPA, only access to
> > LDAP and some MTA is required.
>
> Crude, but a start:
>
> 
> #! /bin/bash
> ldapsearch -z 500 -x -h ipa1.example.net -b
> cn=users,cn=accounts,dc=example,dc=net "(krbPasswordExpiration<=$(date
> +%Y%m%d --date='+1 week')00Z)" mail |grep ^mail|cut -d: -f2 |while read
> mail
> do
> echo password expires in less than a week | mail -s "Password
> expires" $mail
> done
> 
>
>
>
>   -jf
>
> ___
> 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] Account Expiration

[James James]

What is the IIRC docs ?


2013/2/13 Rob Crittenden 

> Petr Spacek wrote:
>
>> On 12.2.2013 20:21, John Dennis wrote:
>>
>>> On 02/12/2013 01:40 PM, Rob Crittenden wrote:
>>>
 Is it possible to ipa to send a email to user when his account is about
> to expire (the current date is near krbprincipalexpiration date) ?
>

 Not currently. In 3.0+ we will provide a notice when one logs into the
 WebUI but that's it.

 We can't be sure that an MTA is properly configured on the IPA server at
 install time so we have punted on this for a while. We don't want to get
 into the business of picking and configuring one. This is one of those
 things that seems really easy but gets complicated the deeper you dig
 into it. We're open to suggestions/patches.

>>>
>>> Yeah, I don't think we want to be in the business of installing and
>>> configuring an MTA. However, we should be able to detect if one is
>>> available
>>> and use it if it is. I think it would be reasonable to restrict it to
>>> LMTP
>>> with a Unix domain socket (most MTA's support this). Then our config
>>> would
>>> have a LMTP domain socket pathname, if that pathname exists and we can
>>> connect
>>> to it we use, if not we fallback to not generating any mail.
>>>
>>
>> In meanwhile, it should be relatively simple to code script which does
>> ldapsearch from time to time and sends some e-mails. This script doesn't
>> have to run on the same server as IPA, only access to LDAP and some MTA
>> is required.
>>
>>
> Yes, that is our current recommendation. There is a sample query in the
> docs IIRC.
>
> rob
>
>
> __**_
> 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] Account Expiration

[Jan-Frode Myklebust]

On Wed, Feb 13, 2013 at 09:29:42AM +0100, Petr Spacek wrote:
> >
> >Yeah, I don't think we want to be in the business of installing and
> >configuring an MTA. However, we should be able to detect if one is available
> >and use it if it is. I think it would be reasonable to restrict it to LMTP
> >with a Unix domain socket (most MTA's support this). Then our config would
> >have a LMTP domain socket pathname, if that pathname exists and we can 
> >connect
> >to it we use, if not we fallback to not generating any mail.
> 
> In meanwhile, it should be relatively simple to code script which
> does ldapsearch from time to time and sends some e-mails. This
> script doesn't have to run on the same server as IPA, only access to
> LDAP and some MTA is required.

Crude, but a start:


#! /bin/bash
ldapsearch -z 500 -x -h ipa1.example.net -b 
cn=users,cn=accounts,dc=example,dc=net "(krbPasswordExpiration<=$(date +%Y%m%d 
--date='+1 week')00Z)" mail |grep ^mail|cut -d: -f2 |while read mail
do
echo password expires in less than a week | mail -s "Password expires" 
$mail
done




  -jf

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

Re: [Freeipa-users] FreeIPA installation bug on F18 while "requesting RA certificate from CA"

[Robert M. Albrecht]

Hi Rob,

yes, worked after downgrading nss* and xulrunner & firefox because of deps.

Thanks.

cu romal


Am 13.02.13 15:48, schrieb Rob Crittenden:

Robert M. Albrecht wrote:

Hi,


Configuring NTP daemon (ntpd)
   [1/4]: stopping ntpd
   [2/4]: writing configuration
   [3/4]: configuring ntpd to start on boot
   [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
   [1/36]: creating directory server user
   [2/36]: creating directory server instance
   [3/36]: adding default schema
   [4/36]: enabling memberof plugin
   [5/36]: enabling winsync plugin
   [6/36]: configuring replication version plugin
   [7/36]: enabling IPA enrollment plugin
   [8/36]: enabling ldapi
   [9/36]: configuring uniqueness plugin
   [10/36]: configuring uuid plugin
   [11/36]: configuring modrdn plugin
   [12/36]: enabling entryUSN plugin
   [13/36]: configuring lockout plugin
   [14/36]: creating indices
   [15/36]: enabling referential integrity plugin
   [16/36]: configuring certmap.conf
   [17/36]: configure autobind for root
   [18/36]: configure new location for managed entries
   [19/36]: restarting directory server
   [20/36]: adding default layout
   [21/36]: adding delegation layout
   [22/36]: adding replication acis
   [23/36]: creating container for managed entries
   [24/36]: configuring user private groups
   [25/36]: configuring netgroups from hostgroups
   [26/36]: creating default Sudo bind user
   [27/36]: creating default Auto Member layout
   [28/36]: adding range check plugin
   [29/36]: creating default HBAC rule allow_all
   [30/36]: Upload CA cert to the directory
ipa : CRITICAL Failed to load upload-cacert.ldif: Command
'/usr/bin/ldapmodify -v -f /tmp/tmpSkzd0p -H
ldap://gutenberg.vorlon.lan:389 -x -D cn=Directory Manager -y
/tmp/tmpVB45G5' returned non-zero exit status 247
   [31/36]: initializing group membership
   [32/36]: adding master entry
   [33/36]: configuring Posix uid/gid generation
   [34/36]: enabling compatibility plugin
   [35/36]: tuning directory server
   [36/36]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes
30 seconds
   [1/20]: creating certificate server user
   [2/20]: configuring certificate server instance
   [3/20]: disabling nonces
   [4/20]: creating RA agent certificate database
   [5/20]: importing CA chain to RA certificate database
   [6/20]: fixing RA database permissions
   [7/20]: setting up signing cert profile
   [8/20]: set up CRL publishing
   [9/20]: set certificate subject base
   [10/20]: enabling Subject Key Identifier
   [11/20]: enabling CRL and OCSP extensions for certificates
   [12/20]: setting audit signing renewal to 2 years
   [13/20]: configuring certificate server to start on boot
   [14/20]: restarting certificate server
   [15/20]: requesting RA certificate from CA
Unexpected error - see /var/log/ipaserver-install.log for details:
IndexError: list index out of range
[root@gutenberg ~]#

from /var/log/ipaserver-install.log

2013-02-13T14:38:15Z DEBUG stderr=
2013-02-13T14:38:15Z DEBUG Saving StateFile to
'/var/lib/ipa/sysrestore/sysrestore.state'
2013-02-13T14:38:15Z DEBUG   duration: 0 seconds
2013-02-13T14:38:15Z DEBUG   [14/20]: restarting certificate server
2013-02-13T14:38:15Z DEBUG Starting external process
2013-02-13T14:38:15Z DEBUG args=/bin/systemctl restart
pki-tomcatd@pki-tomcat.service
2013-02-13T14:38:19Z DEBUG Process finished, return code=0
2013-02-13T14:38:19Z DEBUG stdout=
2013-02-13T14:38:19Z DEBUG stderr=
2013-02-13T14:38:19Z DEBUG Starting external process
2013-02-13T14:38:19Z DEBUG args=/bin/systemctl is-active
pki-tomcatd@pki-tomcat.service
2013-02-13T14:38:19Z DEBUG Process finished, return code=0
2013-02-13T14:38:19Z DEBUG stdout=active

2013-02-13T14:38:19Z DEBUG stderr=
2013-02-13T14:38:19Z DEBUG wait_for_open_ports: localhost [8080, 8443]
timeout 120
2013-02-13T14:38:25Z DEBUG The httpd proxy is not installed, skipping
wait for CA
2013-02-13T14:38:25Z DEBUG   duration: 9 seconds
2013-02-13T14:38:25Z DEBUG   [15/20]: requesting RA certificate from CA
2013-02-13T14:38:25Z DEBUG Starting external process
2013-02-13T14:38:25Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias -f
 -R -k rsa -g 2048 -s CN=IPA RA,O=VORLON.LAN -z /tmp/tmpQoA4BN -a
2013-02-13T14:38:31Z DEBUG Process finished, return code=0
2013-02-13T14:38:31Z DEBUG
stdout=^X^\5^@^@^@^X^\5^@^@^@^P<81>^A^@^@^@^@^P<81>^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@!^F^@^@^@^@^@^@<98>^W5^@^@^@<81>^A^@


^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<80><8D><81>^A^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@P^@^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

Re: [Freeipa-users] Account Expiration

[Steven Jones]

Hi,

Isnt Postfix the RHEL default now?  So is it that hard to do a 
Postfix-ipa-config.rpm?

Its something we want as well, so I'll do a RFE, RH support will love me more 
I'm sure

;]

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 Rob Crittenden [rcrit...@redhat.com]
Sent: Thursday, 14 February 2013 2:56 a.m.
To: Petr Spacek
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Account Expiration

Petr Spacek wrote:
> On 12.2.2013 20:21, John Dennis wrote:
>> On 02/12/2013 01:40 PM, Rob Crittenden wrote:
 Is it possible to ipa to send a email to user when his account is about
 to expire (the current date is near krbprincipalexpiration date) ?
>>>
>>> Not currently. In 3.0+ we will provide a notice when one logs into the
>>> WebUI but that's it.
>>>
>>> We can't be sure that an MTA is properly configured on the IPA server at
>>> install time so we have punted on this for a while. We don't want to get
>>> into the business of picking and configuring one. This is one of those
>>> things that seems really easy but gets complicated the deeper you dig
>>> into it. We're open to suggestions/patches.
>>
>> Yeah, I don't think we want to be in the business of installing and
>> configuring an MTA. However, we should be able to detect if one is
>> available
>> and use it if it is. I think it would be reasonable to restrict it to
>> LMTP
>> with a Unix domain socket (most MTA's support this). Then our config
>> would
>> have a LMTP domain socket pathname, if that pathname exists and we can
>> connect
>> to it we use, if not we fallback to not generating any mail.
>
> In meanwhile, it should be relatively simple to code script which does
> ldapsearch from time to time and sends some e-mails. This script doesn't
> have to run on the same server as IPA, only access to LDAP and some MTA
> is required.
>

Yes, that is our current recommendation. There is a sample query in the
docs IIRC.

rob

___
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] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC

[Steven Jones]

Hi,

You can specify a --winsubtree, provided all the users you want are in that, I 
think that will work.

For filters, Ive suggested that, we have so much garbage in our AD that its 
cluttering IPA badly.  eg we have hundred templates, so I'd like to block those 
from being transferred.

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 Dag Wieers [d...@wieers.com]
Sent: Thursday, 14 February 2013 3:58 a.m.
To: freeipa-users@redhat.com
Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and 
Solaris RBAC

Hi,

We are investigating whether IPA is an acceptable solution for our
environment. One of the aspects that is not clear (from reading the
documentation and testing it without AD) is whether the synchronization
with AD can be limited to a subset.


Since we would like to only synchronize certain user-accounts (conforming
to a specific format) from AD unidirectionally, and we also want to manage
functional/technical accounts on IPA, we need to make sure that we:

  - can filter the stuff we pull from AD
  - can avoid the synchronisation to remove other accounts managed in IPA

Can someone confirm that this is possible ? Is there any indepth
information on how this AD sycnhronization works (preferably about RHEL6
IPA) ?


Also since we also require compatibility with Solaris, and roles (RBAC) is
currently used on Solaris, does IPA support RBAC on Solaris ? (We noticed
that RBAC mentioned in the IPA web interface only relates to IPA
management).


Thanks in advance,
--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, i...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

___
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] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC

[Rich Megginson]

On 02/13/2013 08:10 AM, Rob Crittenden wrote:

Dag Wieers wrote:

Hi,

We are investigating whether IPA is an acceptable solution for our
environment. One of the aspects that is not clear (from reading the
documentation and testing it without AD) is whether the synchronization
with AD can be limited to a subset.


Since we would like to only synchronize certain user-accounts
(conforming to a specific format) from AD unidirectionally, and we also
want to manage functional/technical accounts on IPA, we need to make
sure that we:

  - can filter the stuff we pull from AD


You can set the subtree to use, I'm not sure if you can supply a 
filter to the winsync agreement. Rich?


No, this is an RFE

This trac report gives a pretty good idea of the limitations of 389 winsync:
https://fedorahosted.org/389/query?component=Sync+Service&status=accepted&status=assigned&status=new&status=reopened&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority&report=16

see especially
https://fedorahosted.org/389/ticket/178
https://fedorahosted.org/389/ticket/460



  - can avoid the synchronisation to remove other accounts managed in 
IPA


I don't understand the question. You don't want the winsync agreement 
to affect IPA-specific users? That works.




Can someone confirm that this is possible ? Is there any indepth
information on how this AD sycnhronization works (preferably about RHEL6
IPA) ?


Not beyond what is in the 389-ds-base and IPA documentation. There 
might be some additional information on the 389-ds wiki.


What would you like to know?





Also since we also require compatibility with Solaris, and roles (RBAC)
is currently used on Solaris, does IPA support RBAC on Solaris ? (We
noticed that RBAC mentioned in the IPA web interface only relates to IPA
management).


No, IPA doesn't support RBAC on Solaris.

rob



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

Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC

[Rob Crittenden]

Dag Wieers wrote:

Hi,

We are investigating whether IPA is an acceptable solution for our
environment. One of the aspects that is not clear (from reading the
documentation and testing it without AD) is whether the synchronization
with AD can be limited to a subset.


Since we would like to only synchronize certain user-accounts
(conforming to a specific format) from AD unidirectionally, and we also
want to manage functional/technical accounts on IPA, we need to make
sure that we:

  - can filter the stuff we pull from AD


You can set the subtree to use, I'm not sure if you can supply a filter 
to the winsync agreement. Rich?



  - can avoid the synchronisation to remove other accounts managed in IPA


I don't understand the question. You don't want the winsync agreement to 
affect IPA-specific users? That works.




Can someone confirm that this is possible ? Is there any indepth
information on how this AD sycnhronization works (preferably about RHEL6
IPA) ?


Not beyond what is in the 389-ds-base and IPA documentation. There might 
be some additional information on the 389-ds wiki.




Also since we also require compatibility with Solaris, and roles (RBAC)
is currently used on Solaris, does IPA support RBAC on Solaris ? (We
noticed that RBAC mentioned in the IPA web interface only relates to IPA
management).


No, IPA doesn't support RBAC on Solaris.

rob

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

Re: [Freeipa-users] Python Client

[Simo Sorce]

On Wed, 2013-02-13 at 09:35 -0500, Dmitri Pal wrote:
> On 02/13/2013 12:47 AM, It Meme wrote: 

> > Could there be anyway that accounts can be provisioned to IPA, via
> > LDAP, from existing IAM system?
> > 
> > 
> > The newly provisioned accounts can be temporarily stored in IPA's
> > 389 Directory Server, and subsequently an automated task can IPA-ize
> > the accounts (i.e. via the Python libraries). The accounts that have
> > not been IPA-ized will be provisioned in a disabled state (i.e.
> > users will be not using them).
> > 
> > 
> > After accounts have been IPA-ize, account attributes, such as
> > 'givenName', 'password', 'membershipOf', can be managed by LDAP from
> > the central IAM system.


> IMO a solution might be to do something like this:
> https://fedorahosted.org/freeipa/ticket/1593
> You create a plugin for DS to intercept the changes and send them over
> DBUS or socket
> 
> So the whole thing would work like this:
> You create a different tree for accounts managed by the external
> system for example under cn=ext, ...
> You create a plugin that would intercept add, delete and modify
> commands and would also send these over the DBUS/Socket to a python
> service that would translate the changes into ipa user-add, ipa
> user-mod and ipa-user-del commands.
> 
> The value of this approach is that would take advantage of the
> standard interfaces of both systems and have full control over the
> code you develop.
> 
> Would that work for you?
> 

I hadn't seen this reply yet, but I just proposed something similar on
freeipa-devel.

However my proposal would avoid strange back and forth with temporary
objects and so on.

It Meme,
if you are interested in helping in this direction please subscribe to
freeipa-devel and follow this thread: 
https://www.redhat.com/archives/freeipa-devel/2013-February/msg00149.html

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

[Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC

[Dag Wieers]

Hi,

We are investigating whether IPA is an acceptable solution for our 
environment. One of the aspects that is not clear (from reading the 
documentation and testing it without AD) is whether the synchronization 
with AD can be limited to a subset.



Since we would like to only synchronize certain user-accounts (conforming 
to a specific format) from AD unidirectionally, and we also want to manage 
functional/technical accounts on IPA, we need to make sure that we:


 - can filter the stuff we pull from AD
 - can avoid the synchronisation to remove other accounts managed in IPA

Can someone confirm that this is possible ? Is there any indepth 
information on how this AD sycnhronization works (preferably about RHEL6 
IPA) ?



Also since we also require compatibility with Solaris, and roles (RBAC) is 
currently used on Solaris, does IPA support RBAC on Solaris ? (We noticed 
that RBAC mentioned in the IPA web interface only relates to IPA 
management).



Thanks in advance,
--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, i...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

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

Re: [Freeipa-users] FreeIPA installation bug on F18 while "requesting RA certificate from CA"

[Rob Crittenden]

Robert M. Albrecht wrote:

Hi,


Configuring NTP daemon (ntpd)
   [1/4]: stopping ntpd
   [2/4]: writing configuration
   [3/4]: configuring ntpd to start on boot
   [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
   [1/36]: creating directory server user
   [2/36]: creating directory server instance
   [3/36]: adding default schema
   [4/36]: enabling memberof plugin
   [5/36]: enabling winsync plugin
   [6/36]: configuring replication version plugin
   [7/36]: enabling IPA enrollment plugin
   [8/36]: enabling ldapi
   [9/36]: configuring uniqueness plugin
   [10/36]: configuring uuid plugin
   [11/36]: configuring modrdn plugin
   [12/36]: enabling entryUSN plugin
   [13/36]: configuring lockout plugin
   [14/36]: creating indices
   [15/36]: enabling referential integrity plugin
   [16/36]: configuring certmap.conf
   [17/36]: configure autobind for root
   [18/36]: configure new location for managed entries
   [19/36]: restarting directory server
   [20/36]: adding default layout
   [21/36]: adding delegation layout
   [22/36]: adding replication acis
   [23/36]: creating container for managed entries
   [24/36]: configuring user private groups
   [25/36]: configuring netgroups from hostgroups
   [26/36]: creating default Sudo bind user
   [27/36]: creating default Auto Member layout
   [28/36]: adding range check plugin
   [29/36]: creating default HBAC rule allow_all
   [30/36]: Upload CA cert to the directory
ipa : CRITICAL Failed to load upload-cacert.ldif: Command
'/usr/bin/ldapmodify -v -f /tmp/tmpSkzd0p -H
ldap://gutenberg.vorlon.lan:389 -x -D cn=Directory Manager -y
/tmp/tmpVB45G5' returned non-zero exit status 247
   [31/36]: initializing group membership
   [32/36]: adding master entry
   [33/36]: configuring Posix uid/gid generation
   [34/36]: enabling compatibility plugin
   [35/36]: tuning directory server
   [36/36]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes
30 seconds
   [1/20]: creating certificate server user
   [2/20]: configuring certificate server instance
   [3/20]: disabling nonces
   [4/20]: creating RA agent certificate database
   [5/20]: importing CA chain to RA certificate database
   [6/20]: fixing RA database permissions
   [7/20]: setting up signing cert profile
   [8/20]: set up CRL publishing
   [9/20]: set certificate subject base
   [10/20]: enabling Subject Key Identifier
   [11/20]: enabling CRL and OCSP extensions for certificates
   [12/20]: setting audit signing renewal to 2 years
   [13/20]: configuring certificate server to start on boot
   [14/20]: restarting certificate server
   [15/20]: requesting RA certificate from CA
Unexpected error - see /var/log/ipaserver-install.log for details:
IndexError: list index out of range
[root@gutenberg ~]#

from /var/log/ipaserver-install.log

2013-02-13T14:38:15Z DEBUG stderr=
2013-02-13T14:38:15Z DEBUG Saving StateFile to
'/var/lib/ipa/sysrestore/sysrestore.state'
2013-02-13T14:38:15Z DEBUG   duration: 0 seconds
2013-02-13T14:38:15Z DEBUG   [14/20]: restarting certificate server
2013-02-13T14:38:15Z DEBUG Starting external process
2013-02-13T14:38:15Z DEBUG args=/bin/systemctl restart
pki-tomcatd@pki-tomcat.service
2013-02-13T14:38:19Z DEBUG Process finished, return code=0
2013-02-13T14:38:19Z DEBUG stdout=
2013-02-13T14:38:19Z DEBUG stderr=
2013-02-13T14:38:19Z DEBUG Starting external process
2013-02-13T14:38:19Z DEBUG args=/bin/systemctl is-active
pki-tomcatd@pki-tomcat.service
2013-02-13T14:38:19Z DEBUG Process finished, return code=0
2013-02-13T14:38:19Z DEBUG stdout=active

2013-02-13T14:38:19Z DEBUG stderr=
2013-02-13T14:38:19Z DEBUG wait_for_open_ports: localhost [8080, 8443]
timeout 120
2013-02-13T14:38:25Z DEBUG The httpd proxy is not installed, skipping
wait for CA
2013-02-13T14:38:25Z DEBUG   duration: 9 seconds
2013-02-13T14:38:25Z DEBUG   [15/20]: requesting RA certificate from CA
2013-02-13T14:38:25Z DEBUG Starting external process
2013-02-13T14:38:25Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias -f
 -R -k rsa -g 2048 -s CN=IPA RA,O=VORLON.LAN -z /tmp/tmpQoA4BN -a
2013-02-13T14:38:31Z DEBUG Process finished, return code=0
2013-02-13T14:38:31Z DEBUG
stdout=^X^\5^@^@^@^X^\5^@^@^@^P<81>^A^@^@^@^@^P<81>^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@!^F^@^@^@^@^@^@<98>^W5^@^@^@<81>^A^@

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<80><8D><81>^A^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@P^@^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^

[Freeipa-users] FreeIPA installation bug on F18 while "requesting RA certificate from CA"

[Robert M. Albrecht]

Hi,


Configuring NTP daemon (ntpd)
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
  [1/36]: creating directory server user
  [2/36]: creating directory server instance
  [3/36]: adding default schema
  [4/36]: enabling memberof plugin
  [5/36]: enabling winsync plugin
  [6/36]: configuring replication version plugin
  [7/36]: enabling IPA enrollment plugin
  [8/36]: enabling ldapi
  [9/36]: configuring uniqueness plugin
  [10/36]: configuring uuid plugin
  [11/36]: configuring modrdn plugin
  [12/36]: enabling entryUSN plugin
  [13/36]: configuring lockout plugin
  [14/36]: creating indices
  [15/36]: enabling referential integrity plugin
  [16/36]: configuring certmap.conf
  [17/36]: configure autobind for root
  [18/36]: configure new location for managed entries
  [19/36]: restarting directory server
  [20/36]: adding default layout
  [21/36]: adding delegation layout
  [22/36]: adding replication acis
  [23/36]: creating container for managed entries
  [24/36]: configuring user private groups
  [25/36]: configuring netgroups from hostgroups
  [26/36]: creating default Sudo bind user
  [27/36]: creating default Auto Member layout
  [28/36]: adding range check plugin
  [29/36]: creating default HBAC rule allow_all
  [30/36]: Upload CA cert to the directory
ipa : CRITICAL Failed to load upload-cacert.ldif: Command
'/usr/bin/ldapmodify -v -f /tmp/tmpSkzd0p -H
ldap://gutenberg.vorlon.lan:389 -x -D cn=Directory Manager -y
/tmp/tmpVB45G5' returned non-zero exit status 247
  [31/36]: initializing group membership
  [32/36]: adding master entry
  [33/36]: configuring Posix uid/gid generation
  [34/36]: enabling compatibility plugin
  [35/36]: tuning directory server
  [36/36]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes
30 seconds
  [1/20]: creating certificate server user
  [2/20]: configuring certificate server instance
  [3/20]: disabling nonces
  [4/20]: creating RA agent certificate database
  [5/20]: importing CA chain to RA certificate database
  [6/20]: fixing RA database permissions
  [7/20]: setting up signing cert profile
  [8/20]: set up CRL publishing
  [9/20]: set certificate subject base
  [10/20]: enabling Subject Key Identifier
  [11/20]: enabling CRL and OCSP extensions for certificates
  [12/20]: setting audit signing renewal to 2 years
  [13/20]: configuring certificate server to start on boot
  [14/20]: restarting certificate server
  [15/20]: requesting RA certificate from CA
Unexpected error - see /var/log/ipaserver-install.log for details:
IndexError: list index out of range
[root@gutenberg ~]#

from /var/log/ipaserver-install.log

2013-02-13T14:38:15Z DEBUG stderr=
2013-02-13T14:38:15Z DEBUG Saving StateFile to
'/var/lib/ipa/sysrestore/sysrestore.state'
2013-02-13T14:38:15Z DEBUG   duration: 0 seconds
2013-02-13T14:38:15Z DEBUG   [14/20]: restarting certificate server
2013-02-13T14:38:15Z DEBUG Starting external process
2013-02-13T14:38:15Z DEBUG args=/bin/systemctl restart
pki-tomcatd@pki-tomcat.service
2013-02-13T14:38:19Z DEBUG Process finished, return code=0
2013-02-13T14:38:19Z DEBUG stdout=
2013-02-13T14:38:19Z DEBUG stderr=
2013-02-13T14:38:19Z DEBUG Starting external process
2013-02-13T14:38:19Z DEBUG args=/bin/systemctl is-active
pki-tomcatd@pki-tomcat.service
2013-02-13T14:38:19Z DEBUG Process finished, return code=0
2013-02-13T14:38:19Z DEBUG stdout=active

2013-02-13T14:38:19Z DEBUG stderr=
2013-02-13T14:38:19Z DEBUG wait_for_open_ports: localhost [8080, 8443]
timeout 120
2013-02-13T14:38:25Z DEBUG The httpd proxy is not installed, skipping
wait for CA
2013-02-13T14:38:25Z DEBUG   duration: 9 seconds
2013-02-13T14:38:25Z DEBUG   [15/20]: requesting RA certificate from CA
2013-02-13T14:38:25Z DEBUG Starting external process
2013-02-13T14:38:25Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias -f
 -R -k rsa -g 2048 -s CN=IPA RA,O=VORLON.LAN -z /tmp/tmpQoA4BN -a
2013-02-13T14:38:31Z DEBUG Process finished, return code=0
2013-02-13T14:38:31Z DEBUG
stdout=^X^\5^@^@^@^X^\5^@^@^@^P<81>^A^@^@^@^@^P<81>^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@!^F^@^@^@^@^@^@<98>^W5^@^@^@<81>^A^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<80><8D><81>^A^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@P^@^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^

Re: [Freeipa-users] Python Client

[Rob Crittenden]

It Meme wrote:

Thank you for your reply.

Could there be anyway that accounts can be provisioned to IPA, via LDAP,
from existing IAM system?

The newly provisioned accounts can be temporarily stored in IPA's 389
Directory Server, and subsequently an automated task can IPA-ize the
accounts (i.e. via the Python libraries). The accounts that have not
been IPA-ized will be provisioned in a disabled state (i.e. users will
be not using them).

After accounts have been IPA-ize, account attributes, such as
'givenName', 'password', 'membershipOf', can be managed by LDAP from the
central IAM system.


I think as has been suggested your best bet is to write the users to a 
location outside of the IPA DIT and run a periodic query or write a 
service that uses LDAP persistent search to retrieve the user then pass 
it to the IPA framework via user-add. I think persistent search and a 
user principal in a keytab would be a pretty decent way to go.


rob



Thank you.


On Tue, Feb 12, 2013 at 4:18 PM, Dmitri Pal mailto:d...@redhat.com>> wrote:

On 02/12/2013 12:42 PM, It Meme wrote:
 > Yes - Dmitri is correct.
 >
 > Our purchased IAM product has LDAP connectors. It is possible to
customize to develop other connector protocols but it requires
tweaking the core product code - this adds risk and, if not careful,
could break our support with vendor or increase operational risk to
a critical production system.
 >
 > The most practical option is to continue to use the LDAP
connectors to provision accounts to directory server.
 >
 > If we use IPA, that would mean provisioning accounts, from our
IAM product to IPA, via LDAP (Step 1) - and subsequently running a
script that will call the python libraries to IPA-ize the
provisioned accounts (Step 2).
 >
 > It will assist our help desk staff if 'Step 1' provisioned
accounts were created in main accounts tree in IPA - then subsequent
script will IPA-ize the accounts for 'Step 2' and accounts will be
updated in same tree.
 >
 > Any gotchas foreseen with above?
Yes. You need to be very careful. You are bypassing all the checks that
framework creates around user and group management. It is also unclear
how the system would react to the half baked user. It is all doable but
you shift the risk from the tweaking core product code to creating a
custom IPA code. IMO the level of risk is nearly the same.

 > We have larger user base with ~40K new accounts per year and 600K
ongoing - automating the tasks in stable systems, and having help
desk insight to account statuses are critical items for management.
 >
 > Thank you for your help, insights, input - they are very helpful
and greatly appreciated.
 >
 > On 2013-02-10, at 7:32, Dmitri Pal mailto:d...@redhat.com>> wrote:
 >
 >> On 02/09/2013 11:53 AM, John Dennis wrote:
 >>> On 02/08/2013 05:29 PM, It Meme wrote:
  Hi:
 
  Scenario:
 
  1) User is created via LDAP call to IPA (i.e.the 389 Directory
Server)
 
  The above user will not have IPA-specific attributes.
 
  Can we use the Python Library, or CLI, to modify the account to
  IPA-ize it?
 >>> You're really better off using the IPA API directly rather than
trying
 >>> to bypass it. Why? Because we implement additional logic inside the
 >>> commands. If you could achieve everything IPA does by just
modifying
 >>> an LDAP server there wouldn't be a need for IPA. A good example of
 >>> this is group membership, some of that logic is handled
directly by a
 >>> plugin to the 389 DS, but a large part of it is implemented in
the IPA
 >>> commands that manage users and groups. You really don't want to
bypass
 >>> it.
 >>>
 >>> You have a number of options on how to call the IPA commands:
 >>>
 >>> 1) the ipa command line client
 >>>
 >>> 2) sending the command formatted in JSON to the server
 >>>
 >>> 3) sending the command formatted in XML-RPC to the server
 >>>
 >>> 4) calling the command from your own python code
 >>>
 >>> 5) using the web GUI
 >>>
 >>> It's really not hard to call the IPA command line client from a
 >>> program, typically this is done via a "system" command of which
there
 >>> are a number of variants.
 >>>
 >>> The following thread has a discussion of how to invoke one of our
 >>> commands from Python code, this particular email response from
Martin
 >>> shows how it can be done in in about half a dozen lines of code.
 >>>
 >>>
https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html
 >>>
 >>> What I'm not understanding why you're avoiding using the
commands we
 >>> provide. If you're not familiar with how to call another
 >>> program/process we can help 

Re: [Freeipa-users] Python Client

[Dmitri Pal]

On 02/13/2013 12:47 AM, It Meme wrote:
> Thank you for your reply.
>
> Could there be anyway that accounts can be provisioned to IPA, via
> LDAP, from existing IAM system?
>
> The newly provisioned accounts can be temporarily stored in IPA's 389
> Directory Server, and subsequently an automated task can IPA-ize the
> accounts (i.e. via the Python libraries). The accounts that have not
> been IPA-ized will be provisioned in a disabled state (i.e. users will
> be not using them).
>
> After accounts have been IPA-ize, account attributes, such as
> 'givenName', 'password', 'membershipOf', can be managed by LDAP from
> the central IAM system.
>

IMO a solution might be to do something like this:
https://fedorahosted.org/freeipa/ticket/1593
You create a plugin for DS to intercept the changes and send them over
DBUS or socket

So the whole thing would work like this:
You create a different tree for accounts managed by the external system
for example under cn=ext, ...
You create a plugin that would intercept add, delete and modify commands
and would also send these over the DBUS/Socket to a python service that
would translate the changes into ipa user-add, ipa user-mod and
ipa-user-del commands.

The value of this approach is that would take advantage of the standard
interfaces of both systems and have full control over the code you develop.

Would that work for you?




> Thank you.
>
>
> On Tue, Feb 12, 2013 at 4:18 PM, Dmitri Pal  > wrote:
>
> On 02/12/2013 12:42 PM, It Meme wrote:
> > Yes - Dmitri is correct.
> >
> > Our purchased IAM product has LDAP connectors. It is possible to
> customize to develop other connector protocols but it requires
> tweaking the core product code - this adds risk and, if not
> careful, could break our support with vendor or increase
> operational risk to a critical production system.
> >
> > The most practical option is to continue to use the LDAP
> connectors to provision accounts to directory server.
> >
> > If we use IPA, that would mean provisioning accounts, from our
> IAM product to IPA, via LDAP (Step 1) - and subsequently running a
> script that will call the python libraries to IPA-ize the
> provisioned accounts (Step 2).
> >
> > It will assist our help desk staff if 'Step 1' provisioned
> accounts were created in main accounts tree in IPA - then
> subsequent script will IPA-ize the accounts for 'Step 2' and
> accounts will be updated in same tree.
> >
> > Any gotchas foreseen with above?
> Yes. You need to be very careful. You are bypassing all the checks
> that
> framework creates around user and group management. It is also unclear
> how the system would react to the half baked user. It is all
> doable but
> you shift the risk from the tweaking core product code to creating a
> custom IPA code. IMO the level of risk is nearly the same.
>
> > We have larger user base with ~40K new accounts per year and
> 600K ongoing - automating the tasks in stable systems, and having
> help desk insight to account statuses are critical items for
> management.
> >
> > Thank you for your help, insights, input - they are very helpful
> and greatly appreciated.
> >
> > On 2013-02-10, at 7:32, Dmitri Pal  > wrote:
> >
> >> On 02/09/2013 11:53 AM, John Dennis wrote:
> >>> On 02/08/2013 05:29 PM, It Meme wrote:
>  Hi:
> 
>  Scenario:
> 
>  1) User is created via LDAP call to IPA (i.e.the 389
> Directory Server)
> 
>  The above user will not have IPA-specific attributes.
> 
>  Can we use the Python Library, or CLI, to modify the account to
>  IPA-ize it?
> >>> You're really better off using the IPA API directly rather
> than trying
> >>> to bypass it. Why? Because we implement additional logic
> inside the
> >>> commands. If you could achieve everything IPA does by just
> modifying
> >>> an LDAP server there wouldn't be a need for IPA. A good example of
> >>> this is group membership, some of that logic is handled
> directly by a
> >>> plugin to the 389 DS, but a large part of it is implemented in
> the IPA
> >>> commands that manage users and groups. You really don't want
> to bypass
> >>> it.
> >>>
> >>> You have a number of options on how to call the IPA commands:
> >>>
> >>> 1) the ipa command line client
> >>>
> >>> 2) sending the command formatted in JSON to the server
> >>>
> >>> 3) sending the command formatted in XML-RPC to the server
> >>>
> >>> 4) calling the command from your own python code
> >>>
> >>> 5) using the web GUI
> >>>
> >>> It's really not hard to call the IPA command line client from a
> >>> program, typically this is done via a "system" command of
> 

Re: [Freeipa-users] Restricting other User's Details to be visible to a user

[Rob Crittenden]

Rajnesh Kumar Siwal wrote:

Yes. We would still like to restrict the Visibility of the users.
We could implement the ACL's in 389-ds. However, I was concerned
whether it breaks the IPA.



To disable anonymous you need to set nsslapd-allow-anonymous-access to 
off in cn=config (bind as Directory Manager). Note that this needs to be 
done on every IPA master (and you need to remember to do this if you add 
any more).


To disallow restrict read access to a set of attributes you'd need to 
write a custom ACI, something that is beyond the ability of our 
permission commands.


If you're considering just some attributes in the user object then it 
should be fine. Those fields will just appear as blank to users that 
cannot read them. Hard to say if it would break anything without seeing 
the ACI.


rob

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

Re: [Freeipa-users] Account Expiration

[Rob Crittenden]

Petr Spacek wrote:

On 12.2.2013 20:21, John Dennis wrote:

On 02/12/2013 01:40 PM, Rob Crittenden wrote:

Is it possible to ipa to send a email to user when his account is about
to expire (the current date is near krbprincipalexpiration date) ?


Not currently. In 3.0+ we will provide a notice when one logs into the
WebUI but that's it.

We can't be sure that an MTA is properly configured on the IPA server at
install time so we have punted on this for a while. We don't want to get
into the business of picking and configuring one. This is one of those
things that seems really easy but gets complicated the deeper you dig
into it. We're open to suggestions/patches.


Yeah, I don't think we want to be in the business of installing and
configuring an MTA. However, we should be able to detect if one is
available
and use it if it is. I think it would be reasonable to restrict it to
LMTP
with a Unix domain socket (most MTA's support this). Then our config
would
have a LMTP domain socket pathname, if that pathname exists and we can
connect
to it we use, if not we fallback to not generating any mail.


In meanwhile, it should be relatively simple to code script which does
ldapsearch from time to time and sends some e-mails. This script doesn't
have to run on the same server as IPA, only access to LDAP and some MTA
is required.



Yes, that is our current recommendation. There is a sample query in the 
docs IIRC.


rob

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

Re: [Freeipa-users] Account Expiration

[James James]

It's a good idea. I will try that.



2013/2/13 Petr Spacek 

> On 12.2.2013 20:21, John Dennis wrote:
>
>> On 02/12/2013 01:40 PM, Rob Crittenden wrote:
>>
>>> Is it possible to ipa to send a email to user when his account is about
 to expire (the current date is near krbprincipalexpiration date) ?

>>>
>>> Not currently. In 3.0+ we will provide a notice when one logs into the
>>> WebUI but that's it.
>>>
>>> We can't be sure that an MTA is properly configured on the IPA server at
>>> install time so we have punted on this for a while. We don't want to get
>>> into the business of picking and configuring one. This is one of those
>>> things that seems really easy but gets complicated the deeper you dig
>>> into it. We're open to suggestions/patches.
>>>
>>
>> Yeah, I don't think we want to be in the business of installing and
>> configuring an MTA. However, we should be able to detect if one is
>> available
>> and use it if it is. I think it would be reasonable to restrict it to LMTP
>> with a Unix domain socket (most MTA's support this). Then our config would
>> have a LMTP domain socket pathname, if that pathname exists and we can
>> connect
>> to it we use, if not we fallback to not generating any mail.
>>
>
> In meanwhile, it should be relatively simple to code script which does
> ldapsearch from time to time and sends some e-mails. This script doesn't
> have to run on the same server as IPA, only access to LDAP and some MTA is
> required.
>
> --
> Petr^2 Spacek
>
>
> __**_
> 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] Restricting other User's Details to be visible to a user

[Rajnesh Kumar Siwal]

Yes. We would still like to restrict the Visibility of the users.
We could implement the ACL's in 389-ds. However, I was concerned
whether it breaks the IPA.

-- 
Regards,
Rajnesh Kumar Siwal

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

Re: [Freeipa-users] Restricting other User's Details to be visible to a user

[Petr Spacek]

On 13.2.2013 11:38, Rajnesh Kumar Siwal wrote:

It has been found that any user can see the details of other users
through the IPA Web Interface (even ldapsearch with anonymous user).
It would be great if we could hide the details of the other users from
the current user (including emai, phone number, Licence Number).
Additionally, anonymous access to the information should not be available.


Please look to archives, Dmitri summarized current state of things nicely:
https://www.redhat.com/archives/freeipa-users/2012-November/msg00052.html

We can recommend some way if you still want to do that.

--
Petr^2 Spacek

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

[Freeipa-users] Restricting other User's Details to be visible to a user

[Rajnesh Kumar Siwal]

It has been found that any user can see the details of other users
through the IPA Web Interface (even ldapsearch with anonymous user).
It would be great if we could hide the details of the other users from
the current user (including emai, phone number, Licence Number).
Additionally, anonymous access to the information should not be available.

-- 
Regards,
Rajnesh Kumar Siwal

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

[Freeipa-users] Announcing FreeIPA 2.2.2

[Martin Kosek]

The FreeIPA team is proud to announce version FreeIPA v2.2.2

This release contains Security Updates.

It can be downloaded from http://www.freeipa.org/page/Downloads.

A build is currently on the way to updates-testing for Fedora 17.

== Highlights ==

This release contains a Security Advisory:

* CVE-2012-5484: MITM Attack during Join process

The FreeIPA Team would like to thank the Red Hat Security Response Team and in
particular Vincent Danen for the invaluable assistance provided for the
assessment and resolution of these issues.
For CVE-2012-5484 we would like to thank Petr Menšík for reporting the issue.

== Upgrading ==

Please consult each CVE announcement for related Upgrading instructions.

An IPA server can be upgraded simply by installing updated rpms. The server
does not need to be shut down in advance.

If you have multiple servers you may upgrade them one at a time. It is expected
that all servers will be upgraded in a relatively short period (days or weeks
not months). They should be able to co-exist peacefully but new features will
not be available on old servers and enrolling a new client against an old
server will result in the SSH keys not being uploaded.

Downgrading a server once upgraded is not supported.

== Feedback ==

Please provide comments, bugs and other feedback via the freeipa-devel mailing
list: http://www.redhat.com/mailman/listinfo/freeipa-devel

== Detailed Changelog since 2.2.1 ==

Alexander Bokovoy (1):
* Update plugin to upload CA certificate to LDAP

Jan Cholasta (1):
* Pylint cleanup

John Dennis (1):
* Use secure method to acquire IPA CA certificate

Martin Kosek (3):
* Run index task for new indexes
* Filter suffix in replication management tools
* Become IPA 2.2.2

Rob Crittenden (1):
* Do SSL CA verification and hostname validation.

Simo Sorce (1):
* Upload CA cert in the directory on install



== CVE-2012-5484: MITM Attack during Join process ==

A weakness was found in the way an IPA client communicates with an IPA
server when attempting to join an IPA domain.

When an IPA client attempts to join an IPA domain an attacker could run
a Man in The Middle Attack to try to intercept and hijack initial
communication. A join initiated by an administrative user would grant
the attacker administrative rights to the IPA server, whereas a join
initiated by an unprivileged user would only grant the attacker limited
privilege (typically just the ability to join the domain).

The weakness is caused by the way the CA certificate is retrieved from
the server. The following SSL communication may then be intercepted and
subverted.

Note that no credentials are exposed through this attack and it is
effective only if performed during the join procedure and network
traffic can be redirected or intercepted. Mere observation of the
network traffic is not sufficient to grant an attacker any privilege.

== Affected Versions ==

All 2.x and 3.x versions

== Impact ==

Low

== Acknowledgements ==

The FreeIPA team would like to thank Petr Menšík for reporting this
issue.

== Upgrade instructions ==

The resolution for this issue consist in allowing clients to download
the CA certificate exclusively via a mutually authenticated LDAP
connection or by providing the CA cert via an external method to the
client. At least one IPA server in a domain need to be updated using the
provided patches, so that the CA certificate is made available via LDAP.
All client should be upgraded to use the updated ipa-client-install
script that downloads the CA cert via an authenticated LDAP connection.

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

Re: [Freeipa-users] Account Expiration

[Petr Spacek]

On 12.2.2013 20:21, John Dennis wrote:

On 02/12/2013 01:40 PM, Rob Crittenden wrote:

Is it possible to ipa to send a email to user when his account is about
to expire (the current date is near krbprincipalexpiration date) ?


Not currently. In 3.0+ we will provide a notice when one logs into the
WebUI but that's it.

We can't be sure that an MTA is properly configured on the IPA server at
install time so we have punted on this for a while. We don't want to get
into the business of picking and configuring one. This is one of those
things that seems really easy but gets complicated the deeper you dig
into it. We're open to suggestions/patches.


Yeah, I don't think we want to be in the business of installing and
configuring an MTA. However, we should be able to detect if one is available
and use it if it is. I think it would be reasonable to restrict it to LMTP
with a Unix domain socket (most MTA's support this). Then our config would
have a LMTP domain socket pathname, if that pathname exists and we can connect
to it we use, if not we fallback to not generating any mail.


In meanwhile, it should be relatively simple to code script which does 
ldapsearch from time to time and sends some e-mails. This script doesn't have 
to run on the same server as IPA, only access to LDAP and some MTA is required.


--
Petr^2 Spacek

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