Re: [Freeipa-users] Slow logins on FreeIPA 4.1.2 (F21)
On Mon, Apr 06, 2015 at 08:01:46PM -0500, Dan Mossor wrote: On 04/05/2015 12:51 PM, Dmitri Pal wrote: On 04/05/2015 12:10 AM, Dan Mossor wrote: I've recently deployed a new domain based on 4.1.2 in F21. We've noticed an issue and can't quite seem to nail it down. The problem is that logins are taking an inordinate amount of time to complete - the fastest logon we can get using LDAP credentials is 8 seconds. During our testing, even logons to the IPA server itself took over 30 seconds to complete. I've narrowed this down to sssd, but that is as far as I can get. When cranking up debugging for sshd and PAM, I see a minimum 2 second delay between ssh handing off the authentication request to sssd and the reply back. The only troubleshooting I've done is with ssh, but the area that causes the most grief is Apache logins. We configured Apache to use PAM for auth through IPA, vice directly calling IPA itself. Logging in to our Redmine site takes users a minimum of 34 seconds to complete. Following this, a simple webpage containing two hyperlinks and two small thumbnail images takes over a minute to load on a gigabit network. The *only* thing changed in this environment was the IPA server. We moved the Redmine from our old network that was using IPA 3.x (F20 branch) to the new one. My initial reaction was that it was the VM that was hosting Redmine, but we've run these tests against bare metal machines in the same network and have the same issue. It appears that sssd is taking a very, very long time to talk to FreeIPA - even on the IPA server itself. However, Kerberos logins into the IPA web GUI are near instantaneous, while Username/Password logins take more than a few seconds. I need to get this solved. My developers don't appreciate the glory days of XP taking 5 minutes to log into an IIS 2.1 web server on the local network. I don't have the budget to keep them at the coffee pot waiting on the network. So, what further information do you need from me to track this one down? Dan Several tips. Please check your DNS configuration. Such delay is usually caused by the DNS lookups timing out. That means that the servers probably trying to resolve names against an old DNS server that is not around. Look at resolve.conf and make sure only valid DNS servers are there and they are in the proper order. If this does not help please turn on SSSD debug_level to 10, sanitize and send the SSSD domain logs and sssd.conf to the list. More hints can be found here: https://fedorahosted.org/sssd/wiki/Troubleshooting DNS lookups are good - 'dig' and 'dig -x' return instantaneous forward and reverse lookups on the IPA server, the target server, and the client. The only DNS server configured is the IPA server. I did catch some sssd logs. I set logging to 0x0450 instead of 10, and I didn't have time to compare if any different information was caught. If you still need me to specify log level 10 or some other setting, let me know. The login that these logs are for took 15.371 seconds (checked via 'time ssh danofs...@yoda.example.lcl exit' selinux_child.log: http://fpaste.org/207805/ sssd_sudo.log: http://fpaste.org/207806/ sssd_pac.log: http://fpaste.org/207807/ sssd_pam.log: http://fpaste.org/207808/67775142/ sssd_nss.log: http://fpaste.org/207809/ sssd.log: http://fpaste.org/207810/ sssd_example.lcl.log: http://fpaste.org/207811/36832514/ We've recently found a performance problem in the SELinux code. Can you check if setting: selinux_provider = none improves the performance anyhow? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] multihome - single interface?
On 5.4.2015 20:03, Dmitri Pal wrote: On 04/05/2015 12:51 PM, Janelle wrote: Hello, Trying to find a way on a multi-homed server to force IPA and its related apps to listen on a specific interface. I can find all kinds of info saying the services listen on all interfaces by default so there must be a way? It is not automated but you can reconfigure every single service on FreeIPA server manually. Please follow documentation for particular services (Apache, BIND, etc.). -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Question on freeipa-server-trust-ad
On Sat, 04 Apr 2015, Coy Hile wrote: Hi all, What purpose does this package serve? The way I’ve done Kerberos between Active Directory and AD, the trust was always one way (outgoing): the MIT realm is authoritative and AD “shadow accounts” were mapped to ‘real’ principals via the alternateSecurityID attribute. Looking at what freeipa-server-trust-ad installs, it appears the dependencies installed are around letting someone a bidirectional trust (or at least let the AD users be authoritative). If one wants to setup his trust in the way I described, all he really needs to do in MIT land is create krbtgt/AD.REALM@MIT.REALM in the MIT Realm. Is there a ‘supported’ way to do something similar with FreeIPA? Time to break out kadmin.local -x ipa-setup-override-restrictions? Or would that not drop the principal in the right place in the LDAP tree? Let me answer this mail as Simo didn't answer a key part of it and I feel with a growing number of subscribers and people looking at the archives it might bring a lot of misunderstanding. FreeIPA implements cross-forest trust to AD in terms of AD protocols. Part of it is Kerberos cross-realm trust, right, but not only that. In particular, FreeIPA side uses Samba to implement required NetLogon, LSA, and SAMR interfaces required by AD to validate the trust. This causes AD DCs to think that FreeIPA realm is a proper AD forest, not just 'external Kerberos realm'. As result, a proper set of trusted domain objects is created in AD and can be used by FreeIPA to perform lookups of AD users and groups and a proper information about internal FreeIPA realm structure is conveyed to AD DCs, including details of DNS ownership which are crucial to decide what KDCs are responsible in handling specific hosts and subdomains. We are deliberately not supporting external Kerberos trust with Active Directory because we believe this has very little value in an enterprise environment without additional means to deliver such topology details and SID to name and name to SID translation for Kerberos principals on each Windows client. Instead of focusing on a manual maintenance of such mappings on Windows side which would have required us to spend time on implementing software for Windows with obvious limitations due to need to rewrite half of LSA stack on Windows to support all features we want (look at pGINA story and how they failed with it), we chose to concentrate on improving Linux interoperability based on the protocols Microsoft has to support itself to make sure their own Windows clients would work. Right now FreeIPA only supports looking up AD users and groups and is not being able to provide a fully-compliant service so that AD DCs could look up FreeIPA users and groups. This results in Windows machines not being able to resolve SIDs of FreeIPA users and groups to human-friendly names and therefore inability to assign permissions in Windows user interfaces in Security tabs to allow or deny certain access rights to resources on Windows machines. We are working on implementing remaining components so that it will be possible to use FreeIPA users on Windows side too. Even with those components we are not going to implement all features required to present ourselves as Active Directory so no direct join of Windows machines to FreeIPA is planned. Instead, we are continuing to pursue an approach where FreeIPA is seen by AD as another AD forest and trust relationship is used to provide access to resources in both forests. Samba usage in FreeIPA, thus, is limited to being a 'NT4 member server', using LDAP store of FreeIPA to keep users, groups, and trusted domains' accounts. Samba's Active Directory Domain Controller mode is not used but we are working on making sure FreeIPA and Samba AD DC are capable to trust each other as cross-forest trust and, thus, Samba AD DC would be used to enroll Windows machines while Linux machines would be enrolled to FreeIPA. We are at a stage where there is a hope to demonstrate a working solution during SambaXP conference next month and have all the bits and pieces merged upstream Samba. A somewhat detailed overview how FreeIPA trust to AD works is available in the design section of http://www.freeipa.org/page/V4/One-way_trust -- what is described as 'FreeIPA v3.0 and v3.3' is applicable to v4.1 too, we plan to complete the changes by v4.2. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replication issues
Hi Thierry, Thanks for the reply. Turned out that the slapi-plugin was not ignoring the replicated operations. Problem solved. Regards. --Prashant On 6 April 2015 at 23:25, thierry bordaz tbor...@redhat.com wrote: Hello Prashant, If you are able to reproduce the problem (ipasshpubkey not replicated), would you enable replication and plugin logging ( http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#Troubleshooting) and provide the access/errors logs ? thanks thierry On 04/06/2015 04:38 PM, Prashant Bapat wrote: Hi, Seems like there is an issue with replication that I have encountered. I'm using a custom attribute and a slapi-plugin. Below is the attribute added. dn: cn=schema changetype: modify add: attributeTypes attributeTypes: (2.16.840.1.113730.3.8.11.31.1 NAME 'ipaSshSigTimestamp' DESC 'SSH public key signature and timestamp' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'APIGEE FREEIPA EXTENSION' ) - add: objectclasses objectclasses: ( 2.16.840.1.113730.3.8.11.31.2 NAME 'ApigeeUserAttr' SUP top AUXILIARY DESC 'APIGEE FREEIPA EXTENSION' MAY ipaSshSigTimestamp ) This is the only change. Problem: I'm using a python script calling the user_add and user_mod to add user and then add ssh key to the user. After this the custom attr (ipaSshSigTimestamp) is getting replicated to the other master but the standard ipaSshPubKey is not. This had happened once before in the exact same setup. I removed the second master and re-installed it and it was working. But same problem again. Any pointers appreciated. Regards. --Prashant -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Antwort: Re: Upgrade fail 3.3.3 (rhel7) to 4.1 (rhel7.1)
Hello, comments inline Martin On 02/04/15 18:54, Christoph Kaminski wrote: see this in ipupgrade.log 2015-04-02T11:27:02Z ERROR Pre schema upgrade failed with [Errno 111] Connection refused 2015-04-02T11:27:02Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py, line 128, in __pre_schema_upgrade ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True, live_run=self.live_run, plugins=True) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 220, in __init__ self.create_connection() File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 783, in create_connection dm_password=self.dm_password, pw_name=self.pw_name) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 65, in connect conn.do_external_bind(pw_name) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 1173, in wait_for_open_socket raise e error: [Errno 111] Connection refused This is the issue. Do you have any errors in DS error log? /var/log/dirsrv/slapd-INSTANCE/errors 2015-04-02T11:27:02Z DEBUG duration: 12 seconds 2015-04-02T11:27:02Z DEBUG [6/10]: updating schema 2015-04-02T11:27:12Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 372, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py, line 145, in __update_schema dm_password='', ldapi=True, live_run=self.live_run) or self.modified File /usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py, line 112, in update_schema fqdn=installutils.get_fqdn()) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 65, in connect conn.do_external_bind(pw_name) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 1173, in wait_for_open_socket raise e error: [Errno 111] Connection refused 2015-04-02T11:27:12Z DEBUG [error] error: [Errno 111] Connection refused 2015-04-02T11:27:12Z DEBUG [cleanup]: stopping directory server ... Is this another upgrade? Or why is here this time gap? 2015-04-02T12:46:11Z DEBUG stderr= 2015-04-02T12:46:12Z DEBUG File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in execute return_value = self.run() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py, line 213, in run modified = ld.update(self.files, ordered=True) or modified File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 874, in update updates = api.Backend.updateclient.update(POST_UPDATE, self.dm_password, self.ldapi, self.live_run) File /usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py, line 123, in update (restart, apply_now, res) = self.run(update.name, **kw) File /usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py, line 146, in run return self.Updater[method](**kw) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 1399, in __call__ return self.execute(**options) File /usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py, line 76, in execute ldap.add_entry(entry) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1592, in add_entry self.conn.add_s(entry.dn, attrs.items()) File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__ self.gen.throw(type, value, traceback) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1191, in error_handler raise errors.ObjectclassViolation(info=info) 2015-04-02T12:46:12Z DEBUG The ipa-ldap-updater command failed, exception: ObjectclassViolation: unknown object class ipaKeyPolicy 2015-04-02T12:46:12Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: ObjectclassViolation: unknown object class ipaKeyPolicy and: grep -i nsSchemaPolicy
Re: [Freeipa-users] freeipa-server on Raspberry Pi 2
Hi,
I gave it a try, but neither ~/.ipa/default.conf or
/etc/ipa/default.conf did work. I also tried "to fool" the
ipa-server-install script by pausing it and wait for the CA to
start. After "un-pausing" the script the same error occurs: "CA did not start in 300.0s"
I might try to hack the services.py script but anyone got another
suggestion?
Kind regards,
Winfried
Op 02-04-15 om 13:38 schreef Martin
Basti:
On 02/04/15 12:53, Winfried de Heiden
wrote:
Hi all,
"Because I can try" I gave a shot on installing freeipa-server
on a Raspberry Pi 2. I used Fedora 21 for this. Installing
looks promising, but fails somewhere halfway:
[8/27]: starting certificate
server instance
[error] RuntimeError: CA did not start
in 300.0s
CA did not start in 300.0s
and the install log will tell:
[root@ipa log]# tail
/var/log/ipaserver-install.log
File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 279, in start
self.service.start(instance_name,
capture_output=capture_output, wait=wait)
File
"/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py",
line 229, in start
self.wait_until_running()
File
"/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py",
line 223, in wait_until_running
raise RuntimeError('CA did not start
in %ss' % timeout)
2015-04-02T09:58:36Z DEBUG The
ipa-server-install command failed, exception: RuntimeError:
CA did not start in 300.0s
I 'm wondering if this is a timing issue... Of course the Pi2
tends to be slow and no wonder starting things will takes
"some time"... (Yep, I 'm trying to move tons of stones using
only a 2CV car...) The catalina log (that's the CA (Tomcat)
log right?)
tells it needs some more time to start:
[root@ipa pki-tomcat]# tail
/var/log/pki/pki-tomcat/catalina.2015-04-02.log
Apr 02, 2015 11:59:20 AM
org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deployment of configuration
descriptor /etc/pki/pki-tomcat/Catalina/localhost/ROOT.xml
has finished in 84,815 ms
Apr 02, 2015 11:59:20 AM
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler
["http-bio-8080"]
Apr 02, 2015 11:59:20 AM
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler
["http-bio-8443"]
Apr 02, 2015 11:59:20 AM
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler
["ajp-bio-127.0.0.1-8009"]
Apr 02, 2015 11:59:20 AM
org.apache.catalina.startup.Catalina start
INFO: Server startup in 355603 ms
Anyone got an idea how to set the time out
for the CA to start to 10 or 15 minuten? Any other sugestion
what is causing this problem? (no, I am not upgrading from an
older version, this is a fresh install)
Kind regards,
Winfried
Hello,
you can try:
https://www.redhat.com/archives/freeipa-users/2015-April/msg00076.html
--
Martin Basti
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Slow logins on FreeIPA 4.1.2 (F21)
On Tue, Apr 07, 2015 at 11:12:40AM +0200, Martin (Lists) wrote: Am 05.04.2015 um 11:51 schrieb Martin (Lists): Hallo I have a similar issue. On login (graphic systems and ssh) and on the screen saver I have a delay from about 2 secons to 10 seconds. According to my logfile i have the following timeline at login: 0 pam_unix (auth) 3 pam_sss (auth) 3 pam_kwallet (sddm:auth) 4 pam_kwallet (sddm:setcred) 5 pam_unix (session) First collum is the number of seconds after the first action. On myl old server I had a pure kerberos (handmade) system, which reacted almost instandly. Regards Martin Hallo I enabled debugging (set to level 6). selinux provider is set to none. During a login I got data accorting to my attachment. Regards Martin If that's all the data, then the login seems quite fast (3 seconds). The slowdown seems to happen when the krb5 provider is initializing the krb5 ccache for the user. krb5_child.log with a high debug level would show what's happening in particular. (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [be_req_set_domain] (0x0400): Changing request domain from [mittelerde.de] to [mittelerde.de] (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [be_pam_handler] (0x0100): Got request with the following data (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): domain: mittelerde.de (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): user: frodo (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): service: sddm (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): tty: (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): ruser: (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): rhost: (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): authtok type: 1 (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): priv: 1 (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): cli_pid: 6409 (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): logon name: not set (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [be_resolve_server_process] (0x0200): Found address for server gandalf.mittelerde.de: [10.2.33.5] TTL 1200 (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://gandalf.mittelerde.de' (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [write_pipe_handler] (0x0400): All data has been sent! Here we sent data to krb5_child (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [child_sig_handler] (0x0100): child [6410] finished successfully. Here the krb5_child process finished (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [read_pipe_handler] (0x0400): EOF received, client finished (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'gandalf.mittelerde.de' as 'working' (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [set_server_common_status] (0x0100): Marking server 'gandalf.mittelerde.de' as 'working' (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'gandalf.mittelerde.de' as 'working' (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, NULL) [Success] (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [be_pam_handler_callback] (0x0100): Sending result [0][mittelerde.de] (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [be_pam_handler_callback] (0x0100): Sent result [0][mittelerde.de] (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [be_req_set_domain] (0x0400): Changing request domain from [mittelerde.de] to [mittelerde.de] (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [be_pam_handler] (0x0100): Got request with the following data (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): domain: mittelerde.de (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): user: frodo (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): service: sddm (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): tty: (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]]
Re: [Freeipa-users] freeipa-server on Raspberry Pi 2
I realize the default.conf is replaced during install, pausing IPA will
not help.
The easiest way is modify the source file.
ipalib/constants.py:('startup_timeout', 300),
The file should be in /usr/lib/python2.7/site-packages/ipalib/constants.py
Modify file and run ipa-server-install, it should work.
HTH
Martin
On 07/04/15 10:05, Winfried de Heiden wrote:
Hi,
I gave it a try, but neither ~/.ipa/default.conf or
/etc/ipa/default.conf did work. I also tried to fool the
ipa-server-install script by pausing it and wait for the CA to start.
After un-pausing the script the same error occurs: CA did not start
in 300.0s
I might try to hack the services.py script but anyone got another
suggestion?
Kind regards,
Winfried
Op 02-04-15 om 13:38 schreef Martin Basti:
On 02/04/15 12:53, Winfried de Heiden wrote:
Hi all,
Because I can try I gave a shot on installing freeipa-server on a
Raspberry Pi 2. I used Fedora 21 for this. Installing looks
promising, but fails somewhere halfway:
[8/27]: starting certificate server instance
[error] RuntimeError: CA did not start in 300.0s
CA did not start in 300.0s
and the install log will tell:
[root@ipa log]# tail /var/log/ipaserver-install.log
File
/usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 279, in start
self.service.start(instance_name,
capture_output=capture_output, wait=wait)
File
/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py,
line 229, in start
self.wait_until_running()
File
/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py,
line 223, in wait_until_running
raise RuntimeError('CA did not start in %ss' % timeout)
2015-04-02T09:58:36Z DEBUG The ipa-server-install command
failed, exception: RuntimeError: CA did not start in 300.0s
I 'm wondering if this is a timing issue... Of course the Pi2 tends
to be slow and no wonder starting things will takes some time...
(Yep, I 'm trying to move tons of stones using only a 2CV car...)
The catalina log (that's the CA (Tomcat) log right?)
tells it needs some more time to start:
[root@ipa pki-tomcat]# tail
/var/log/pki/pki-tomcat/catalina.2015-04-02.log
Apr 02, 2015 11:59:20 AM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deployment of configuration descriptor
/etc/pki/pki-tomcat/Catalina/localhost/ROOT.xml has finished in
84,815 ms
Apr 02, 2015 11:59:20 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [http-bio-8080]
Apr 02, 2015 11:59:20 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [http-bio-8443]
Apr 02, 2015 11:59:20 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [ajp-bio-127.0.0.1-8009]
Apr 02, 2015 11:59:20 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 355603 ms
Anyone got an idea how to set the time out for the CA to start to 10
or 15 minuten? Any other sugestion what is causing this problem?
(no, I am not upgrading from an older version, this is a fresh install)
Kind regards,
Winfried
Hello,
you can try:
https://www.redhat.com/archives/freeipa-users/2015-April/msg00076.html
--
Martin Basti
--
Martin Basti
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Slow logins on FreeIPA 4.1.2 (F21)
Am 05.04.2015 um 11:51 schrieb Martin (Lists): Hallo I have a similar issue. On login (graphic systems and ssh) and on the screen saver I have a delay from about 2 secons to 10 seconds. According to my logfile i have the following timeline at login: 0 pam_unix (auth) 3 pam_sss (auth) 3 pam_kwallet (sddm:auth) 4 pam_kwallet (sddm:setcred) 5 pam_unix (session) First collum is the number of seconds after the first action. On myl old server I had a pure kerberos (handmade) system, which reacted almost instandly. Regards Martin Hallo I enabled debugging (set to level 6). selinux provider is set to none. During a login I got data accorting to my attachment. Regards Martin (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [be_req_set_domain] (0x0400): Changing request domain from [mittelerde.de] to [mittelerde.de] (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [be_pam_handler] (0x0100): Got request with the following data (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): domain: mittelerde.de (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): user: frodo (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): service: sddm (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): tty: (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): ruser: (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): rhost: (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): authtok type: 1 (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): priv: 1 (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): cli_pid: 6409 (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): logon name: not set (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [be_resolve_server_process] (0x0200): Found address for server gandalf.mittelerde.de: [10.2.33.5] TTL 1200 (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://gandalf.mittelerde.de' (Tue Apr 7 10:52:38 2015) [sssd[be[mittelerde.de]]] [write_pipe_handler] (0x0400): All data has been sent! (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [child_sig_handler] (0x0100): child [6410] finished successfully. (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [read_pipe_handler] (0x0400): EOF received, client finished (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'gandalf.mittelerde.de' as 'working' (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [set_server_common_status] (0x0100): Marking server 'gandalf.mittelerde.de' as 'working' (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'gandalf.mittelerde.de' as 'working' (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, NULL) [Success] (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [be_pam_handler_callback] (0x0100): Sending result [0][mittelerde.de] (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [be_pam_handler_callback] (0x0100): Sent result [0][mittelerde.de] (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [be_req_set_domain] (0x0400): Changing request domain from [mittelerde.de] to [mittelerde.de] (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [be_pam_handler] (0x0100): Got request with the following data (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): domain: mittelerde.de (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): user: frodo (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): service: sddm (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): tty: (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): ruser: (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): rhost: (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): authtok type: 0 (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): priv: 1 (Tue Apr 7 10:52:41 2015) [sssd[be[mittelerde.de]]] [pam_print_data] (0x0100): cli_pid: 6409 (Tue Apr 7
[Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 4.1.0
I have deployed FreeIPA on RedHat 7 and everything is working perfectly fine except when I try to configure SUDO. All my clients are all centos 6 and RedHat 6 clients and have the below config . I have followed every how-to and I just can't seem to get it.I have configured the sudo commands and rules mostly for reading files /usr/bin/vim and /usr/bin/less for reading log files /etc/nssswitch sudoers: files sss cat /etc/sssd/sssd.conf [root@nemo ~]# cat /etc/sssd/sssd.conf [domain/default] autofs_provider = ldap cache_credentials = True krb5_realm = XX.XX.XX krb5_server = XX.XX.XX.XX:88 id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_id_use_start_tls = False ldap_tls_cacertdir = /etc/openldap/cacerts [domain/ai.co.zw] debug_level = 0x07F0 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ai.co.zw id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = XX.XX.XX.XX chpass_provider = ipa ipa_server = _srv_, XX.XX.XX.XX ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, autofs, ssh config_file_version = 2 domains = default, XX.XX.XX [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replication issues
On 04/07/2015 10:51 AM, Prashant Bapat wrote: Hi Thierry, Thanks for the reply. Turned out that the slapi-plugin was not ignoring the replicated operations. Problem solved. Great news ! regards thierry Regards. --Prashant On 6 April 2015 at 23:25, thierry bordaz tbor...@redhat.com mailto:tbor...@redhat.com wrote: Hello Prashant, If you are able to reproduce the problem (ipasshpubkey not replicated), would you enable replication and plugin logging (http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#Troubleshooting) and provide the access/errors logs ? thanks thierry On 04/06/2015 04:38 PM, Prashant Bapat wrote: Hi, Seems like there is an issue with replication that I have encountered. I'm using a custom attribute and a slapi-plugin. Below is the attribute added. dn: cn=schema changetype: modify add: attributeTypes attributeTypes: (2.16.840.1.113730.3.8.11.31.1 NAME 'ipaSshSigTimestamp' DESC 'SSH public key signature and timestamp' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'APIGEE FREEIPA EXTENSION' ) - add: objectclasses objectclasses: ( 2.16.840.1.113730.3.8.11.31.2 NAME 'ApigeeUserAttr' SUP top AUXILIARY DESC 'APIGEE FREEIPA EXTENSION' MAY ipaSshSigTimestamp ) This is the only change. Problem: I'm using a python script calling the user_add and user_mod to add user and then add ssh key to the user. After this the custom attr (ipaSshSigTimestamp) is getting replicated to the other master but the standard ipaSshPubKey is not. This had happened once before in the exact same setup. I removed the second master and re-installed it and it was working. But same problem again. Any pointers appreciated. Regards. --Prashant -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Replication failed
Dear All, Replication was working fine for the last 1 month and recently the replica server (ipa2) is having some hardware issue and it was down for a week. Replication is not working once the machine is up. Please help. [root@ipa etc]# service dirsrv status dirsrv PKI-IPA (pid 29954) is running... dirsrv DOMAIN-COM (pid 30023) is running... [root@ipa2 ~]# service dirsrv status dirsrv DOMAIN-COM (pid 1892) is running... [root@ipa2 ~]# [root@ipa etc]# tail -f /var/log/dirsrv/slapd-TCS-MOBILITY-COM/errors [07/Apr/2015:16:25:50 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:16:25:50 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:16:28:10 +051800] ipa_range_check_pre_op - [file ipa_range_check.c, line 235]: Missing entry to modify. [07/Apr/2015:16:30:50 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:16:30:50 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:16:35:50 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:16:35:50 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:16:35:57 +051800] ipa_range_check_pre_op - [file ipa_range_check.c, line 235]: Missing entry to modify. [07/Apr/2015:16:40:50 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:16:40:50 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) ^C [root@ipa2 ~]# tail -f /var/log/dirsrv/slapd-TCS-MOBILITY-COM/errors [07/Apr/2015:21:58:49 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:21:58:49 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:21:59:01 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:21:59:01 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:21:59:25 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:21:59:25 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:22:00:13 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:22:00:13 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:22:01:49 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:22:01:49 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) Regards Sanju Abraham Linux Admin =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this
Re: [Freeipa-users] Proper configuration of service accounts
On 04/03/2015 03:36 PM, Brian Topping wrote: On Apr 3, 2015, at 6:17 AM, Dmitri Pal d...@redhat.com wrote: On 04/03/2015 01:51 AM, Brian Topping wrote: Great work on 4.1.0! As a CentOS user, I am able to convey the 3.x - 4.1.0 upgrade went smoothly via the CentOS 7.0 - 7.1 upgrade on my replicated pair of IPA instances. Question about proper setup of service accounts: I see that the service accounts I set up under cn=etc, cn=sysaccounts are still able to log in, but the permission changes have left them unable to read anything. Previously, I hacked the ACLs on the domain root. I would like to believe that's not how it should be done. That said, I was surprised that service accounts are not supported in 4.x UI, so I wonder if service accounts (https://www.redhat.com/archives/freeipa-users/2012-June/msg00011.html https://www.redhat.com/archives/freeipa-users/2012-June/msg00011.html) are the wrong way for services like Postfix to be doing LDAP queries. The ACIs changed because we tightened them for the read permissions. I hope you would be able to change them so that your service account works again. Here is the root page of the changes that we implemented. http://www.freeipa.org/page/V4/Permissions_V2 http://www.freeipa.org/page/V4/Permissions_V2 System account is probably the right one for Postfix. It is not in the UI and CLI because other features take precedence. We acknowledge that it needs to be added, we just not have enough time and resources to do it. When we looked at 4.2 we assessed it too and it was on the border line with a good chance of not happening, sorry. Thanks Dmitri. I had known in advance about the ACLs, but couldn't fully appreciate what was going to happen until doing the upgrade. Once it was done, I was kind of surprised that the ACL changes replicated to the 3.x server. As luck would have it, I didn't snapshot both servers at the same time before upgrading either, and eventually, the ACLs managed to work their way back to both the 3.x snapshots (one of them was obviously snapshotted after the other one had been installed with 4.1). I couldn't find upgrade notes with gotchas, this might be a good addition if there are somewhere. It was kind of humorous in all. Interesting, I sort of thought this is automatically implied, given that FreeIPA has a fully replicated environment. Based on your recommendation, I added a note to https://www.freeipa.org/page/Upgrade#Words_of_caution As for the service feature itself, please don't apologize. I think you guys did a spectacular job with this feature set. What I was concerned about is making sure I am doing things as closely as possible to future patterns to reduce upgrade costs. I don't know if it's possible to document the pattern without committing to the feature, but it might be helpful. The one thing I would like to discover at this point is whether roles and privileges build in the UI can be used by system accounts. If so, I could stop editing ACLs directly in LDIF, which is error prone and not the kind of thing I remember too well. FreeIPA 4.x permission system can now assign privileges and new permission ACIs to users, groups, hosts, host groups and services. System accounts are not covered, they should be covered when we have API for them. I added this requirement to the respective RFE: https://fedorahosted.org/freeipa/ticket/2801 Brian, what exactly would you like to achieve? There were changes to the default permissions, some objects are only readable by authenticated users - which should apply also to system users. If you want to add special ACIs using the new/updated permission API (ipa permission-add), I would suggest following procedure: 1) Add the new system account in cn=sysaccounts,cn=etc,dc=rhel71 2) Add the new permissions you want to add, make them a member of a (new) privilege. 3) Create a new role, make the new/updated privileges members of that role 4) Use ldapmodify to make the system account DN member of that role (you just add a new member attribute value) 5) Profit - you should be now able to control permissions to your system account with FreeIPA CLI/UI -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replication failed
On 07/04/15 13:13, Sanju A wrote: Dear All, Replication was working fine for the last 1 month and recently the replica server (ipa2) is having some hardware issue and it was down for a week. Replication is not working once the machine is up. Please help. [root@ipa etc]# service dirsrv status dirsrv PKI-IPA (pid 29954) is running... dirsrv DOMAIN-COM (pid 30023) is running... [root@ipa2 ~]# service dirsrv status dirsrv DOMAIN-COM (pid 1892) is running... [root@ipa2 ~]# [root@ipa etc]# tail -f /var/log/dirsrv/slapd-TCS-MOBILITY-COM/errors [07/Apr/2015:16:25:50 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:16:25:50 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:16:28:10 +051800] ipa_range_check_pre_op - [file ipa_range_check.c, line 235]: Missing entry to modify. [07/Apr/2015:16:30:50 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:16:30:50 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:16:35:50 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:16:35:50 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:16:35:57 +051800] ipa_range_check_pre_op - [file ipa_range_check.c, line 235]: Missing entry to modify. [07/Apr/2015:16:40:50 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:16:40:50 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) ^C [root@ipa2 ~]# tail -f /var/log/dirsrv/slapd-TCS-MOBILITY-COM/errors [07/Apr/2015:21:58:49 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:21:58:49 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:21:59:01 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:21:59:01 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:21:59:25 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:21:59:25 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:22:00:13 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:22:00:13 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:22:01:49 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:22:01:49 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) Regards Sanju Abraham Linux Admin =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly
Re: [Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 4.1.0
On Tue, Apr 07, 2015 at 11:58:35AM +0200, Chamambo Martin wrote: I have deployed FreeIPA on RedHat 7 and everything is working perfectly fine except when I try to configure SUDO. All my clients are all centos 6 and RedHat 6 clients and have the below config . I have followed every how-to and I just can't seem to get it.I have configured the sudo commands and rules mostly for reading files /usr/bin/vim and /usr/bin/less for reading log files /etc/nssswitch sudoers: files sss cat /etc/sssd/sssd.conf [root@nemo ~]# cat /etc/sssd/sssd.conf [domain/default] it is really strange that you have a domain called default (that's the name authconfig normally uses) set to ldap provider. Where does this come from, did you add it manually? This really sounds wrong and I would suggest to remove this domain, but I'd also like to know why did you add it in the first place? autofs_provider = ldap cache_credentials = True krb5_realm = XX.XX.XX krb5_server = XX.XX.XX.XX:88 id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_id_use_start_tls = False ldap_tls_cacertdir = /etc/openldap/cacerts [domain/ai.co.zw] debug_level = 0x07F0 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ai.co.zw id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = XX.XX.XX.XX chpass_provider = ipa ipa_server = _srv_, XX.XX.XX.XX ldap_tls_cacert = /etc/ipa/ca.crt What RHEL/CentOS version are you running in particular? Starting with 6.6, it should be enough to do: sudo_provider = ipa [sssd] services = nss, sudo, pam, autofs, ssh config_file_version = 2 domains = default, XX.XX.XX [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica with external ca + custom subject in certificate
On 04/03/2015 11:39 AM, James James wrote: Hello, I want to initialize a new replica with an external CA. My Certificate Authority wants a CSR with the field emailAddress in the subject like : /C=FR/O=TESTO/OU=TESTOU/CN=*.example.com/emailAddress=n...@none.com I am not a bit confused. Do you plan to have FreeIPA *without* a CA or with own CA signed by external CA? FreeIPA supports these kinds of setups right now: http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructure How can I do with the ipa-server-install command ? I have been trying for few days but I still can't. Thanks for your help. CCing Honza who should know the definitive answer. However, FreeIPA was not very flexible in configuring special subjects for it's CA certificate (i.e. cn=Certificate Authority, ou=...) or hosts in case of CA-less setup. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 4.1.0
Sorry for the confusion about that one ,that client I used to aunthenticate to a pure 389 directory server and I have since changed it to free ipa and below is the correct configuration. I managed to add the line sudo_provider = ipa and im getting the below error on my client [admin@ironhide postfix]$ sudo vim access [sudo] password for admin: Sorry, user admin is not allowed to execute '/usr/bin/vim access' as root on ironhide.ai.co.zw. [admin@ironhide postfix]$ [root@ironhide ~]# cat /etc/sssd/sssd.conf [domain/ai.co.zw] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ai.co.zw id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ironhide.ai.co.zw chpass_provider = ipa ipa_server = _srv_, cyclops.ai.co.zw ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = ai.co.zw [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp] [root@ironhide ~]# -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA Web UI - blank screen
On 04/01/2015 08:42 PM, Janelle wrote: the example of a blank screen -- anyone seen this before? Seems to be very random, but across all browsers. ~J Hello Janelle, Do you see any errors in browser console (part of browser developer tools, usually opened by F12 key) when this happen? https://pvoborni.fedorapeople.org/doc/#!/guide/Debugging -- Petr Vobornik -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] upgrade 3.0 - 4.1
On 04/03/2015 04:45 PM, Tamas Papp wrote: On 04/03/2015 03:46 PM, Brian Topping wrote: On Apr 3, 2015, at 6:48 AM, Tamas Papp tom...@martos.bme.hu wrote: hi All, I have CentOS 6.6 server and want to upgrade to 7.1. What is the upgrade path, can I do it directly or first I need to make it to 3.3? Also is there any known issue I should expect with workarounds? I just did this yesterday, so here's my experience. If you have a simple single-server installation with no custom LDAP DIT modifications, you should find yum upgrade does the right thing. If you do have DIT mods, you should ask yourself why they are there and whether the data will still be accessible after the ACLs are changed. In my case, I had Postfix using a LDAP hash and mail delivery stopped working (although the domain data was still there just fine). Note that the ACLs will propagate from the 4.1 server to your 3.0 if they are replicated. To be safe, back up all replicas (snapshot or whatnot) before the first upgrade and if you decide to restore any of them, be sure everything is shut down and restore all of them to avoid 4.x schema contaminating 3.0 as they come up. Ouch, that must have hurt:) As far as I recall, we have just very small custom changes. Then you should be able to follow the standard migration path without too much issue. To check the biggest changes in FreeIPA 4.1, compared to the old FreeIPA 3.x versions, see http://www.freeipa.org/page/Releases/4.0.0 http://www.freeipa.org/page/Releases/4.1.0 Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa and external ca
On 04/03/2015 08:25 PM, Dmitri Pal wrote: On 04/03/2015 02:03 PM, James James wrote: Hi everybody, sorry to repost my original question but this time my problem is better described. I want to install a ipa sever on centos 6 with an external ca. My problem is to add emailAddress in the subject field when I type the command : [root@ipa-dev ~]# ipa-server-install --external_ca --subject=O=orga,C=FR,OU=MyOU Does somebody knows how to do ? Please wait till Tuesday next week. People who might be able to help are not available due to holidays in Europe. I just replied to the original thread, let us discuss the topic there. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 4.1.0
On Tue, Apr 07, 2015 at 12:48:37PM +0200, Chamambo Martin wrote: Sorry for the confusion about that one ,that client I used to aunthenticate to a pure 389 directory server and I have since changed it to free ipa and below is the correct configuration. I managed to add the line sudo_provider = ipa and im getting the below error on my client I don't see it added to the config. If it's added, the next steps would be to add debug_level to the sudo and domain sections. https://fedorahosted.org/sssd/wiki/Troubleshooting has some notes on gathering the debug logs. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] multihome - single interface?
On 04/05/2015 08:03 PM, Dmitri Pal wrote: On 04/05/2015 12:51 PM, Janelle wrote: Hello, Trying to find a way on a multi-homed server to force IPA and its related apps to listen on a specific interface. I can find all kinds of info saying the services listen on all interfaces by default so there must be a way? Thank you ~J Sounds familiar. I think there is a ticket open for that. This is the RFE: https://fedorahosted.org/freeipa/ticket/3338 Just in case anybody would like to help us extend FreeIPA installers :-) -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] ipa-replica-prepare failing
Hello, I am trying to setup a replica for my master which has been setup with an external CA to use our godaddy wildcard certificate. The ipa-replica-prepare is failing with the following debug information. I am using --http-cert and --dirsrv-cert with my pk12 server certificate. What can I verify to get an idea of what is going wrong? ipa: DEBUG: stderr= ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 169, in execute self.ask_for_options() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py, line 276, in ask_for_options options.http_cert_name) File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py, line 176, in load_pkcs12 host_name=self.replica_fqdn) File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 785, in load_pkcs12 nss_cert = x509.load_certificate(cert, x509.DER) File /usr/lib/python2.7/site-packages/ipalib/x509.py, line 128, in load_certificate return nss.Certificate(buffer(data)) ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The ipa-replica-prepare command failed, exception: NSPRError: (SEC_ERROR_LIBRARY_FAILURE) security library failure. ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: (SEC_ERROR_LIBRARY_FAILURE) security library failure. Regards, D -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode
On Apr 3, 2015, at 14:40, Bobby Prins bobby.pr...@proxy.nl wrote: - Oorspronkelijk bericht - Van: Alexander Bokovoy aboko...@redhat.com Aan: Bobby Prins bobby.pr...@proxy.nl Cc: d...@redhat.com, freeipa-users@redhat.com Verzonden: Vrijdag 3 april 2015 14:26:17 Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode On Fri, 03 Apr 2015, Bobby Prins wrote: - Oorspronkelijk bericht - Van: Alexander Bokovoy aboko...@redhat.com Aan: Bobby Prins bobby.pr...@proxy.nl Cc: d...@redhat.com, freeipa-users@redhat.com Verzonden: Vrijdag 3 april 2015 12:45:07 Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode On Fri, 03 Apr 2015, Bobby Prins wrote: access: [03/Apr/2015:11:58:47 +0200] conn=5950 fd=68 slot=68 connection from 192.168.140.107 to 192.168.140.133 [03/Apr/2015:11:58:47 +0200] conn=5950 op=0 BIND dn= method=128 version=3 [03/Apr/2015:11:58:47 +0200] conn=5950 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn= [03/Apr/2015:11:59:04 +0200] conn=5950 op=1 SRCH base=cn=users,cn=compat,dc=unix,dc=example,dc=corp scope=2 filter=((objectClass=posixaccount)(uid=bpr...@example.corp)) attrs=ALL [03/Apr/2015:11:59:04 +0200] conn=5950 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [03/Apr/2015:11:59:04 +0200] conn=5950 op=2 SRCH base=cn=users,cn=compat,dc=unix,dc=example,dc=corp scope=2 filter=((objectClass=posixaccount)(uid=bprins)) attrs=ALL [03/Apr/2015:11:59:04 +0200] conn=5950 op=2 RESULT err=0 tag=101 nentries=0 etime=0 Above there are two lookups: - successful lookup for user bpri...@example.com - unsuccessful lookup for user bprins What is causing to perform a lookup without @example.com? Compat tree presents AD users fully qualified, it is the only way it knows to trigger lookup via SSSD on IPA master for these users (because non-fully qualified users are in IPA LDAP tree already and copied to compat tree automatically). This seems to be (standard?) behaviour of the AIX LDAP client. Did some more tests with different accounts and always see the two lookups. I doubt if I can influence that.. No, this is not standard -- I haven't seen such behavior when testing FreeIPA with AIX last autumn. -- / Alexander Bokovoy OK, with the idsldap client software and an AD trust configured? This is on AIX7.1. I'm spinning up an AIX5.3 machine now for another test. Might try AIX6.1 as well. What works is creating the user object in freeIPA so the lookup succeeds. After that I can authenticate succesfully against AD. Not the solution I'm looking for though. Did some tests with AIX5.3 and then I don’t run into any issues. There is no lookup to be seen after entering my username on AIX5.3 (as there was on AIX7.1), only the authentication request which succeeds. Will test AIX6.1 later on.. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica with external ca + custom subject in certificate
ok. Is there a way to migrate from an external CA to a CA-less or a self-signed CA ? 2015-04-07 12:51 GMT+02:00 Martin Kosek mko...@redhat.com: On 04/03/2015 11:39 AM, James James wrote: Hello, I want to initialize a new replica with an external CA. My Certificate Authority wants a CSR with the field emailAddress in the subject like : /C=FR/O=TESTO/OU=TESTOU/CN=*.example.com/emailAddress=n...@none.com I am not a bit confused. Do you plan to have FreeIPA *without* a CA or with own CA signed by external CA? FreeIPA supports these kinds of setups right now: http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructure How can I do with the ipa-server-install command ? I have been trying for few days but I still can't. Thanks for your help. CCing Honza who should know the definitive answer. However, FreeIPA was not very flexible in configuring special subjects for it's CA certificate (i.e. cn=Certificate Authority, ou=...) or hosts in case of CA-less setup. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replication failed
Dear Martin, Thanks for your help and the replication issue got resolved after syncing the time. But I am not able to login to the replica server web ui. Keep on getting Your session has expired. Please re-login.. Please find the logs. [07/Apr/2015:17:24:49 +051800] csngen_new_csn - Warning: too much time skew (-20287 secs). Current seqnum=1 [07/Apr/2015:17:24:49 +051800] csngen_new_csn - Warning: too much time skew (-20288 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20288 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20289 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20290 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20291 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20292 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20293 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20294 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20295 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20296 secs). Current seqnum=1 [07/Apr/2015:17:24:51 +051800] csngen_new_csn - Warning: too much time skew (-20296 secs). Current seqnum=1 [07/Apr/2015:17:24:51 +051800] csngen_new_csn - Warning: too much time skew (-20297 secs). Current seqnum=1 [07/Apr/2015:17:24:51 +051800] csngen_new_csn - Warning: too much time skew (-20298 secs). Current seqnum=1 [07/Apr/2015:17:24:51 +051800] csngen_new_csn - Warning: too much time skew (-20299 secs). Current seqnum=1 [07/Apr/2015:17:24:52 +051800] csngen_new_csn - Warning: too much time skew (-20299 secs). Current seqnum=1 [07/Apr/2015:17:24:52 +051800] csngen_new_csn - Warning: too much time skew (-20300 secs). Current seqnum=1 [07/Apr/2015:17:24:52 +051800] csngen_new_csn - Warning: too much time skew (-20301 secs). Current seqnum=1 [07/Apr/2015:17:24:52 +051800] csngen_new_csn - Warning: too much time skew (-20302 secs). Current seqnum=1 [07/Apr/2015:17:24:54 +051800] csngen_new_csn - Warning: too much time skew (-20301 secs). Current seqnum=1 [07/Apr/2015:17:24:54 +051800] csngen_new_csn - Warning: too much time skew (-20302 secs). Current seqnum=1 [07/Apr/2015:17:24:54 +051800] csngen_new_csn - Warning: too much time skew (-20303 secs). Current seqnum=1 Regards Sanju Abraham Linux Admin From: Martin Basti mba...@redhat.com To: Sanju A sanj...@tcs.com, freeipa-users@redhat.com Date: 07-04-2015 16:53 Subject:Re: [Freeipa-users] Replication failed On 07/04/15 13:13, Sanju A wrote: Dear All, Replication was working fine for the last 1 month and recently the replica server (ipa2) is having some hardware issue and it was down for a week. Replication is not working once the machine is up. Please help. [root@ipa etc]# service dirsrv status dirsrv PKI-IPA (pid 29954) is running... dirsrv DOMAIN-COM (pid 30023) is running... [root@ipa2 ~]# service dirsrv status dirsrv DOMAIN-COM (pid 1892) is running... [root@ipa2 ~]# [root@ipa etc]# tail -f /var/log/dirsrv/slapd-TCS-MOBILITY-COM/errors [07/Apr/2015:16:25:50 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:16:25:50 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:16:28:10 +051800] ipa_range_check_pre_op - [file ipa_range_check.c, line 235]: Missing entry to modify. [07/Apr/2015:16:30:50 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:16:30:50 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:16:35:50 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:16:35:50 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:16:35:57 +051800] ipa_range_check_pre_op - [file ipa_range_check.c, line 235]: Missing entry to modify. [07/Apr/2015:16:40:50 +051800] slapd_ldap_sasl_interactive_bind - Error: could not
Re: [Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 4.1.0
Thanx Jakub for pointing me to the right direction .This is what I have now and I have increased the debug level during troubleshooting [domain/ai.co.zw] debug_level=3 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ai.co.zw id_provider = ipa sudo_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ironhide.ai.co.zw chpass_provider = ipa ipa_server = _srv_, cyclops.ai.co.zw ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = ai.co.zw [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] Error messages from /var/log/sssd/sssd_ai.co.zw when debug level is set at 4 [root@ironhide ~]# tail -f /var/log/sssd/sssd_ai.co.zw.log (Tue Apr 7 13:53:42 2015) [sssd[be[ai.co.zw]]] [set_server_common_status] (0x0100): Marking server 'cyclops.ai.co.zw' as 'working' (Tue Apr 7 13:53:42 2015) [sssd[be[ai.co.zw]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. (Tue Apr 7 13:53:42 2015) [sssd[be[ai.co.zw]]] [sysdb_range_create] (0x0040): Invalid range, skipping. Expected that either the secondary base RID or the SID of the trusted domain is set, but not both or none of them. (Tue Apr 7 13:53:42 2015) [sssd[be[ai.co.zw]]] [sysdb_range_create] (0x0040): Invalid range, skipping. Expected that either the secondary base RID or the SID of the trusted domain is set, but not both or none of them. (Tue Apr 7 13:53:42 2015) [sssd[be[ai.co.zw]]] [ipa_subdomains_handler_master_done] (0x0020): Master domain record not found! (Tue Apr 7 13:53:42 2015) [sssd[be[ai.co.zw]]] [ipa_subdomains_handler_master_done] (0x0020): Master domain record not found! (Tue Apr 7 13:53:43 2015) [sssd[be[ai.co.zw]]] [be_get_account_info] (0x0100): Got request for [4099][1][name=postfix] (Tue Apr 7 13:53:43 2015) [sssd[be[ai.co.zw]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Tue Apr 7 13:53:43 2015) [sssd[be[ai.co.zw]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Tue Apr 7 13:53:43 2015) [sssd[be[ai.co.zw]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Tue Apr 7 13:53:58 2015) [sssd[be[ai.co.zw]]] [be_get_account_info] (0x0100): Got request for [4099][1][name=postfix] (Tue Apr 7 13:53:58 2015) [sssd[be[ai.co.zw]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Tue Apr 7 13:53:58 2015) [sssd[be[ai.co.zw]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Tue Apr 7 13:53:58 2015) [sssd[be[ai.co.zw]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [be_get_account_info] (0x0100): Got request for [3][1][name=admin] (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [be_pam_handler] (0x0100): Got request with the following data (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100): domain: ai.co.zw (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100): user: admin (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100): service: sudo (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100): tty: /dev/pts/1 (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100): ruser: admin (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100): rhost: (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100): authtok type: 1 (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Apr 7 13:53:59 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100): priv: 0 (Tue Apr 7 13:53:59
Re: [Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 4.1.0
On Tue, Apr 07, 2015 at 01:55:43PM +0200, Chamambo Martin wrote: Thanx Jakub for pointing me to the right direction .This is what I have now and I have increased the debug level during troubleshooting [domain/ai.co.zw] debug_level=3 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ai.co.zw id_provider = ipa sudo_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ironhide.ai.co.zw chpass_provider = ipa ipa_server = _srv_, cyclops.ai.co.zw ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = ai.co.zw [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] Error messages from /var/log/sssd/sssd_ai.co.zw when debug level is set at 4 This snippet just shows successfull authentication, which I guess is when sudo asked for the password. Anything interesting in the sudo log? /var/log/sssd/sssd_sudo.log You might need a higher debug_level, though (6?) -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica with external ca + custom subject in certificate
On 04/07/2015 01:44 PM, James James wrote: ok. Is there a way to migrate from an external CA to a CA-less or a self-signed CA ? Yes, you can use ipa-cacert-manage tool introduced in FreeIPA 4.1.0: https://www.freeipa.org/page/Howto/CA_Certificate_Renewal https://www.freeipa.org/page/V4/CA_certificate_renewal (Although I am still not sure about your use case and if this would help you) 2015-04-07 12:51 GMT+02:00 Martin Kosek mko...@redhat.com: On 04/03/2015 11:39 AM, James James wrote: Hello, I want to initialize a new replica with an external CA. My Certificate Authority wants a CSR with the field emailAddress in the subject like : /C=FR/O=TESTO/OU=TESTOU/CN=*.example.com/emailAddress=n...@none.com I am not a bit confused. Do you plan to have FreeIPA *without* a CA or with own CA signed by external CA? FreeIPA supports these kinds of setups right now: http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructure How can I do with the ipa-server-install command ? I have been trying for few days but I still can't. Thanks for your help. CCing Honza who should know the definitive answer. However, FreeIPA was not very flexible in configuring special subjects for it's CA certificate (i.e. cn=Certificate Authority, ou=...) or hosts in case of CA-less setup. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica with external ca + custom subject in certificate
I will try to give a better explanation : I have a CentOS 6.6 with ipa 3.0 named ipa-master. ipa-master has been installed with an external CA about 3 years ago and I will have to renew the certificate soon. I have created a test server (ipa-dev) with the same configuration (centos 6.6 and ipa 3.0) to test the renewal process. I want the new ipa-dev sever to be installed with an external CA. In the same time my external CA has changed and wants the emailAddress field in the certificate request 's subject. If it is not possible to add emailAddress in the subject, is it possible to migrate my ipa-master CA system from an external CA to a CA-less or self-signed CA ? Thanks. 2015-04-07 13:48 GMT+02:00 Martin Kosek mko...@redhat.com: On 04/07/2015 01:44 PM, James James wrote: ok. Is there a way to migrate from an external CA to a CA-less or a self-signed CA ? Yes, you can use ipa-cacert-manage tool introduced in FreeIPA 4.1.0: https://www.freeipa.org/page/Howto/CA_Certificate_Renewal https://www.freeipa.org/page/V4/CA_certificate_renewal (Although I am still not sure about your use case and if this would help you) 2015-04-07 12:51 GMT+02:00 Martin Kosek mko...@redhat.com: On 04/03/2015 11:39 AM, James James wrote: Hello, I want to initialize a new replica with an external CA. My Certificate Authority wants a CSR with the field emailAddress in the subject like : /C=FR/O=TESTO/OU=TESTOU/CN=*.example.com/emailAddress=n...@none.com I am not a bit confused. Do you plan to have FreeIPA *without* a CA or with own CA signed by external CA? FreeIPA supports these kinds of setups right now: http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructure How can I do with the ipa-server-install command ? I have been trying for few days but I still can't. Thanks for your help. CCing Honza who should know the definitive answer. However, FreeIPA was not very flexible in configuring special subjects for it's CA certificate (i.e. cn=Certificate Authority, ou=...) or hosts in case of CA-less setup. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replication failed
Great! additional comments inline Martin On 07/04/15 13:56, Sanju A wrote: Dear Martin, Thanks for your help and the replication issue got resolved after syncing the time. But I am not able to login to the replica server web ui. Keep on getting Your session has expired. Please re-login.. Please find the logs. Does CLI command works on the server? What do you use, form based authentication or kerberos to login to webUI? Did you try to clean browser cache (or kdestroy)? You can find something useful in this thread, https://www.redhat.com/archives/freeipa-users/2015-April/msg00047.html [07/Apr/2015:17:24:49 +051800] csngen_new_csn - Warning: too much time skew (-20287 secs). Current seqnum=1 [07/Apr/2015:17:24:49 +051800] csngen_new_csn - Warning: too much time skew (-20288 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20288 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20289 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20290 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20291 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20292 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20293 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20294 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20295 secs). Current seqnum=1 [07/Apr/2015:17:24:50 +051800] csngen_new_csn - Warning: too much time skew (-20296 secs). Current seqnum=1 [07/Apr/2015:17:24:51 +051800] csngen_new_csn - Warning: too much time skew (-20296 secs). Current seqnum=1 [07/Apr/2015:17:24:51 +051800] csngen_new_csn - Warning: too much time skew (-20297 secs). Current seqnum=1 [07/Apr/2015:17:24:51 +051800] csngen_new_csn - Warning: too much time skew (-20298 secs). Current seqnum=1 [07/Apr/2015:17:24:51 +051800] csngen_new_csn - Warning: too much time skew (-20299 secs). Current seqnum=1 [07/Apr/2015:17:24:52 +051800] csngen_new_csn - Warning: too much time skew (-20299 secs). Current seqnum=1 [07/Apr/2015:17:24:52 +051800] csngen_new_csn - Warning: too much time skew (-20300 secs). Current seqnum=1 [07/Apr/2015:17:24:52 +051800] csngen_new_csn - Warning: too much time skew (-20301 secs). Current seqnum=1 [07/Apr/2015:17:24:52 +051800] csngen_new_csn - Warning: too much time skew (-20302 secs). Current seqnum=1 [07/Apr/2015:17:24:54 +051800] csngen_new_csn - Warning: too much time skew (-20301 secs). Current seqnum=1 [07/Apr/2015:17:24:54 +051800] csngen_new_csn - Warning: too much time skew (-20302 secs). Current seqnum=1 [07/Apr/2015:17:24:54 +051800] csngen_new_csn - Warning: too much time skew (-20303 secs). Current seqnum=1 From which log is this? Regards Sanju Abraham Linux Admin From: Martin Basti mba...@redhat.com To: Sanju A sanj...@tcs.com, freeipa-users@redhat.com Date: 07-04-2015 16:53 Subject: Re: [Freeipa-users] Replication failed On 07/04/15 13:13, Sanju A wrote: Dear All, Replication was working fine for the last 1 month and recently the replica server (ipa2) is having some hardware issue and it was down for a week. Replication is not working once the machine is up. Please help. [root@ipa etc]# service dirsrv status dirsrv PKI-IPA (pid 29954) is running... dirsrv DOMAIN-COM (pid 30023) is running... [root@ipa2 ~]# service dirsrv status dirsrv DOMAIN-COM (pid 1892) is running... [root@ipa2 ~]# [root@ipa etc]# tail -f /var/log/dirsrv/slapd-TCS-MOBILITY-COM/errors [07/Apr/2015:16:25:50 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:16:25:50 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:16:28:10 +051800] ipa_range_check_pre_op - [file ipa_range_check.c, line 235]: Missing entry to modify. [07/Apr/2015:16:30:50 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success) [07/Apr/2015:16:30:50 +051800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) [07/Apr/2015:16:35:50 +051800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13):
Re: [Freeipa-users] Creating arbitrary users?
On Mon, 2015-04-06 at 21:16 -0400, Coy Hile wrote: In MIT land, one can potentially have multiple instances tied (by convention) to a given user (that is, that administratively one knows are the same set of eyeballs). For example, I might have my normal user (hile), and I might have another distinct MIT principal hile/admin used when I’m doing administrative work in the kerb database, or potentially yet another hile/vpn for remote access. Only the first of these is a ‘real’ user that needs to have a uid, gid, home directory, and shell; the others are just Kerberos principals that might have differing password policies applied to them. In FreeIPA, it appears all kerberos principals are tied to a user (or to a host in the case of host/ or another service definition). Is it possible to define a non-posix user? There is no good reason for hile/admin@MY.REALM to have a uidNumber or gidNumber; one should never login directly using that principal. Early on when we created FreeIPA we decided against providing alternative principals for the same user as it made things a lot more complex for little gain. To this day we still do not support them. Keep in mind that adding a principal is not the whole story, once you do that then you probably still want to associate it to some user, and assign privileges and allow alternative principal names to ssh into some machines, which means distributing k5login files or providing explicit support in the new aname2lname plugin. To do all this means adding new objects and configuration facilities to handle these special non-users, we haven't yet found enough benefit in adding support for these to warrant the work involved. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 4.1.0
Thanx for the feedback ,let me read a bit and will share how I managed to resolve it -Original Message- From: Lukas Slebodnik [mailto:lsleb...@redhat.com] Sent: Tuesday, April 07, 2015 2:16 PM To: Jakub Hrozek Cc: Chamambo Martin; freeipa-users@redhat.com Subject: Re: [Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 4.1.0 On (07/04/15 12:57), Jakub Hrozek wrote: On Tue, Apr 07, 2015 at 12:48:37PM +0200, Chamambo Martin wrote: Sorry for the confusion about that one ,that client I used to aunthenticate to a pure 389 directory server and I have since changed it to free ipa and below is the correct configuration. I managed to add the line sudo_provider = ipa and im getting the below error on my client I don't see it added to the config. It's not necessary to add sudo_provider = ipa into domain section. because if sudo_provider is not specified then it is automatically inherited from id_provider. It is described in documentation [1] (point 4) and also in the manual page sssd-sudo. IIRC ipa-client-install should configure all necessary things on rhel 7.1 If it's added, the next steps would be to add debug_level to the sudo and domain sections. https://fedorahosted.org/sssd/wiki/Troubleshooting has some notes on gathering the debug logs. +1 LS [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/Configuring_Services.html#configuring-sssd-sudo -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Creating arbitrary users?
On Tue, 2015-04-07 at 14:16 +, coy.h...@coyhile.com wrote: Quoting Simo Sorce s...@redhat.com On Mon, 2015-04-06 at 21:16 -0400, Coy Hile wrote: In MIT land, one can potentially have multiple instances tied (by convention) to a given user (that is, that administratively one knows are the same set of eyeballs). For example, I might have my normal user (hile), and I might have another distinct MIT principal hile/admin used when I’m doing administrative work in the kerb database, or potentially yet another hile/vpn for remote access. Only the first of these is a ‘real’ user that needs to have a uid, gid, home directory, and shell; the others are just Kerberos principals that might have differing password policies applied to them. In FreeIPA, it appears all kerberos principals are tied to a user (or to a host in the case of host/ or another service definition). Is it possible to define a non-posix user? There is no good reason for hile/admin@MY.REALM to have a uidNumber or gidNumber; one should never login directly using that principal. Early on when we created FreeIPA we decided against providing alternative principals for the same user as it made things a lot more complex for little gain. To this day we still do not support them. Keep in mind that adding a principal is not the whole story, once you do that then you probably still want to associate it to some user, and assign privileges and allow alternative principal names to ssh into some machines, which means distributing k5login files or providing explicit support in the new aname2lname plugin. To do all this means adding new objects and configuration facilities to handle these special non-users, we haven't yet found enough benefit in adding support for these to warrant the work involved. Simo. -- Simo Sorce * Red Hat, Inc * New York I guess that makes sense. Is it possible to add a user that simply doesn't have the posix attributes defined? In the particular case of */admin, I would expect that user to login to the ipa ui or to be kinit'd to prior to running ipa administrative commands, but I should hope that it should never login directly. Does that question make more sense? It does, but we do not have such a feature, sorry. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica with external ca + custom subject in certificate
On 04/07/2015 02:08 PM, James James wrote: I will try to give a better explanation : I have a CentOS 6.6 with ipa 3.0 named ipa-master. ipa-master has been installed with an external CA about 3 years ago and I will have to renew the certificate soon. I have created a test server (ipa-dev) with the same configuration (centos 6.6 and ipa 3.0) to test the renewal process. I want the new ipa-dev sever to be installed with an external CA. In the same time my external CA has changed and wants the emailAddress field in the certificate request 's subject. CSR during installation with external CA is produced by Dogtag, so you are constrained with the options and capabilities provided by ipa-server-install. Maybe it would be possible to modify the CSR and update the Subject manually, but I expect it would crash the installer later (JanC may know more (CCed)) If it is not possible to add emailAddress in the subject, is it possible to migrate my ipa-master CA system from an external CA to a CA-less or self-signed CA ? It is, with ipa-cacert-manage - see links below. Thanks. 2015-04-07 13:48 GMT+02:00 Martin Kosek mko...@redhat.com: On 04/07/2015 01:44 PM, James James wrote: ok. Is there a way to migrate from an external CA to a CA-less or a self-signed CA ? Yes, you can use ipa-cacert-manage tool introduced in FreeIPA 4.1.0: https://www.freeipa.org/page/Howto/CA_Certificate_Renewal https://www.freeipa.org/page/V4/CA_certificate_renewal (Although I am still not sure about your use case and if this would help you) 2015-04-07 12:51 GMT+02:00 Martin Kosek mko...@redhat.com: On 04/03/2015 11:39 AM, James James wrote: Hello, I want to initialize a new replica with an external CA. My Certificate Authority wants a CSR with the field emailAddress in the subject like : /C=FR/O=TESTO/OU=TESTOU/CN=*.example.com/emailAddress=n...@none.com I am not a bit confused. Do you plan to have FreeIPA *without* a CA or with own CA signed by external CA? FreeIPA supports these kinds of setups right now: http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructure How can I do with the ipa-server-install command ? I have been trying for few days but I still can't. Thanks for your help. CCing Honza who should know the definitive answer. However, FreeIPA was not very flexible in configuring special subjects for it's CA certificate (i.e. cn=Certificate Authority, ou=...) or hosts in case of CA-less setup. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] FreeIPA 4 AD Integration issue
Hey all, I’m having a problem with integrating a FreeIPA4 infrastructure to an AD environment. AD Domain is fioptics.int FreeIPA infrastructure is preprod.fioptics.int The AD Controller in this environment is at 10.32.145.134 The FreeIPA 4 server is at 10.32.146.40 I’m attaching the procedure that I’m using below for review. Everything works perfectly, even the DNS testing, up until I run the command to initiate the trust. Then it ALWAYS c comes back with unable to find server. The DNS tests I’ve done from AD and from IPA are also listed below. This procedure works flawlessly in the virtual test environment every time. There are NO firewalls between the IPA box and the AD box. Software firewalls on both boxes are down. Selinux is disabled. The only differences are 1. They are on different subnets but I don’t see how that should matter, and 2. There is a load balancer between them, but again DNS resolves and a nmap shows all the necessary ports are available. If anyone has any advice it would be greatly appreciated. I have to get this working asap for the deployment of the project. Thanks in advance. — DNS Results — Active Directory — Server: ppad01.fioptics.int Address: 10.32.145.134 _ldap._tcp.fioptics.int SRV service location: priority = 0 weight = 100 port = 389 svr hostname = mtad01.fioptics.int _ldap._tcp.fioptics.int SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ppad01.fioptics.int _ldap._tcp.fioptics.int SRV service location: priority = 0 weight = 100 port = 389 svr hostname = p1ad01.fioptics.int _ldap._tcp.fioptics.int SRV service location: priority = 0 weight = 100 port = 389 svr hostname = mtad02.fioptics.int _ldap._tcp.fioptics.int SRV service location: priority = 0 weight = 100 port = 389 svr hostname = stad01.fioptics.int mtad01.fioptics.int internet address = 10.32.162.182 ppad01.fioptics.int internet address = 10.32.145.134 p1ad01.fioptics.int internet address = 10.32.129.134 mtad02.fioptics.int internet address = 10.32.130.182 stad01.fioptics.int internet address = 10.32.161.134 _ldap._tcp.preprod.fioptics.int Server: ppad01.fioptics.int Address: 10.32.145.134 Non-authoritative answer: _ldap._tcp.preprod.fioptics.int SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ppip01.preprod.fioptics.int _ldap._tcp.preprod.fioptics.int SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ppip02.preprod.fioptics.int ppip01.preprod.fioptics.int internet address = 10.32.146.40 ppip01.preprod.fioptics.int internet address = 10.32.146.40 FreeIPA [root@ppip01 ~]# dig srv _ldap._tcp.fioptics.int ; DiG 9.9.4-RedHat-9.9.4-20.el7.centos.pkcs11 srv _ldap._tcp.fioptics.int ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 26858 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 13, ADDITIONAL: 6 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;_ldap._tcp.fioptics.int. IN SRV ;; ANSWER SECTION: _ldap._tcp.fioptics.int. 600IN SRV 0 100 389 p1ad01.fioptics.int. _ldap._tcp.fioptics.int. 600IN SRV 0 100 389 stad01.fioptics.int. _ldap._tcp.fioptics.int. 600IN SRV 0 100 389 ppad01.fioptics.int. _ldap._tcp.fioptics.int. 600IN SRV 0 100 389 mtad02.fioptics.int. _ldap._tcp.fioptics.int. 600IN SRV 0 100 389 mtad01.fioptics.int. ;; AUTHORITY SECTION: . 11558 IN NS g.root-servers.net. . 11558 IN NS e.root-servers.net. . 11558 IN NS i.root-servers.net. . 11558 IN NS f.root-servers.net. . 11558 IN NS a.root-servers.net. . 11558 IN NS c.root-servers.net. . 11558 IN NS j.root-servers.net. . 11558 IN NS k.root-servers.net. . 11558 IN NS h.root-servers.net. . 11558 IN NS l.root-servers.net. . 11558 IN NS d.root-servers.net. . 11558 IN NS b.root-servers.net. . 11558 IN NS m.root-servers.net. ;; ADDITIONAL SECTION: ppad01.fioptics.int.3057IN A 10.32.145.134 p1ad01.fioptics.int.3600IN A
Re: [Freeipa-users] Creating arbitrary users?
Quoting Simo Sorce s...@redhat.com On Mon, 2015-04-06 at 21:16 -0400, Coy Hile wrote: In MIT land, one can potentially have multiple instances tied (by convention) to a given user (that is, that administratively one knows are the same set of eyeballs). For example, I might have my normal user (hile), and I might have another distinct MIT principal hile/admin used when I’m doing administrative work in the kerb database, or potentially yet another hile/vpn for remote access. Only the first of these is a ‘real’ user that needs to have a uid, gid, home directory, and shell; the others are just Kerberos principals that might have differing password policies applied to them. In FreeIPA, it appears all kerberos principals are tied to a user (or to a host in the case of host/ or another service definition). Is it possible to define a non-posix user? There is no good reason for hile/admin@MY.REALM to have a uidNumber or gidNumber; one should never login directly using that principal. Early on when we created FreeIPA we decided against providing alternative principals for the same user as it made things a lot more complex for little gain. To this day we still do not support them. Keep in mind that adding a principal is not the whole story, once you do that then you probably still want to associate it to some user, and assign privileges and allow alternative principal names to ssh into some machines, which means distributing k5login files or providing explicit support in the new aname2lname plugin. To do all this means adding new objects and configuration facilities to handle these special non-users, we haven't yet found enough benefit in adding support for these to warrant the work involved. Simo. -- Simo Sorce * Red Hat, Inc * New York I guess that makes sense. Is it possible to add a user that simply doesn't have the posix attributes defined? In the particular case of */admin, I would expect that user to login to the ipa ui or to be kinit'd to prior to running ipa administrative commands, but I should hope that it should never login directly. Does that question make more sense? Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone Original message From: Simo Sorce s...@redhat.com Date:04/07/2015 08:52 (GMT-05:00) To: coy.h...@coyhile.com Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Creating arbitrary users? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Slow logins on FreeIPA 4.1.2 (F21)
On Tue, Apr 07, 2015 at 05:57:49PM +0200, Martin (Lists) wrote: Hallo attached you can find the data from krb_child.log. As far as I can see it, the three seconds are due to the communication with the kerberos server. (1.2.3.4 is my server). regards Martin Yes. It looks like kinit takes two seconds and validation one second. You might be interested in: https://fedorahosted.org/sssd/ticket/1807 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Slow logins on FreeIPA 4.1.2 (F21)
On Tue, 2015-04-07 at 17:57 +0200, Martin (Lists) wrote: Hallo attached you can find the data from krb_child.log. As far as I can see it, the three seconds are due to the communication with the kerberos server. (1.2.3.4 is my server). Do you experience the same latency if you kinit manually ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Slow logins on FreeIPA 4.1.2 (F21)
On 04/07/2015 03:05 AM, Jakub Hrozek wrote: On Mon, Apr 06, 2015 at 08:01:46PM -0500, Dan Mossor wrote: On 04/05/2015 12:51 PM, Dmitri Pal wrote: Several tips. Please check your DNS configuration. Such delay is usually caused by the DNS lookups timing out. That means that the servers probably trying to resolve names against an old DNS server that is not around. Look at resolve.conf and make sure only valid DNS servers are there and they are in the proper order. If this does not help please turn on SSSD debug_level to 10, sanitize and send the SSSD domain logs and sssd.conf to the list. More hints can be found here: https://fedorahosted.org/sssd/wiki/Troubleshooting DNS lookups are good - 'dig' and 'dig -x' return instantaneous forward and reverse lookups on the IPA server, the target server, and the client. The only DNS server configured is the IPA server. I did catch some sssd logs. I set logging to 0x0450 instead of 10, and I didn't have time to compare if any different information was caught. If you still need me to specify log level 10 or some other setting, let me know. The login that these logs are for took 15.371 seconds (checked via 'time ssh danofs...@yoda.example.lcl exit' selinux_child.log: http://fpaste.org/207805/ sssd_sudo.log: http://fpaste.org/207806/ sssd_pac.log: http://fpaste.org/207807/ sssd_pam.log: http://fpaste.org/207808/67775142/ sssd_nss.log: http://fpaste.org/207809/ sssd.log: http://fpaste.org/207810/ sssd_example.lcl.log: http://fpaste.org/207811/36832514/ We've recently found a performance problem in the SELinux code. Can you check if setting: selinux_provider = none improves the performance anyhow? Adding selinux_provider = none to the domain section of /etc/sssd/sssd.conf seems to have drastically improved ssh logins. The Apache authentications are faster, but we're still hitting a performance issue somewhere in that chain. It may be with Apache itself, so stand by...but otherwise, I'm calling this fixed. Thanks! -- Dan Mossor Systems Engineer at Large Fedora KDE WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice FAS: dmossor IRC: danofsatx San Antonio, Texas, USA -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Two way trust vs one way trust and IPA features
Hello, I’m wondering if establishing two way trust or one way trust in upcoming 4.2 release somehow is going to affect FreeIPA feature set, like ability to add windows groups to external groups or anything else I may not think of right now? Our Windows security team is expressing concerns about two way trust and we are planning to switch to one way when it becomes available. I’m trying to find out what could be affected. Regards, Andrey -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] upgrade 3.0 - 4.1
hi, On Fri, Apr 3, 2015 at 4:41 PM, Dmitri Pal d...@redhat.com wrote: On 04/03/2015 09:46 AM, Brian Topping wrote: On Apr 3, 2015, at 6:48 AM, Tamas Papp tom...@martos.bme.hu tom...@martos.bme.hu wrote: hi All, I have CentOS 6.6 server and want to upgrade to 7.1. What is the upgrade path, can I do it directly or first I need to make it to 3.3? Also is there any known issue I should expect with workarounds? I just did this yesterday, so here's my experience. If you have a simple single-server installation with no custom LDAP DIT modifications, you should find yum upgrade does the right thing. If you do have DIT mods, you should ask yourself why they are there and whether the data will still be accessible after the ACLs are changed. In my case, I had Postfix using a LDAP hash and mail delivery stopped working (although the domain data was still there just fine). Note that the ACLs will propagate from the 4.1 server to your 3.0 if they are replicated. To be safe, back up all replicas (snapshot or whatnot) before the first upgrade and if you decide to restore any of them, be sure everything is shut down and restore all of them to avoid 4.x schema contaminating 3.0 as they come up. The general recommendation for 3.3 - 4.1 migration is to start introducing 4.1 replicas into your 3.3 environment and then turn your 3.3 replicas off. Do not forget to install the CA component with one of your 4.1 replicas before removing all the 3.3 instanced with CAs. With this procedure you would also need to move the CRL generation and cert tracking. See details in migration section https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#migrating-ipa-proc Will this excellent documentation work too on the migration from 3.0x (rhel 6) to 4.1.x (rhel 7.1)? I will be migrating the coming months to 7.1 or 7.2 (whichever is the current stable then), so just wondering. Thanks! -- Groeten, natxo -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Two way trust vs one way trust and IPA features
On Tue, 07 Apr 2015, Andrey Ptashnik wrote: Hello, I’m wondering if establishing two way trust or one way trust in upcoming 4.2 release somehow is going to affect FreeIPA feature set, like ability to add windows groups to external groups or anything else I may not think of right now? No, it should not affect existing feature set. There will be some tightening of access controls for how administrative tasks would be done to some degree but they already required admin privileges anyway so it is not a change in functionality. Our Windows security team is expressing concerns about two way trust and we are planning to switch to one way when it becomes available. I’m trying to find out what could be affected. Nothing really changes between current use of two-way trust and a future one-way trust in a sense of what is already available to IPA side to look up on AD side. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Creating arbitrary users?
On Tue, 2015-04-07 at 18:54 +, Coy Hile wrote: Quoting Simo Sorce s...@redhat.com: I guess that makes sense. Is it possible to add a user that simply doesn't have the posix attributes defined? In the particular case of */admin, I would expect that user to login to the ipa ui or to be kinit'd to prior to running ipa administrative commands, but I should hope that it should never login directly. Does that question make more sense? It does, but we do not have such a feature, sorry. Simo. Could one hypothetically remove the posix attributes (via some scripted process that validates that what it's doing is inline with organizational norms/goals) without breaking freeIPA, or are the posix attributes MUST in the IPA object classes? I'm sorry for so many endless questions, but having finally got my personal setup/lab using something other than Active Directory, I'm looking to migrate to something that is easier to manage, so I'm trying to draw comparisons between what I had been used to in previous vanilla krb/ldap shops. Removing attributes will probably not work well, but let me ask: Do you require different passwords for these principals ? Or do you merely want to have the alternative names but would be ok if the credentials were identical ? Because you could (manually for now) add aliases so that hile@ hile/admin@ hile/foo@ are the same thing, where hile@ is the canonical name but you can use aliases too (just make sure not to request canonicalization at kinit time. Simo. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Creating arbitrary users?
Quoting Simo Sorce s...@redhat.com: I guess that makes sense. Is it possible to add a user that simply doesn't have the posix attributes defined? In the particular case of */admin, I would expect that user to login to the ipa ui or to be kinit'd to prior to running ipa administrative commands, but I should hope that it should never login directly. Does that question make more sense? It does, but we do not have such a feature, sorry. Simo. Could one hypothetically remove the posix attributes (via some scripted process that validates that what it's doing is inline with organizational norms/goals) without breaking freeIPA, or are the posix attributes MUST in the IPA object classes? I'm sorry for so many endless questions, but having finally got my personal setup/lab using something other than Active Directory, I'm looking to migrate to something that is easier to manage, so I'm trying to draw comparisons between what I had been used to in previous vanilla krb/ldap shops. Thanks, -c -- Coy Hile coy.h...@coyhile.com -- Coy Hile coy.h...@coyhile.com -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Slow logins on FreeIPA 4.1.2 (F21)
On Tue, Apr 07, 2015 at 01:15:46PM -0500, Dan Mossor wrote: On 04/07/2015 03:05 AM, Jakub Hrozek wrote: On Mon, Apr 06, 2015 at 08:01:46PM -0500, Dan Mossor wrote: On 04/05/2015 12:51 PM, Dmitri Pal wrote: Several tips. Please check your DNS configuration. Such delay is usually caused by the DNS lookups timing out. That means that the servers probably trying to resolve names against an old DNS server that is not around. Look at resolve.conf and make sure only valid DNS servers are there and they are in the proper order. If this does not help please turn on SSSD debug_level to 10, sanitize and send the SSSD domain logs and sssd.conf to the list. More hints can be found here: https://fedorahosted.org/sssd/wiki/Troubleshooting DNS lookups are good - 'dig' and 'dig -x' return instantaneous forward and reverse lookups on the IPA server, the target server, and the client. The only DNS server configured is the IPA server. I did catch some sssd logs. I set logging to 0x0450 instead of 10, and I didn't have time to compare if any different information was caught. If you still need me to specify log level 10 or some other setting, let me know. The login that these logs are for took 15.371 seconds (checked via 'time ssh danofs...@yoda.example.lcl exit' selinux_child.log: http://fpaste.org/207805/ sssd_sudo.log: http://fpaste.org/207806/ sssd_pac.log: http://fpaste.org/207807/ sssd_pam.log: http://fpaste.org/207808/67775142/ sssd_nss.log: http://fpaste.org/207809/ sssd.log: http://fpaste.org/207810/ sssd_example.lcl.log: http://fpaste.org/207811/36832514/ We've recently found a performance problem in the SELinux code. Can you check if setting: selinux_provider = none improves the performance anyhow? Adding selinux_provider = none to the domain section of /etc/sssd/sssd.conf seems to have drastically improved ssh logins. The Apache authentications are faster, but we're still hitting a performance issue somewhere in that chain. It may be with Apache itself, so stand by...but otherwise, I'm calling this fixed. Not fixed, merely worked around. Thanks! Thank you for confirming the problem and the workaround. I do have a WIP patch, I just need to finish testing it. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Troubleshooting SSO
On 4/6/15, 2:26 PM, Gould, Joshua joshua.go...@osumc.edu wrote: On 4/4/15, 9:57 AM, Sumit Bose sb...@redhat.com wrote: Really strange but SSO is working from the test Windows box to both the IPA server and client. No changes were made other than I added the linux client to the IPA domain. (It was with ipa-client-install, it auto-discovered the values, which I used and I enrolled it with the admin ad-user). Note: ssh connection from Windows test machine to IPA client and IPA server used the exact same saved putty config other than changing the hostname. SSO from Windows to our two IPA clients seems to work intermittently today. (no config changes on either end) In both cases, the first attempted to connect via Putty/SSO failed but signin to password worked. We then disconnected the ssh session and immediately tried SSO via SSH to the same client SSO worked. We were able to replicate this for both clients. SSH output from the failed SSO logins: (Sorry but the kvno and other command were not captured) To Test Client01: -sh-4.2$ export KRB5_TRACE=/dev/stdout -sh-4.2$ kinit ad-user@TEST.OSUWMC [23557] 1428416095.525107: Getting initial credentials for ad-user@TEST.OSUWMC [23557] 1428416095.527977: Sending request (170 bytes) to TEST.OSUWMC [23557] 1428416095.529496: Resolving hostname test-dc-vt01.test.osuwmc. [23557] 1428416095.530694: Sending initial UDP request to dgram 10.0.0.239:88 [23557] 1428416095.531745: Received answer (187 bytes) from dgram 10.0.0.239:88 [23557] 1428416095.531978: Response was not from master KDC [23557] 1428416095.532006: Received error from KDC: -1765328359/Additional pre-authentication required [23557] 1428416095.532039: Processing preauth types: 16, 15, 19, 2 [23557] 1428416095.532053: Selected etype info: etype aes256-cts, salt TEST.OSUWMCad-user, params [23557] 1428416095.532094: PKINIT client has no configured identity; giving up [23557] 1428416095.532111: PKINIT client has no configured identity; giving up [23557] 1428416095.532122: Preauth module pkinit (16) (real) returned: 22/Invalid argument [23557] 1428416095.532132: PKINIT client has no configured identity; giving up [23557] 1428416095.532139: Preauth module pkinit (14) (real) returned: 22/Invalid argument Password for ad-user@TEST.OSUWMC: [23557] 1428416098.700510: AS key obtained for encrypted timestamp: aes256-cts/BA80 [23557] 1428416098.700574: Encrypted timestamp (for 1428416098.622522): plain 301AA011180F32303135303430373134313435385AA1050203097FBA, encrypted DDE7C80B8F1F1B5877E7E05764895E024E65D83CA6BFB633E4281384E03D60F27AB6A6EDF68 C161720933FD481FF881BE203238F816D4393 [23557] 1428416098.700600: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [23557] 1428416098.700605: Produced preauth for next request: 2 [23557] 1428416098.700626: Sending request (248 bytes) to TEST.OSUWMC [23557] 1428416098.701350: Resolving hostname test-dc-vt01.test.osuwmc. [23557] 1428416098.701661: Sending initial UDP request to dgram 10.0.0.239:88 [23557] 1428416098.703161: Received answer (94 bytes) from dgram 10.0.0.239:88 [23557] 1428416098.703374: Response was not from master KDC [23557] 1428416098.703397: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP [23557] 1428416098.703403: Request or response is too big for UDP; retrying with TCP [23557] 1428416098.703408: Sending request (248 bytes) to TEST.OSUWMC (tcp only) [23557] 1428416098.703735: Resolving hostname test-dc-vt01.test.osuwmc. [23557] 1428416098.704667: Initiating TCP connection to stream 10.0.0.239:88 [23557] 1428416098.705090: Sending TCP request to stream 10.0.0.239:88 [23557] 1428416098.706260: Received answer (1649 bytes) from stream 10.0.0.239:88 [23557] 1428416098.706268: Terminating TCP connection to stream 10.0.0.239:88 [23557] 1428416098.706486: Response was not from master KDC [23557] 1428416098.706522: Processing preauth types: 19 [23557] 1428416098.706530: Selected etype info: etype aes256-cts, salt TEST.OSUWMCad-user, params [23557] 1428416098.706538: Produced preauth for next request: (empty) [23557] 1428416098.706546: AS key determined by preauth: aes256-cts/BA80 [23557] 1428416098.706600: Decrypted AS reply; session key is: aes256-cts/21BF [23557] 1428416098.706605: FAST negotiation: unavailable [23557] 1428416098.706629: Initializing KEYRING:persistent:2398410:krb_ccache_v8K2ML2 with default princ ad-user@TEST.OSUWMC [23557] 1428416098.706675: Removing ad-user@TEST.OSUWMC - krbtgt/TEST.OSUWMC@TEST.OSUWMC from KEYRING:persistent:2398410:krb_ccache_v8K2ML2 [23557] 1428416098.706683: Storing ad-user@TEST.OSUWMC - krbtgt/TEST.OSUWMC@TEST.OSUWMC in KEYRING:persistent:2398410:krb_ccache_v8K2ML2 [23557] 1428416098.706754: Storing config in KEYRING:persistent:2398410:krb_ccache_v8K2ML2 for krbtgt/TEST.OSUWMC@TEST.OSUWMC: pa_type: 2 [23557] 1428416098.706771: Removing ad-user@TEST.OSUWMC - krb5_ccache_conf_data/pa_type/krbtgt\/TEST.OSUWMC\@TEST.OSUWMC@X-CACHECONF: from
Re: [Freeipa-users] Creating arbitrary users?
On 04/07/2015 10:22 AM, Simo Sorce wrote: On Tue, 2015-04-07 at 14:16 +, coy.h...@coyhile.com wrote: Quoting Simo Sorce s...@redhat.com On Mon, 2015-04-06 at 21:16 -0400, Coy Hile wrote: In MIT land, one can potentially have multiple instances tied (by convention) to a given user (that is, that administratively one knows are the same set of eyeballs). For example, I might have my normal user (hile), and I might have another distinct MIT principal hile/admin used when I’m doing administrative work in the kerb database, or potentially yet another hile/vpn for remote access. Only the first of these is a ‘real’ user that needs to have a uid, gid, home directory, and shell; the others are just Kerberos principals that might have differing password policies applied to them. In FreeIPA, it appears all kerberos principals are tied to a user (or to a host in the case of host/ or another service definition). Is it possible to define a non-posix user? There is no good reason for hile/admin@MY.REALM to have a uidNumber or gidNumber; one should never login directly using that principal. Early on when we created FreeIPA we decided against providing alternative principals for the same user as it made things a lot more complex for little gain. To this day we still do not support them. Keep in mind that adding a principal is not the whole story, once you do that then you probably still want to associate it to some user, and assign privileges and allow alternative principal names to ssh into some machines, which means distributing k5login files or providing explicit support in the new aname2lname plugin. To do all this means adding new objects and configuration facilities to handle these special non-users, we haven't yet found enough benefit in adding support for these to warrant the work involved. Simo. -- Simo Sorce * Red Hat, Inc * New York I guess that makes sense. Is it possible to add a user that simply doesn't have the posix attributes defined? In the particular case of */admin, I would expect that user to login to the ipa ui or to be kinit'd to prior to running ipa administrative commands, but I should hope that it should never login directly. Does that question make more sense? It does, but we do not have such a feature, sorry. Simo. Would setting shell to NULL help? What do you want to prevent? SSH logins? You can have host based access control rules for that. May be a better explanation of why you need this user to not have posix would be beneficial. You can have posix users and still prevent them from logging where they should not be able to log in. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] upgrade 3.0 - 4.1
On 04/07/2015 03:04 PM, Natxo Asenjo wrote: hi, On Fri, Apr 3, 2015 at 4:41 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 04/03/2015 09:46 AM, Brian Topping wrote: On Apr 3, 2015, at 6:48 AM, Tamas Papptom...@martos.bme.hu mailto:tom...@martos.bme.hu wrote: hi All, I have CentOS 6.6 server and want to upgrade to 7.1. What is the upgrade path, can I do it directly or first I need to make it to 3.3? Also is there any known issue I should expect with workarounds? I just did this yesterday, so here's my experience. If you have a simple single-server installation with no custom LDAP DIT modifications, you should find yum upgrade does the right thing. If you do have DIT mods, you should ask yourself why they are there and whether the data will still be accessible after the ACLs are changed. In my case, I had Postfix using a LDAP hash and mail delivery stopped working (although the domain data was still there just fine). Note that the ACLs will propagate from the 4.1 server to your 3.0 if they are replicated. To be safe, back up all replicas (snapshot or whatnot) before the first upgrade and if you decide to restore any of them, be sure everything is shut down and restore all of them to avoid 4.x schema contaminating 3.0 as they come up. The general recommendation for 3.3 - 4.1 migration is to start introducing 4.1 replicas into your 3.3 environment and then turn your 3.3 replicas off. Do not forget to install the CA component with one of your 4.1 replicas before removing all the 3.3 instanced with CAs. With this procedure you would also need to move the CRL generation and cert tracking. See details in migration section https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#migrating-ipa-proc Will this excellent documentation work too on the migration from 3.0x (rhel 6) to 4.1.x (rhel 7.1)? I will be migrating the coming months to 7.1 or 7.2 (whichever is the current stable then), so just wondering. Yes, though it is recommended to get to the latest 6.x first before you start introducing 7.x replicas. Thanks! -- Groeten, natxo -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Creating arbitrary users?
On Apr 7, 2015, at 2:58 PM, Simo Sorce s...@redhat.com wrote: On Tue, 2015-04-07 at 18:54 +, Coy Hile wrote: Quoting Simo Sorce s...@redhat.com: I guess that makes sense. Is it possible to add a user that simply doesn't have the posix attributes defined? In the particular case of */admin, I would expect that user to login to the ipa ui or to be kinit'd to prior to running ipa administrative commands, but I should hope that it should never login directly. Does that question make more sense? It does, but we do not have such a feature, sorry. Simo. Could one hypothetically remove the posix attributes (via some scripted process that validates that what it's doing is inline with organizational norms/goals) without breaking freeIPA, or are the posix attributes MUST in the IPA object classes? I'm sorry for so many endless questions, but having finally got my personal setup/lab using something other than Active Directory, I'm looking to migrate to something that is easier to manage, so I'm trying to draw comparisons between what I had been used to in previous vanilla krb/ldap shops. Removing attributes will probably not work well, but let me ask: Do you require different passwords for these principals ? Or do you merely want to have the alternative names but would be ok if the credentials were identical ? Because you could (manually for now) add aliases so that hile@ hile/admin@ hile/foo@ are the same thing, where hile@ is the canonical name but you can use aliases too (just make sure not to request canonicalization at kinit time. My intent was that they have different passwords (and perhaps differing password policies.) For example, a /admin principal might enforce password expiry with a shorter lifespan than a normal principal, or might have a shorter maximum ticket lifetime before kinit -R is necessary. It’s merely convenient that these other instances not necessarily be posix accounts to enforce there’s no possible way that, for example, someone logs in and is running a full GNOME session as an admin. But I can live with them being posix accounts since it’s baked in. We’ve all heard the horror stories of the Microsoft shops where some genius decided to login to his workstation with his juser_domainadmin account, or worse Administrator…. -- Coy Hile coy.h...@coyhile.com -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Creating arbitrary users?
On Tue, 2015-04-07 at 22:01 -0400, Coy Hile wrote: On Apr 7, 2015, at 2:58 PM, Simo Sorce s...@redhat.com wrote: On Tue, 2015-04-07 at 18:54 +, Coy Hile wrote: Quoting Simo Sorce s...@redhat.com: I guess that makes sense. Is it possible to add a user that simply doesn't have the posix attributes defined? In the particular case of */admin, I would expect that user to login to the ipa ui or to be kinit'd to prior to running ipa administrative commands, but I should hope that it should never login directly. Does that question make more sense? It does, but we do not have such a feature, sorry. Simo. Could one hypothetically remove the posix attributes (via some scripted process that validates that what it's doing is inline with organizational norms/goals) without breaking freeIPA, or are the posix attributes MUST in the IPA object classes? I'm sorry for so many endless questions, but having finally got my personal setup/lab using something other than Active Directory, I'm looking to migrate to something that is easier to manage, so I'm trying to draw comparisons between what I had been used to in previous vanilla krb/ldap shops. Removing attributes will probably not work well, but let me ask: Do you require different passwords for these principals ? Or do you merely want to have the alternative names but would be ok if the credentials were identical ? Because you could (manually for now) add aliases so that hile@ hile/admin@ hile/foo@ are the same thing, where hile@ is the canonical name but you can use aliases too (just make sure not to request canonicalization at kinit time. My intent was that they have different passwords (and perhaps differing password policies.) For example, a /admin principal might enforce password expiry with a shorter lifespan than a normal principal, or might have a shorter maximum ticket lifetime before kinit -R is necessary. It’s merely convenient that these other instances not necessarily be posix accounts to enforce there’s no possible way that, for example, someone logs in and is running a full GNOME session as an admin. But I can live with them being posix accounts since it’s baked in. We’ve all heard the horror stories of the Microsoft shops where some genius decided to login to his workstation with his juser_domainadmin account, or worse Administrator…. You can use HBAC to prevent these users from logging in via gdm/ssh/login etc... Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica with external ca + custom subject in certificate
Dne 7.4.2015 v 15:31 Martin Kosek napsal(a): On 04/07/2015 02:08 PM, James James wrote: I will try to give a better explanation : I have a CentOS 6.6 with ipa 3.0 named ipa-master. ipa-master has been installed with an external CA about 3 years ago and I will have to renew the certificate soon. I have created a test server (ipa-dev) with the same configuration (centos 6.6 and ipa 3.0) to test the renewal process. I want the new ipa-dev sever to be installed with an external CA. In the same time my external CA has changed and wants the emailAddress field in the certificate request 's subject. CSR during installation with external CA is produced by Dogtag, so you are constrained with the options and capabilities provided by ipa-server-install. Maybe it would be possible to modify the CSR and update the Subject manually, but I expect it would crash the installer later (JanC may know more (CCed)) The subject name identifies the CA in server (and other) certificates. If you change it, you break the trust chain from the CA certificate to the server certificates and that will break all SSL in IPA. If it is not possible to add emailAddress in the subject, is it possible to migrate my ipa-master CA system from an external CA to a CA-less or self-signed CA ? It is, with ipa-cacert-manage - see links below. You can change your external CA to self-signed CA in IPA 4.1 or newer by running: # ipa-cacert-manage renew --self-signed You can't change external CA to CA-less. Thanks. 2015-04-07 13:48 GMT+02:00 Martin Kosek mko...@redhat.com: On 04/07/2015 01:44 PM, James James wrote: ok. Is there a way to migrate from an external CA to a CA-less or a self-signed CA ? Yes, you can use ipa-cacert-manage tool introduced in FreeIPA 4.1.0: https://www.freeipa.org/page/Howto/CA_Certificate_Renewal https://www.freeipa.org/page/V4/CA_certificate_renewal (Although I am still not sure about your use case and if this would help you) 2015-04-07 12:51 GMT+02:00 Martin Kosek mko...@redhat.com: On 04/03/2015 11:39 AM, James James wrote: Hello, I want to initialize a new replica with an external CA. My Certificate Authority wants a CSR with the field emailAddress in the subject like : /C=FR/O=TESTO/OU=TESTOU/CN=*.example.com/emailAddress=n...@none.com I am not a bit confused. Do you plan to have FreeIPA *without* a CA or with own CA signed by external CA? FreeIPA supports these kinds of setups right now: http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructure How can I do with the ipa-server-install command ? I have been trying for few days but I still can't. Thanks for your help. CCing Honza who should know the definitive answer. However, FreeIPA was not very flexible in configuring special subjects for it's CA certificate (i.e. cn=Certificate Authority, ou=...) or hosts in case of CA-less setup. -- Jan Cholasta -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
