Re: [Freeipa-users] Account Expiration
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] Announcing FreeIPA 2.2.2
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] Restricting other User's Details to be visible to a user
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
Re: [Freeipa-users] Restricting other User's Details to be visible to a user
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] Account Expiration
It's a good idea. I will try that. 2013/2/13 Petr Spacek pspa...@redhat.com 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-usershttps://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
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] Restricting other User's Details to be visible to a user
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] Python Client
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 d...@redhat.com 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 d...@redhat.com 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
Re: [Freeipa-users] Python Client
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 d...@redhat.com 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 d...@redhat.com 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 you or just google it. Or is the problem your existing management system does not provide you with any hooks to
[Freeipa-users] FreeIPA installation bug on F18 while requesting RA certificate from CA
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^\FBED5^@^@^@^X^\FBED5^@^@^@^PFD81^A^@^@^@^@^PFD81^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@B0^@^@^@^@^@^@^@!^F^@^@^@^@^@^@98^WFBED5^@^@^@A0F981^A^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@808D81^A^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@P^@^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
Re: [Freeipa-users] FreeIPA installation bug on F18 while requesting RA certificate from CA
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^\FBED5^@^@^@^X^\FBED5^@^@^@^PFD81^A^@^@^@^@^PFD81^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@B0^@^@^@^@^@^@^@!^F^@^@^@^@^@^@98^WFBED5^@^@^@A0F981^A^@
[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
Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC
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] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC
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+Servicestatus=acceptedstatus=assignedstatus=newstatus=reopenedcol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=componentorder=priorityreport=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
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] Account Expiration
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] FreeIPA installation bug on F18 while requesting RA certificate from CA
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^\FBED5^@^@^@^X^\FBED5^@^@^@^PFD81^A^@^@^@^@^PFD81^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@B0^@^@^@^@^@^@^@!^F^@^@^@^@^@^@98^WFBED5^@^@^@A0F981^A^@
Re: [Freeipa-users] Account Expiration
What is the IIRC docs ? 2013/2/13 Rob Crittenden 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-usershttps://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
thanks for your code. :) 2013/2/13 Jan-Frode Myklebust janfr...@tanso.net 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 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 rcrit...@redhat.com 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 mailto:Freeipa-users@redhat.com https://www.redhat.com/__mailman/listinfo/freeipa-users 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
On Sun, Feb 10, 2013 at 1:48 AM, Rob Crittenden rcrit...@redhat.com 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 http://example.com --server=ipa.example.com http://ipa.example.com --realm=EXAMPLE.COM http://EXAMPLE.COM --principal=user --password=pass -U --ntp-server=123.123.123.123 --mkhomedir --hostname=server1.example.com http://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] 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
Re: [Freeipa-users] Unable to enrol servers with principal
On 02/13/2013 04:57 PM, Charlie Derwent wrote: On Sun, Feb 10, 2013 at 1:48 AM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com 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 http://example.com http://example.com --server=ipa.example.com http://ipa.example.com http://ipa.example.com --realm=EXAMPLE.COM http://EXAMPLE.COM http://EXAMPLE.COM --principal=user --password=pass -U --ntp-server=123.123.123.123 --mkhomedir --hostname=server1.example.com http://server1.example.com http://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
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
