Re: [Freeipa-users] RedHat IDM Replica runs ony dirsrv, kinit and getent fail after reboot
On 05/18/2015 02:17 PM, Sina Owolabi wrote: Hi Martin And thanks for getting back, greatly appreciated. I tore down the replica and reinstalled from scratch, using an old replica-info file I had on the primary. Im not sure if this is a good thing to do, but I would appreciate if you could point me to the logs you'd be interested in seeing. I had to reinstall the replica without CA before it would complete, too. Thanks again for your precious time. It depends what component you are actually fighting with. There is a separate log for LDAP server, KDC server, Apache and PKI servers. Most directions are specific here http://www.freeipa.org/page/Troubleshooting We need to know first what specific error you are dealing with right now, to point you to right direction. Martin On Mon, May 18, 2015 at 10:15 AM, Martin Kosek mko...@redhat.com wrote: On 05/16/2015 12:19 PM, Sina Owolabi wrote: Please help me. I am in dire straits, this is the linchpin of our network and we are suffering. I am sorry for delay in answering, but not many people here show up on the weekend. Comments below. On Sat, May 16, 2015 at 6:00 AM, Sina Owolabi notify.s...@gmail.com wrote: Hi! I am running an IPA domain with two servers, one is a replica. Red Hat 6.6, with the following versions: libipa_hbac-1.11.6-30.el6_6.4.x86_64 ipa-server-selinux-3.0.0-42.el6.x86_64 libipa_hbac-python-1.11.6-30.el6_6.4.x86_64 ipa-admintools-3.0.0-42.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-client-3.0.0-42.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch device-mapper-multipath-libs-0.4.9-80.el6_6.3.x86_64 device-mapper-multipath-0.4.9-80.el6_6.3.x86_64 ipa-server-3.0.0-42.el6.x86_64 ipa-python-3.0.0-42.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch sssd-ipa-1.11.6-30.el6_6.4.x86_64 I noticed the replica did not seem to be in sync with the primary IPA server, as login requests to ipa clients using the replica for domain authentication failed with Too many authentication failures for user UNKNOWN. I forced a sync with the primary server and rebooted the replica afterwards. Now the replica is back up, but when I run ipactl status, only dirsrv is running: # ipactl status Directory Service: RUNNING This is strange, try # ipactl restart see which services fail to start and see the logs they produce. No other service shows up. I also tried editing /etc/krb5.conf to change the [realms] information to point to the primary server, but while I can now kinit admin, nothing else works. Please how can I fix this problem? Please what can I do fix this? First things first. You need to first see if all service start and operate properly, if not, we need to see their logs in order to help or advise. 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] Securing IPA Redux
On May 18, 2015, at 9:55 PM, Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com wrote: Not necessarily. https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/SecureConnections.html#requiring-secure-connections https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/SecureConnections.html#requiring-secure-connections I think that covers what I need in combination with what Martin previously provided. Thanks guys! signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] LDAP uid to cn modify
Yes, I saw that discussion but there is no solution. So how to create compat tree? In my ldap there is somenting like uid=bartosz,cn=users,cn=compat,dc=example,dc=com - but it is still with uid. PS. I have fresh instalation CentOS 7.1 and IPA 4.1. 2015-05-18 16:03 GMT+02:00 Rob Crittenden rcrit...@redhat.com: Vangass wrote: Hi, I try to set FreeIPA as a LDAP server for HP iLO authentication. iLO client sends dn as cn=bartosz,cn=users,cn=accounts,dc=example,dc=com but in FreeIPA there is no cn=bartosz just uid=bartosz (as for any other user I create is uid). Is it possible to modify uid to cn or is there any other option? Thanks, Bartosz Witkowski Others have had the same issue, https://www.redhat.com/archives/freeipa-users/2014-January/msg00180.html If you are running EL 7+ you should be able to create a compat configuration to make it work but it isn't clear if anyone has done this work on IPA 3.3+ or not yet (IIRC the users in this thread were all still on RHEL 6). rob -- 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] interesting Kerberos issue
On Mon, 18 May 2015, Nathaniel McCallum wrote: On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote: On Mon, 18 May 2015, Janelle wrote: On 5/10/15 11:57 PM, Alexander Bokovoy wrote: On Sun, 10 May 2015, Janelle wrote: On 5/5/15 6:47 AM, Dmitri Pal wrote: On 05/04/2015 09:38 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account usera they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The servers are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do kinit admin it works just fine. But if I do kinit usera I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet admin works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH password and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? It helps -- thank you. Now allow me to add a little more fun, and there may not be a solution. From OS X (Yosemite) I am able to kinit --kdc-hostname=IPA -server principal and it works, gives me a ticket, and if I attempt to login to the web interface, since I already have my ticket - boom, works fine. Now, I enable 2FA and setup a token and change my account to OTP (with TOTP). But as previously discussed, can't seem to specify a -T option from OS X. I know this sounds tricky -- Any ideas? Use kinit --fast-armor-cache /path/to/ccache to specify already existing ccache to armor the FAST processing. This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least. You can check version number by running 'kinit --version'. Aha, so thee default on OS X Yosemite is $ kinit --version kinit (Heimdal 1.5.1apple1) so this won't work? Yes, you have to have the feature in your Kerberos library. Browsing the Heimdal source code, I don't even see any support for OTP at all. :( The support is since 1.6rc2, it uses the Richards' draft (draft-richards-otp-kerberos-01.txt) as a base and handles preauth but I don't think anything but login and ftpd supports passing the OTP token. -- / 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] interesting Kerberos issue
On Mon, 2015-05-18 at 09:45 -0500, Janelle wrote: Ok, let me ask this a different way, because maybe there is a way, and I am just not seeing it. I have 2 datacenters with typical bastions in each. I have enabled OTP and that works fine via ssh. But the user has to login to both and opening ssh tunnels is problematic at best. Using all the creativity in this list, maybe someone knows of another way to have a user authenticate from a Mac where they would only have to do it once to get their ticket? I guess I can't think of anything, but no harm in asking. Without support for the OTP pre-authentication mechanism, I don't know of any way to do this while still retaining the security properties of Kerberos. Basically, you'll have to hand over your password to a third party (which has OTP support). This is ill advised. Nathaniel -- 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] trusted user groups
On 05/18/2015 04:50 PM, Andy Thompson wrote: -Original Message- From: Lukas Slebodnik [mailto:lsleb...@redhat.com] Sent: Monday, May 18, 2015 10:33 AM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On (18/05/15 13:55), Andy Thompson wrote: -Original Message- From: Lukas Slebodnik [mailto:lsleb...@redhat.com] Sent: Thursday, May 14, 2015 4:41 PM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On (14/05/15 15:53), Andy Thompson wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Thursday, May 14, 2015 11:46 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On Thu, May 14, 2015 at 03:33:28PM +, Andy Thompson wrote: I've noticed that trusted users supplementary ad groups don't show up until after the users login to the box at least once. That's expected with the versions you're running. Prior to 6.7, we could only read the trusted users' group membership from the PAC blob attached to the Kerberos ticket. Is there a chance that information will be dropped again at any point going forward? No, otherwise it's a bug. The reason I ask is that on our sftp boxes we chroot users based on group membership. I set that up as an external group in freeIPA and the first time the user logs in to the sftp box, they are dropped in their normal home directory as opposed to the chroot environment. If there is a chance the group membership will not show up correctly again in the future, I'm inclined to change the chroot stanzas to match on user as opposed to group. Is that by design? If you can't see the correct group memberships after a login, then something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and there's so many fixes and enhancements in this area..is there a chance you could try out 6.7 beta or some custom packages? Group memberships show up fine after the first login so it is working as expected then. The accounts are very controlled so it shouldn't be a huge sticking point. I could try out some custom packages on this box but I can't move to 6.7 until we upgrade the entire environment. Here you are https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ To just bring this full circle, the latest sssd release reads group membership correctly without a Kerberos ticket. I tested this release on 6.6 and tested a 7.1 box and both worked without issue. I'm glad it works for you. I just can't roll them in production yet :/ I see. You have any insight into when 6.7 will be released? We cannot give any exact date at the moment, but given that 6.7 Beta is already out, the GA should be out summer-ish. You can try to use the Beta packages now or wait until it really hits GA. HTH, 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] 4.1.4 and OTP
On May 18, 2015, at 04:31, Martin Kosek mko...@redhat.com wrote: On 05/18/2015 01:49 AM, Janelle wrote: On 4/28/15 6:44 AM, Nathaniel McCallum wrote: On Fri, 2015-04-17 at 20:21 -0700, Janelle wrote: On 4/17/15 5:59 PM, Dmitri Pal wrote: On 04/17/2015 08:07 PM, Janelle wrote: On Apr 17, 2015, at 16:36, Dmitri Pal d...@redhat.com wrote: snip for shorter thread Simple. And my test made it simple. Stand up new vm running fc21/freeipa. Configure user. Add password. Add token. Login to the vm with the user created using password. Kerberos ticket assigned, all is well. Login to web interface with admin. Change user to OTP only. Go to web UI and click sync OTP. Enter username, password and 2 OTP sequences. Click sync. Error appears. Now, ssh to same vm using OTP username. Enter password + OTP value. Login successful. I can reproduce this issue with demo instance. I will file a bug later today. I think it is a bug with sync. Which token do you use time based or event based? TOTP... Hmm, makes me wonder - with HOTP fail the same? Off to try it. This should just affect TOTP. I have posted a patch that should fix this problem. Are you able to test it? https://www.redhat.com/archives/freeipa-devel/2015-April/msg00282.html Sorry - I just got around to testing this and it does resolve the problem - HOWEVER, you took away the ability to Name the tokens? They are now assigned unique IDs?? Was this intentional? It was, we track this (half-done) change in this ticket: https://fedorahosted.org/freeipa/ticket/4456 The main problem here is that user token names share the same name space and we thus do not want to create completely arbitrary names as they would collide. Applications like FreeOTP allow users to set own labels, so this is IMO the way how to add friendly names to the OTP tokens. Martin Makes sense, my only concern is syncing tokens. Once you add a second to,en and want to sync it you have to give it a token ID, otherwise it does not know which to sync. In the past if you named it, that was easy, but it does not seem to take description field as a token name. Guess I need to tell my users it is cut/paste time, or is there another option perhaps? Also, I was wondering, looking for a way to use both FreeOTP and yubikey and wondering if anyone has tried this and possible caveats? Janelle -- 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] 4.1.4 and OTP
On Mon, 2015-05-18 at 07:59 -0500, Janelle wrote: On May 18, 2015, at 04:31, Martin Kosek mko...@redhat.com wrote: On 05/18/2015 01:49 AM, Janelle wrote: On 4/28/15 6:44 AM, Nathaniel McCallum wrote: On Fri, 2015-04-17 at 20:21 -0700, Janelle wrote: On 4/17/15 5:59 PM, Dmitri Pal wrote: On 04/17/2015 08:07 PM, Janelle wrote: On Apr 17, 2015, at 16:36, Dmitri Pal d...@redhat.com wrote: snip for shorter thread Simple. And my test made it simple. Stand up new vm running fc21/freeipa. Configure user. Add password. Add token. Login to the vm with the user created using password. Kerberos ticket assigned, all is well. Login to web interface with admin. Change user to OTP only. Go to web UI and click sync OTP. Enter username, password and 2 OTP sequences. Click sync. Error appears. Now, ssh to same vm using OTP username. Enter password + OTP value. Login successful. I can reproduce this issue with demo instance. I will file a bug later today. I think it is a bug with sync. Which token do you use time based or event based? TOTP... Hmm, makes me wonder - with HOTP fail the same? Off to try it. This should just affect TOTP. I have posted a patch that should fix this problem. Are you able to test it? https://www.redhat.com/archives/freeipa-devel/2015 -April/msg00282.html Sorry - I just got around to testing this and it does resolve the problem - HOWEVER, you took away the ability to Name the tokens? They are now assigned unique IDs?? Was this intentional? It was, we track this (half-done) change in this ticket: https://fedorahosted.org/freeipa/ticket/4456 The main problem here is that user token names share the same name space and we thus do not want to create completely arbitrary names as they would collide. Applications like FreeOTP allow users to set own labels, so this is IMO the way how to add friendly names to the OTP tokens. Martin Makes sense, my only concern is syncing tokens. Once you add a second to,en and want to sync it you have to give it a token ID, otherwise it does not know which to sync. In the past if you named it, that was easy, but it does not seem to take description field as a token name. Guess I need to tell my users it is cut/paste time, or is there another option perhaps? You do not need to specify the token id when syncing. It is optional. If you leave it blank, FreeIPA will do the right thing. Also, I was wondering, looking for a way to use both FreeOTP and yubikey and wondering if anyone has tried this and possible caveats? There shouldn't be any caveats. Yubikey is just an HOTP token. Nathaniel -- 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] interesting Kerberos issue
On Mon, 2015-05-18 at 17:18 +0300, Alexander Bokovoy wrote: On Mon, 18 May 2015, Nathaniel McCallum wrote: On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote: On Mon, 18 May 2015, Janelle wrote: On 5/10/15 11:57 PM, Alexander Bokovoy wrote: On Sun, 10 May 2015, Janelle wrote: On 5/5/15 6:47 AM, Dmitri Pal wrote: On 05/04/2015 09:38 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account usera they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The servers are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do kinit admin it works just fine. But if I do kinit usera I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet admin works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH password and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? It helps -- thank you. Now allow me to add a little more fun, and there may not be a solution. From OS X (Yosemite) I am able to kinit --kdc -hostname=IPA -server principal and it works, gives me a ticket, and if I attempt to login to the web interface, since I already have my ticket - boom, works fine. Now, I enable 2FA and setup a token and change my account to OTP (with TOTP). But as previously discussed, can't seem to specify a -T option from OS X. I know this sounds tricky -- Any ideas? Use kinit --fast-armor-cache /path/to/ccache to specify already existing ccache to armor the FAST processing. This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least. You can check version number by running 'kinit --version'. Aha, so thee default on OS X Yosemite is $ kinit --version kinit (Heimdal 1.5.1apple1) so this won't work? Yes, you have to have the feature in your Kerberos library. Browsing the Heimdal source code, I don't even see any support for OTP at all. :( The support is since 1.6rc2, it uses the Richards' draft (draft-richards-otp-kerberos-01.txt) as a base and handles preauth but I don't think anything but login and ftpd supports passing the OTP token. Where is the code? I don't see any... Nathaniel -- 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] interesting Kerberos issue
On Mon, 18 May 2015, Nathaniel McCallum wrote: On Mon, 2015-05-18 at 17:18 +0300, Alexander Bokovoy wrote: On Mon, 18 May 2015, Nathaniel McCallum wrote: On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote: On Mon, 18 May 2015, Janelle wrote: On 5/10/15 11:57 PM, Alexander Bokovoy wrote: On Sun, 10 May 2015, Janelle wrote: On 5/5/15 6:47 AM, Dmitri Pal wrote: On 05/04/2015 09:38 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account usera they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The servers are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do kinit admin it works just fine. But if I do kinit usera I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet admin works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH password and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? It helps -- thank you. Now allow me to add a little more fun, and there may not be a solution. From OS X (Yosemite) I am able to kinit --kdc -hostname=IPA -server principal and it works, gives me a ticket, and if I attempt to login to the web interface, since I already have my ticket - boom, works fine. Now, I enable 2FA and setup a token and change my account to OTP (with TOTP). But as previously discussed, can't seem to specify a -T option from OS X. I know this sounds tricky -- Any ideas? Use kinit --fast-armor-cache /path/to/ccache to specify already existing ccache to armor the FAST processing. This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least. You can check version number by running 'kinit --version'. Aha, so thee default on OS X Yosemite is $ kinit --version kinit (Heimdal 1.5.1apple1) so this won't work? Yes, you have to have the feature in your Kerberos library. Browsing the Heimdal source code, I don't even see any support for OTP at all. :( The support is since 1.6rc2, it uses the Richards' draft (draft-richards-otp-kerberos-01.txt) as a base and handles preauth but I don't think anything but login and ftpd supports passing the OTP token. Where is the code? I don't see any... Yes, you made me realize this is pre-richards code in lib/otp/. Janelle: no support for Kerberos OTP on Mac OS X Yosemite or any other Heimdal environment to date. -- / 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] trusted user groups
On (18/05/15 13:55), Andy Thompson wrote: -Original Message- From: Lukas Slebodnik [mailto:lsleb...@redhat.com] Sent: Thursday, May 14, 2015 4:41 PM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On (14/05/15 15:53), Andy Thompson wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Thursday, May 14, 2015 11:46 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On Thu, May 14, 2015 at 03:33:28PM +, Andy Thompson wrote: I've noticed that trusted users supplementary ad groups don't show up until after the users login to the box at least once. That's expected with the versions you're running. Prior to 6.7, we could only read the trusted users' group membership from the PAC blob attached to the Kerberos ticket. Is there a chance that information will be dropped again at any point going forward? No, otherwise it's a bug. The reason I ask is that on our sftp boxes we chroot users based on group membership. I set that up as an external group in freeIPA and the first time the user logs in to the sftp box, they are dropped in their normal home directory as opposed to the chroot environment. If there is a chance the group membership will not show up correctly again in the future, I'm inclined to change the chroot stanzas to match on user as opposed to group. Is that by design? If you can't see the correct group memberships after a login, then something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and there's so many fixes and enhancements in this area..is there a chance you could try out 6.7 beta or some custom packages? Group memberships show up fine after the first login so it is working as expected then. The accounts are very controlled so it shouldn't be a huge sticking point. I could try out some custom packages on this box but I can't move to 6.7 until we upgrade the entire environment. Here you are https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ To just bring this full circle, the latest sssd release reads group membership correctly without a Kerberos ticket. I tested this release on 6.6 and tested a 7.1 box and both worked without issue. I'm glad it works for you. I just can't roll them in production yet :/ I see. LS -- 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 Update in progress : FALSE LDAP ERROR
On 05/16/2015 04:06 PM, Nathan Peters wrote: I have updated the bug report you filed below. The issue was that the instructions would only work in Windows Server 2003 because My Network Places was removed in 2008 and above. Since the manual clearly states that the AD sync is to be performed with server 2008 / 2012 only it made no sense to give instructions for an incompatible version of windows. I have added to the ticket 2 methods to get the *correct* certificate that will work in both server 2008 r2 and server 2012 r2. I am cc'd on the bug and have seen all of the information you added. Thanks! On 05/15/2015 03:09 PM, nat...@nathanpeters.com wrote: On 05/14/2015 11:33 PM, nat...@nathanpeters.com wrote: [root@ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net --bindpw supersecretpassword --passsync supersecretpassword --cacert /etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v Directory Manager password: Added CA certificate /etc/openldap/cacerts/addc2-test.cer to certificate database for ipadc1.ipadomain.net ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net Windows PassSync system account exists, not resetting password ipa: INFO: Added new sync agreement, waiting for it to become ready . . . ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP error: Connect error: start: 0: end: 0 ipa: INFO: Agreement is ready, starting replication . . . Starting replication, please wait until this has completed. [ipadc1.ipadomain.net] reports: Update failed! Status: [-11 - LDAP error: Connect error] Have you tried using ldapsearch to verify the connection? # LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ -h addc2.test.mycompany.net -D cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net -w supersecretpassword -s base -b cn=Users,dc=test,dc=mycompany,dc=net objectclass=* and/or # LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch -xLLL -ZZ -h addc2.test.mycompany.net -D cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net -w supersecretpassword -s base -b cn=Users,dc=test,dc=mycompany,dc=net objectclass=* Both commands give the same successful result. I don't think it's a problem with the credentials because I was able to generate different error messages during the attempted sync setup if I intentionally gave a bad password or username. Ok. Have you tried enabling the replication log level? http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting Ok, that helped a lot. I got this fixed now. Because the manual tells you to export the cert using a way that doesn't work on newer versions of windows, I tried to improvise and my first attempt exported the wrong cert. The correct way is to go to mmc.exe and add the certificates snap-in. Then go to personal certificates store for the machine account and export the one that has -CA at the end of it in the issued to column. Now that the correct certificate was exported, replication succeeded. The docs should be updated though to reflect the proper way to export. https://bugzilla.redhat.com/show_bug.cgi?id=1222161 Please add yourself to the bug and provide any additional information. -- 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] AD-trust and external DNS
You should add your IPA zone as a slave on your 'external' DNS servers so they are able to resolve the IPA zone. Josh From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Winfried de Heiden Sent: Monday, May 18, 2015 10:10 AM To: Freeipa-users Subject: [Freeipa-users] AD-trust and external DNS Hi all, Creating an AD-trust works nicely. However, for some customers both AD and IPA don't have have DNS for their own, the use external DNS (Infoblox for example) Now, is is possible to create an AD trust without a build-in (bind) IPA-DNS? Thankz! Winfried -- 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] Securing IPA Redux
Adding freeipa-users list back, to keep others in the loop. On 05/18/2015 12:32 PM, Brian Topping wrote: Thanks for taking the time to write that, Martin. It's good to have a reference to build from. Result of ida-client-install outside the firewall with port 636 accessible: Ah, I mostly just use 636 as a convenience port to show the supported cryptos, 389 is really the port we should be using by default. Of course, 389 port + STARTTLS environment turned on, to make sure passwords do not go in clean over the wire. Please make sure the following ports are opened in the firewall settings: TCP: 80, 88, 389 UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) No mention of 636, confirmed by tcpdump that it's not trying. Also no option on command line to specify 636. Opening up 389 means that some misconfigured client could expose passwords. It's possible to remove null ciphers, but then there's really no reason not to use 636. Seems like ipa-client-install should try 636 by default, then fall back to 389 in it's various forms, no? I think the general direction here was the opposite. To work on the port 389 as the common denominator, offering both password-less traffic and encrypted traffic. I am not sure if there were other reasons too, I would let Rob or Ludwig reply here if they know. Martin On May 18, 2015, at 4:10 PM, Martin Kosek mko...@redhat.com wrote: On 05/15/2015 01:33 PM, Brian Topping wrote: In the (apparently) first message to the list in 2014, https://www.redhat.com/archives/freeipa-users/2014-January/msg0.html https://www.redhat.com/archives/freeipa-users/2014-January/msg0.html addressed questions about securing IPA and I don't see much other talk about it. Now that 4.x is prevalent, I wanted to bring it up again. This is the default by design. However, note that in FreeIPA 4.0+ you can change that default (permission-mod) and let users or some of the user attributes be only shown for authenticated users. https://www.freeipa.org/page/V4/Permissions_V2 So, from my POV, this is not a flaw. I'd like my installation to be allow hardened machines (i.e. in the cloud with encrypted filesystems) to be a part of the domain. I believe this means that I need to expose Kerberos and LDAP to the world, since the machines could live anywhere. I don't believe I need to worry about KRB5, but I am concerned about 389-DS since it seems somewhat difficult to force TLS (https://blog.routedlogic.net/?p=119 https://blog.routedlogic.net/?p=119) and maybe that's a bad idea under IPA for reasons I thought I'd ask here about. Last year's thread also referenced https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html and I thought I would check to see if that's still necessary under 4.x. 389-DS and TLS should be also fixed, since FreeIPA 4.1 (RHEL/CentOS 7.1): https://fedorahosted.org/freeipa/ticket/4653 This is an nmap test against the FreeIPA public demo (4.1.x): $ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-18 11:08 CEST Nmap scan report for ipa.demo1.freeipa.org (209.132.178.99) Host is up (0.19s latency). PORTSTATE SERVICE 636/tcp open ldapssl | ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA256 - strong | TLS_RSA_WITH_RC4_128_MD5 - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL |_ least strength: strong Nmap done: 1 IP address (1 host up) scanned in 6.19 seconds Setting up the firewall to allow cloud networks in is always an option, but if I can get a secure IPA setup going, it would also allow road warriors to kinit and use their credentials for configured intranet sites without having to turn on the VPN (which can really slow things down from remote parts of the globe). BTW, if you are concerned about exposed Kerberos traffic, FreeIPA 4.2 plans to offer Kerberos-over-HTTP functionality by default: https://fedorahosted.org/freeipa/ticket/4801 Even now, it can be manually configured. This is what GNOME used: https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/ So, if I am reading my notes correctly, there should be no blockers in using FreeIPA in your environment. If yes, please let me know. Martin -- Manage your subscription for the Freeipa-users mailing list:
Re: [Freeipa-users] trusted user groups
-Original Message- From: Lukas Slebodnik [mailto:lsleb...@redhat.com] Sent: Monday, May 18, 2015 10:33 AM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On (18/05/15 13:55), Andy Thompson wrote: -Original Message- From: Lukas Slebodnik [mailto:lsleb...@redhat.com] Sent: Thursday, May 14, 2015 4:41 PM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On (14/05/15 15:53), Andy Thompson wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Thursday, May 14, 2015 11:46 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On Thu, May 14, 2015 at 03:33:28PM +, Andy Thompson wrote: I've noticed that trusted users supplementary ad groups don't show up until after the users login to the box at least once. That's expected with the versions you're running. Prior to 6.7, we could only read the trusted users' group membership from the PAC blob attached to the Kerberos ticket. Is there a chance that information will be dropped again at any point going forward? No, otherwise it's a bug. The reason I ask is that on our sftp boxes we chroot users based on group membership. I set that up as an external group in freeIPA and the first time the user logs in to the sftp box, they are dropped in their normal home directory as opposed to the chroot environment. If there is a chance the group membership will not show up correctly again in the future, I'm inclined to change the chroot stanzas to match on user as opposed to group. Is that by design? If you can't see the correct group memberships after a login, then something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and there's so many fixes and enhancements in this area..is there a chance you could try out 6.7 beta or some custom packages? Group memberships show up fine after the first login so it is working as expected then. The accounts are very controlled so it shouldn't be a huge sticking point. I could try out some custom packages on this box but I can't move to 6.7 until we upgrade the entire environment. Here you are https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ To just bring this full circle, the latest sssd release reads group membership correctly without a Kerberos ticket. I tested this release on 6.6 and tested a 7.1 box and both worked without issue. I'm glad it works for you. I just can't roll them in production yet :/ I see. You have any insight into when 6.7 will be released? -- 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] Securing IPA Redux
On 05/18/2015 08:26 AM, Martin Kosek wrote: Adding freeipa-users list back, to keep others in the loop. On 05/18/2015 12:32 PM, Brian Topping wrote: Thanks for taking the time to write that, Martin. It's good to have a reference to build from. Result of ida-client-install outside the firewall with port 636 accessible: Ah, I mostly just use 636 as a convenience port to show the supported cryptos, 389 is really the port we should be using by default. Of course, 389 port + STARTTLS environment turned on, to make sure passwords do not go in clean over the wire. Please make sure the following ports are opened in the firewall settings: TCP: 80, 88, 389 UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) No mention of 636, confirmed by tcpdump that it's not trying. Also no option on command line to specify 636. Opening up 389 means that some misconfigured client could expose passwords. Not necessarily. https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/SecureConnections.html#requiring-secure-connections It's possible to remove null ciphers, but then there's really no reason not to use 636. Seems like ipa-client-install should try 636 by default, then fall back to 389 in it's various forms, no? I think the general direction here was the opposite. To work on the port 389 as the common denominator, offering both password-less traffic and encrypted traffic. I am not sure if there were other reasons too, I would let Rob or Ludwig reply here if they know. Martin On May 18, 2015, at 4:10 PM, Martin Kosek mko...@redhat.com wrote: On 05/15/2015 01:33 PM, Brian Topping wrote: In the (apparently) first message to the list in 2014, https://www.redhat.com/archives/freeipa-users/2014-January/msg0.html https://www.redhat.com/archives/freeipa-users/2014-January/msg0.html addressed questions about securing IPA and I don't see much other talk about it. Now that 4.x is prevalent, I wanted to bring it up again. This is the default by design. However, note that in FreeIPA 4.0+ you can change that default (permission-mod) and let users or some of the user attributes be only shown for authenticated users. https://www.freeipa.org/page/V4/Permissions_V2 So, from my POV, this is not a flaw. I'd like my installation to be allow hardened machines (i.e. in the cloud with encrypted filesystems) to be a part of the domain. I believe this means that I need to expose Kerberos and LDAP to the world, since the machines could live anywhere. I don't believe I need to worry about KRB5, but I am concerned about 389-DS since it seems somewhat difficult to force TLS (https://blog.routedlogic.net/?p=119 https://blog.routedlogic.net/?p=119) and maybe that's a bad idea under IPA for reasons I thought I'd ask here about. Last year's thread also referenced https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html and I thought I would check to see if that's still necessary under 4.x. 389-DS and TLS should be also fixed, since FreeIPA 4.1 (RHEL/CentOS 7.1): https://fedorahosted.org/freeipa/ticket/4653 This is an nmap test against the FreeIPA public demo (4.1.x): $ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-18 11:08 CEST Nmap scan report for ipa.demo1.freeipa.org (209.132.178.99) Host is up (0.19s latency). PORTSTATE SERVICE 636/tcp open ldapssl | ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA256 - strong | TLS_RSA_WITH_RC4_128_MD5 - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL |_ least strength: strong Nmap done: 1 IP address (1 host up) scanned in 6.19 seconds Setting up the firewall to allow cloud networks in is always an option, but if I can get a secure IPA setup going, it would also allow road warriors to kinit and use their credentials for configured intranet sites without having to turn on the VPN (which can really slow things down from remote parts of the globe). BTW, if you are concerned about exposed Kerberos traffic, FreeIPA 4.2 plans to offer Kerberos-over-HTTP functionality by default: https://fedorahosted.org/freeipa/ticket/4801 Even now, it can be manually configured. This is what GNOME used: https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/ So, if I am reading my notes correctly, there should be no blockers in using
Re: [Freeipa-users] RedHat IDM Replica runs ony dirsrv, kinit and getent fail after reboot
Hi Martin And thanks for getting back, greatly appreciated. I tore down the replica and reinstalled from scratch, using an old replica-info file I had on the primary. Im not sure if this is a good thing to do, but I would appreciate if you could point me to the logs you'd be interested in seeing. I had to reinstall the replica without CA before it would complete, too. Thanks again for your precious time. On Mon, May 18, 2015 at 10:15 AM, Martin Kosek mko...@redhat.com wrote: On 05/16/2015 12:19 PM, Sina Owolabi wrote: Please help me. I am in dire straits, this is the linchpin of our network and we are suffering. I am sorry for delay in answering, but not many people here show up on the weekend. Comments below. On Sat, May 16, 2015 at 6:00 AM, Sina Owolabi notify.s...@gmail.com wrote: Hi! I am running an IPA domain with two servers, one is a replica. Red Hat 6.6, with the following versions: libipa_hbac-1.11.6-30.el6_6.4.x86_64 ipa-server-selinux-3.0.0-42.el6.x86_64 libipa_hbac-python-1.11.6-30.el6_6.4.x86_64 ipa-admintools-3.0.0-42.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-client-3.0.0-42.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch device-mapper-multipath-libs-0.4.9-80.el6_6.3.x86_64 device-mapper-multipath-0.4.9-80.el6_6.3.x86_64 ipa-server-3.0.0-42.el6.x86_64 ipa-python-3.0.0-42.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch sssd-ipa-1.11.6-30.el6_6.4.x86_64 I noticed the replica did not seem to be in sync with the primary IPA server, as login requests to ipa clients using the replica for domain authentication failed with Too many authentication failures for user UNKNOWN. I forced a sync with the primary server and rebooted the replica afterwards. Now the replica is back up, but when I run ipactl status, only dirsrv is running: # ipactl status Directory Service: RUNNING This is strange, try # ipactl restart see which services fail to start and see the logs they produce. No other service shows up. I also tried editing /etc/krb5.conf to change the [realms] information to point to the primary server, but while I can now kinit admin, nothing else works. Please how can I fix this problem? Please what can I do fix this? First things first. You need to first see if all service start and operate properly, if not, we need to see their logs in order to help or advise. 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] interesting Kerberos issue
On Mon, 18 May 2015, Janelle wrote: On 5/10/15 11:57 PM, Alexander Bokovoy wrote: On Sun, 10 May 2015, Janelle wrote: On 5/5/15 6:47 AM, Dmitri Pal wrote: On 05/04/2015 09:38 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account usera they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The servers are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do kinit admin it works just fine. But if I do kinit usera I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet admin works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH password and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? It helps -- thank you. Now allow me to add a little more fun, and there may not be a solution. From OS X (Yosemite) I am able to kinit --kdc-hostname=IPA-server principal and it works, gives me a ticket, and if I attempt to login to the web interface, since I already have my ticket - boom, works fine. Now, I enable 2FA and setup a token and change my account to OTP (with TOTP). But as previously discussed, can't seem to specify a -T option from OS X. I know this sounds tricky -- Any ideas? Use kinit --fast-armor-cache /path/to/ccache to specify already existing ccache to armor the FAST processing. This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least. You can check version number by running 'kinit --version'. Aha, so thee default on OS X Yosemite is $ kinit --version kinit (Heimdal 1.5.1apple1) so this won't work? Yes, you have to have the feature in your Kerberos library. -- / 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] LDAP uid to cn modify
Vangass wrote: Hi, I try to set FreeIPA as a LDAP server for HP iLO authentication. iLO client sends dn as cn=bartosz,cn=users,cn=accounts,dc=example,dc=com but in FreeIPA there is no cn=bartosz just uid=bartosz (as for any other user I create is uid). Is it possible to modify uid to cn or is there any other option? Thanks, Bartosz Witkowski Others have had the same issue, https://www.redhat.com/archives/freeipa-users/2014-January/msg00180.html If you are running EL 7+ you should be able to create a compat configuration to make it work but it isn't clear if anyone has done this work on IPA 3.3+ or not yet (IIRC the users in this thread were all still on RHEL 6). rob -- 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] LDAP uid to cn modify
Hi, I try to set FreeIPA as a LDAP server for HP iLO authentication. iLO client sends dn as cn=bartosz,cn=users,cn=accounts,dc=example,dc=com but in FreeIPA there is no cn=bartosz just uid=bartosz (as for any other user I create is uid). Is it possible to modify uid to cn or is there any other option? Thanks, Bartosz Witkowski -- 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] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Yes CA is running, and it's on the same machine. [root@dc ~]# ipa-replica-prepare dc01.ourdom.com --ip-address 192.168.2.40 Directory Manager (existing master) password: Preparing replica for dc01.ourdom.com from dc.ourdom.com Creating SSL certificate for the Directory Server Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) [root@dc ~]# ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING DNS Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING [root@dc ~]# On Mon, May 18, 2015, 10:19 AM Martin Kosek mko...@redhat.com wrote: On 05/16/2015 12:18 PM, Sina Owolabi wrote: Hi Group, I'm attempting again to rebuild and reinstall a troublesome replica. I have two freshly upgraded RHEL6.6 IdM servers. Problem is when I try to run createreplica I have this output: ipa-replica-prepare services01.ours.com --ip-address 192.168.2.40 Directory Manager (existing master) password: Preparing replica for services01.ours.com from services.ours.com Creating SSL certificate for the Directory Server Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) It looks like CA is not reachable. Is CA on the machine where you run ipa-replica-manage? Or other machine? Is the CA running? (ipactl status) I have check the different threads where I find this same error but all symlinks are correctly defined. Please can someone kindly guide a noob in the right path? -- 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] trusted user groups
-Original Message- From: Lukas Slebodnik [mailto:lsleb...@redhat.com] Sent: Thursday, May 14, 2015 4:41 PM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On (14/05/15 15:53), Andy Thompson wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Thursday, May 14, 2015 11:46 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] trusted user groups On Thu, May 14, 2015 at 03:33:28PM +, Andy Thompson wrote: I've noticed that trusted users supplementary ad groups don't show up until after the users login to the box at least once. That's expected with the versions you're running. Prior to 6.7, we could only read the trusted users' group membership from the PAC blob attached to the Kerberos ticket. Is there a chance that information will be dropped again at any point going forward? No, otherwise it's a bug. The reason I ask is that on our sftp boxes we chroot users based on group membership. I set that up as an external group in freeIPA and the first time the user logs in to the sftp box, they are dropped in their normal home directory as opposed to the chroot environment. If there is a chance the group membership will not show up correctly again in the future, I'm inclined to change the chroot stanzas to match on user as opposed to group. Is that by design? If you can't see the correct group memberships after a login, then something is fishy. However, we're rebasing to sssd 1.12.x in 6.7 and there's so many fixes and enhancements in this area..is there a chance you could try out 6.7 beta or some custom packages? Group memberships show up fine after the first login so it is working as expected then. The accounts are very controlled so it shouldn't be a huge sticking point. I could try out some custom packages on this box but I can't move to 6.7 until we upgrade the entire environment. Here you are https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ To just bring this full circle, the latest sssd release reads group membership correctly without a Kerberos ticket. I tested this release on 6.6 and tested a 7.1 box and both worked without issue. I just can't roll them in production yet :/ Thanks -andy -- 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] interesting Kerberos issue
On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote: On Mon, 18 May 2015, Janelle wrote: On 5/10/15 11:57 PM, Alexander Bokovoy wrote: On Sun, 10 May 2015, Janelle wrote: On 5/5/15 6:47 AM, Dmitri Pal wrote: On 05/04/2015 09:38 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account usera they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The servers are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do kinit admin it works just fine. But if I do kinit usera I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet admin works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH password and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? It helps -- thank you. Now allow me to add a little more fun, and there may not be a solution. From OS X (Yosemite) I am able to kinit --kdc-hostname=IPA -server principal and it works, gives me a ticket, and if I attempt to login to the web interface, since I already have my ticket - boom, works fine. Now, I enable 2FA and setup a token and change my account to OTP (with TOTP). But as previously discussed, can't seem to specify a -T option from OS X. I know this sounds tricky -- Any ideas? Use kinit --fast-armor-cache /path/to/ccache to specify already existing ccache to armor the FAST processing. This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least. You can check version number by running 'kinit --version'. Aha, so thee default on OS X Yosemite is $ kinit --version kinit (Heimdal 1.5.1apple1) so this won't work? Yes, you have to have the feature in your Kerberos library. Browsing the Heimdal source code, I don't even see any support for OTP at all. :( Nathaniel -- 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] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Sina Owolabi wrote: Yes CA is running, and it's on the same machine. [root@dc ~]# ipa-replica-prepare dc01.ourdom.com http://dc01.ourdom.com --ip-address 192.168.2.40 Directory Manager (existing master) password: Preparing replica for dc01.ourdom.com http://dc01.ourdom.com from dc.ourdom.com http://dc.ourdom.com Creating SSL certificate for the Directory Server Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) [root@dc ~]# ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING DNS Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING [root@dc ~]# This suggests that while the process is running the CA isn't actually operational. You'll need to poke through the logs in /var/log/pki* to see if there are any errors. I'd also see if the certificates are expired by running `getcert list` as root. rob -- 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 seems to begin but failed after 127 seconds ...
On 05/15/2015 05:11 PM, James James wrote: ok Rob. Thanks for your help. I will wait for the Scientific Linux 6.7 . Hi James, Unfortunately there is no workaround. This is a timing issue mostly seen when the master is more powerful than the consumer. If you are using VM you may try to get master/replica with nearly the same cpu/memory. thanks thierry Best. James 2015-05-15 16:58 GMT+02:00 Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com: On 05/15/2015 08:46 AM, James James wrote: [root@ipa ~]# rpm -q 389-ds-base 389-ds-base-1.2.11.15-50.el6_6.x86_64 Ok. Looks like this is planned to be fixed in RHEL 6.7 with version 389-ds-base-1.2.11.15-56.el6 I don't know if there are any workarounds. 2015-05-15 16:32 GMT+02:00 Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com: On 05/15/2015 08:22 AM, James James wrote: I think that : Starting replication, please wait until this has completed. Update in progress, 127 seconds elapsed Update in progress yet not in progress looks like a time error : https://fedorahosted.org/freeipa/ticket/4756 That issue should have been fixed in 389-ds-base-1.3.3 branch. What version of 389-ds-base? rpm -q 389-ds-base 2015-05-15 16:00 GMT+02:00 Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com: On 05/15/2015 07:55 AM, James James wrote: Is it possible to change the nsds5ReplicaTimeout value to get rid of this timeout error ? What timeout error? 2015-04-17 4:52 GMT+02:00 Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com: On 04/15/2015 10:44 PM, James James wrote: The ipareplica-install.log file in attachment ... Here are the pertinent bits: 2015-04-15T15:06:31Z DEBUG wait_for_open_ports: localhost [389] timeout 300 2015-04-15T15:06:32Z DEBUG flushing ldap://ipa.example.com:389 from SchemaCache 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache url=ldap://ipa.example.com:389 conn=ldap.ldapobject.SimpleLDAPObject instance at 0x484f4d0 2015-04-15T15:06:32Z DEBUG flushing ldaps://ipa1.example.com:636 from SchemaCache 2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache url=ldaps://ipa1.example.com:636 conn=ldap.ldapobject.SimpleLDAPObject instance at 0x4170290 2015-04-15T15:08:44Z 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/dsinstance.py, line 368, in __setup_replica r_bindpw=self.dm_password) File /usr/lib/python2.7/site-packages/ipaserver/install/replication.py, line 969, in setup_replication raise RuntimeError(Failed to start replication) RuntimeError: Failed to start replication 2015-04-15T15:08:44Z DEBUG [error] RuntimeError: Failed to start replication The times are a little off, but I believe this corresponds to [15/Apr/2015:17:08:39 +0200] - import userRoot: Import complete. Processed 1539 entries in 126 seconds. (12.21 entries/sec) [15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr is coming online; enabling replication I don't know why setup_replication is reporting an error if replication completed successfully. 2015-04-16 2:22 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com: Rich Megginson wrote: On 04/15/2015 02:58 PM, James James wrote: Nothing on the replica .. maybye a process on the master. How can I check that ? I have no idea. But it seems highly unlikely that a process on the master is able to shutdown a process on the replica . . . I
Re: [Freeipa-users] interesting Kerberos issue
On 5/10/15 11:57 PM, Alexander Bokovoy wrote: On Sun, 10 May 2015, Janelle wrote: On 5/5/15 6:47 AM, Dmitri Pal wrote: On 05/04/2015 09:38 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account usera they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The servers are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do kinit admin it works just fine. But if I do kinit usera I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet admin works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH password and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? It helps -- thank you. Now allow me to add a little more fun, and there may not be a solution. From OS X (Yosemite) I am able to kinit --kdc-hostname=IPA-server principal and it works, gives me a ticket, and if I attempt to login to the web interface, since I already have my ticket - boom, works fine. Now, I enable 2FA and setup a token and change my account to OTP (with TOTP). But as previously discussed, can't seem to specify a -T option from OS X. I know this sounds tricky -- Any ideas? Use kinit --fast-armor-cache /path/to/ccache to specify already existing ccache to armor the FAST processing. This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least. You can check version number by running 'kinit --version'. Aha, so thee default on OS X Yosemite is $ kinit --version kinit (Heimdal 1.5.1apple1) so this won't work? ~J PS - sorry for the questions, still trying to wrap my head around how to get OTP working from a term session so you can get your ticket and then login to all the hosts you need without reauthenticating. -- 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] host usercertificate attribute
Natxo Asenjo wrote: On Sat, May 16, 2015 at 10:24 PM, Natxo Asenjo natxo.ase...@gmail.com mailto:natxo.ase...@gmail.com wrote: hi, If I retrieve the usercertificate attribute for host objects I get some gibberish. How can I decode the info I get from ldapsearch? maybe there is a way to feed that to openssl. What I ended up doing was using Perl and Crypt::X509 and I can see all the certificate elements. They are DER-encoded files. Something like this will show the contents: $ openssl x509 -text -in /tmp/file rob -- 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] AD-trust and external DNS
Hi all, Creating an AD-trust works nicely. However, for some customers both AD and IPA don't have have DNS "for their own", the use external DNS (Infoblox for example) Now, is is possible to create an AD trust without a build-in (bind) IPA-DNS? Thankz! Winfried -- 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] username case sensitivity
On Sun, May 17, 2015 at 10:26:45PM +, Andy Thompson wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Sunday, May 17, 2015 5:23 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] username case sensitivity On Fri, May 15, 2015 at 09:44:31PM +0200, Lukas Slebodnik wrote: On (15/05/15 17:27), Andy Thompson wrote: Is there a way to enforce case sensitivity for trusted AD users? I am trying to use username for ssh chroots and I can authenticated with any case combination of UsERname but if ssh is set to match on username then the chroot is not enforced and the user is dropped to their usual home directory. I found a case_sensitive option for sssd but it does not seem to have any affect. Running RHEL6.6 clients. IPA domain is by default case sensitive. So You will not change anything if you put case_sensitive = true into domain section of sssd.conf. But SSSD will create subdomains for each AD domain. It is different id_provider therefore different default values are used for subdomains and for AD provider it is case *insensitive* by default. Currently there's no way how to change it for subdomains (AD trusted domains) What are you using for the SSH matching? The way the case insensitiveness is implemented in SSSD is that all usernames are forcibly lowercased on output, so as long as SSH uses the standard NSS calls, you should be good with using the lowecase usernames.. They were initially all in lower case and working when I tested and finalized the setup. I passed the credentials off and they used mixed case and the match stopped working. What is they ? I guess not SSSD but grabbing the data directly from LDAP? -- 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] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Sina Owolabi wrote: Hi Rob There are some logs in /var/log/pki-ca/catalina.out that appear to indicate a problem: [SNIP] These are mostly white noise from tomcat and can be ignored. Also running getcert list tells me there are two expired certs: Request ID '20130524104636': status: CA_UNREACHABLE ca-error: Server at https://dc.ourdom.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://dc.ourdom.com:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). stuck: no Request ID '20130524104828': status: CA_UNREACHABLE ca-error: Server at https://dc.ourdom.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://dc.ourdom.com:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). stuck: no I'd be grateful to know what to do. Your CA subsystem certificates are expired so while the process is up the CA won't serve requests. See http://www.freeipa.org/page/Howto/CA_Certificate_Renewal rob -- 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] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Hi Rob There are some logs in /var/log/pki-ca/catalina.out that appear to indicate a problem: CMS Warning: FAILURE: Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate|FAILURE: authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value| Server is started. SEVERE: A web application appears to have started a thread named [Timer-0] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/signedAudit/ca_audit.flush-3] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/signedAudit/ca_audit.rollover-4] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/system.flush-5] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/system.rollover-6] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/transactions.flush-7] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/transactions.rollover-8] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/selftests.log.flush-9] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [/var/lib/pki-ca/logs/selftests.log.rollover-10] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [LDAPConnThread-2 ldap://dc.ourdom.com:7389] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [LDAPConnThread-3 ldap://dc.ourdom.com:7389] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [LDAPConnThread-4 ldap://dc.ourdom.com:7389] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [LDAPConnThread-5 ldap://dc.ourdom.com:7389] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [LDAPConnThread-6 ldap://dc.ourdom.com:7389] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: A web application appears to have started a thread named [LDAPConnThread-8 ldap://dc.ourdom.com:7389] but has failed to stop it. This is very likely to create a memory leak. May 24, 2013 11:47:35 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads May 24, 2013 11:48:10 AM org.apache.catalina.core.AprLifecycleListener init INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib SEVERE: A web application created a
Re: [Freeipa-users] interesting Kerberos issue
On May 18, 2015, at 09:47, Nathaniel McCallum npmccal...@redhat.com wrote: On Mon, 2015-05-18 at 09:45 -0500, Janelle wrote: Ok, let me ask this a different way, because maybe there is a way, and I am just not seeing it. I have 2 datacenters with typical bastions in each. I have enabled OTP and that works fine via ssh. But the user has to login to both and opening ssh tunnels is problematic at best. Using all the creativity in this list, maybe someone knows of another way to have a user authenticate from a Mac where they would only have to do it once to get their ticket? I guess I can't think of anything, but no harm in asking. Without support for the OTP pre-authentication mechanism, I don't know of any way to do this while still retaining the security properties of Kerberos. Basically, you'll have to hand over your password to a third party (which has OTP support). This is ill advised. Nathaniel Excellent point. Thanks for all the tips and advice. And of course for a great product that continues to get better. ~J -- 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] Apache htaccess replacement
Hello I have been attempting to use my 4.1.4 FreeIPA server to authenticate folders on a web server as a replacement for the normal htaccess feature. I do require group authentication. I have tried just about online example and have only been able to get basic ldap and basic kerbos authentication. How do I go about getting group based authentication working. I have tried to add the following to either example below and no luck. I added the httpbind user from an ldif file from examples. I created a user group named htaccess and added the users to it. AuthLDAPBindDN uid=httpbind,cn=sysaccounts,cn=etc,dc=test,dc=com AuthLDAPBindPassword XX AuthLDAPGroupAttributeIsDN off AuthLDAPUrl ldap://ipa.test.com/dc=test,dc=com?uid Require ldap-group cn=htaccess,cn=groups,cn=compat,dc=test,dc=com My error logs look like [Mon May 18 14:31:19 2015] [debug] src/mod_auth_kerb.c(1944): [client xxx.xxx.xxx.xxx] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Mon May 18 14:31:19 2015] [debug] src/mod_auth_kerb.c(1032): [client xxx.xxx.xxx.xxx] Using HTTP/server1.test@test.com as server principal for password verification [Mon May 18 14:31:19 2015] [debug] src/mod_auth_kerb.c(736): [client xxx.xxx.xxx.xxx] Trying to get TGT for user js...@test.com [Mon May 18 14:31:19 2015] [debug] src/mod_auth_kerb.c(646): [client xxx.xxx.xxx.xxx] Trying to verify authenticity of KDC using principal HTTP/server1.test@test.com [Mon May 18 14:31:19 2015] [debug] src/mod_auth_kerb.c(): [client xxx.xxx.xxx.xxx] kerb_authenticate_user_krb5pwd ret=0 user=js...@test.com authtype=Basic [Mon May 18 14:31:19 2015] [debug] mod_authnz_ldap.c(727): [client xxx.xxx.xxx.xxx] ldap authorize: Creating LDAP req structure [Mon May 18 14:31:19 2015] [debug] mod_authnz_ldap.c(739): [client xxx.xxx.xxx.xxx] auth_ldap authorise: User DN not found, LDAP: ldap_simple_bind_s() failed I have this working. Location /private SSLRequireSSL AuthName LDAP Authentication AuthType Basic AuthzLDAPMethod ldap AuthzLDAPServer ipa.test.com AuthzLDAPUserBase cn=users,cn=compat,dc=test,dc=com AuthzLDAPUserKey uid AuthzLDAPUserScope base require valid-user /Location And this is working Location /private SSLRequireSSL AuthName KERBEROS Authentication AuthType Kerberos KrbServiceName HTTP KrbMethodK5Passwd On KrbSaveCredentials On KrbMethodNegotiate On KrbAuthRealms TEST.COM Krb5KeyTab /etc/httpd/conf.d/keytab AuthLDAPUrl ldap://ipa.test.com/dc=test,dc=com?krbPrincipalName Require valid-user /Location -- = Matthew Feinberg -- 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] interesting Kerberos issue
On 5/18/15 7:47 AM, Nathaniel McCallum wrote: On Mon, 2015-05-18 at 09:45 -0500, Janelle wrote: Ok, let me ask this a different way, because maybe there is a way, and I am just not seeing it. I have 2 datacenters with typical bastions in each. I have enabled OTP and that works fine via ssh. But the user has to login to both and opening ssh tunnels is problematic at best. Using all the creativity in this list, maybe someone knows of another way to have a user authenticate from a Mac where they would only have to do it once to get their ticket? I guess I can't think of anything, but no harm in asking. Without support for the OTP pre-authentication mechanism, I don't know of any way to do this while still retaining the security properties of Kerberos. Basically, you'll have to hand over your password to a third party (which has OTP support). This is ill advised. Nathaniel Going to see about installing MIT version from source on Yosemite and see what happens.. Current is 1.13.2 Will let you know ~J -- 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 again :-(
Once again, replication/sync has been lost. I really wish the product was more stable, it is so much potential and yet. Servers running for 6 days no issues. No new accounts or changes (maybe a few users changing passwords) and again, 5 out of 16 servers are no longer in sync. I can test it easily by adding an account and then waiting a few minutes, then run ipa user-show --all username on all the servers, and only a few of them have the account. I have now waited 15 minutes, still no luck. Oh well.. I guess I will go look at alternatives. I had such high hopes for this tool. Thanks so much everyone for all your help in trying to get things stable, but for whatever reason, there is a random loss of sync among the servers and obviously this is not acceptable. regards ~J -- 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 again :-(
On 5/18/15 6:23 PM, Janelle wrote: Once again, replication/sync has been lost. I really wish the product was more stable, it is so much potential and yet. Servers running for 6 days no issues. No new accounts or changes (maybe a few users changing passwords) and again, 5 out of 16 servers are no longer in sync. I can test it easily by adding an account and then waiting a few minutes, then run ipa user-show --all username on all the servers, and only a few of them have the account. I have now waited 15 minutes, still no luck. Oh well.. I guess I will go look at alternatives. I had such high hopes for this tool. Thanks so much everyone for all your help in trying to get things stable, but for whatever reason, there is a random loss of sync among the servers and obviously this is not acceptable. regards ~J A new error: [ipa03.example.com] reports: Update failed! Status: [49 - LDAP error: Invalid credentials] -- 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] Reinstall ipa client, problem with old CA
Hello! I'm trying to reinstall ipa client, but have a problem with old/existing ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA server still on development and always reinstalled, I need to reproduce any possible problem/error on FreeIPA 4.x on CentOS 7. The error was : LDAP Error: Connect error: TLS error -8054:You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. Currently, I was renamed ca.crt to ca.crt.old and the ipa client successfully reconnected to new FreeIPA Server using dns discovery. Is it normal? And why the ipa-client-install --uninstall didn't completely remove the old ca.crt? Thank you. -- 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 again :-(
On 05/19/2015 03:23 AM, Janelle wrote: Once again, replication/sync has been lost. I really wish the product was more stable, it is so much potential and yet. Servers running for 6 days no issues. No new accounts or changes (maybe a few users changing passwords) and again, 5 out of 16 servers are no longer in sync. I can test it easily by adding an account and then waiting a few minutes, then run ipa user-show --all username on all the servers, and only a few of them have the account. I have now waited 15 minutes, still no luck. Oh well.. I guess I will go look at alternatives. I had such high hopes for this tool. Thanks so much everyone for all your help in trying to get things stable, but for whatever reason, there is a random loss of sync among the servers and obviously this is not acceptable. Hello Janelle, I am very sorry to hear about your troubles. Would you be still OK with helping us (mostly Ludwig and Thierry) investigate what is the root cause of the instability of the replication agreements? This is obviously something that should not be happening at this rate as in your deployment, so I would really like to be able to identity and fix this issue in the 389 DS. -- 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] Reinstall ipa client, problem with old CA
On 05/19/2015 04:04 AM, Dewangga Bachrul Alam wrote: Hello! I'm trying to reinstall ipa client, but have a problem with old/existing ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA server still on development and always reinstalled, I need to reproduce any possible problem/error on FreeIPA 4.x on CentOS 7. The error was : LDAP Error: Connect error: TLS error -8054:You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. Currently, I was renamed ca.crt to ca.crt.old and the ipa client successfully reconnected to new FreeIPA Server using dns discovery. Is it normal? And why the ipa-client-install --uninstall didn't completely remove the old ca.crt? Hello, ipa-client-install uninstall the CA certificate properly since FreeIPA 3.2. This is the upstream ticket: https://fedorahosted.org/freeipa/ticket/3537 CentOS/RHEL speaking, this should be thus fixed in 7.0+. In 6.x versions, you need to delete the certificate manually if you reinstalled the IPA server. HTH, 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] RedHat IDM Replica runs ony dirsrv, kinit and getent fail after reboot
On 05/16/2015 12:19 PM, Sina Owolabi wrote: Please help me. I am in dire straits, this is the linchpin of our network and we are suffering. I am sorry for delay in answering, but not many people here show up on the weekend. Comments below. On Sat, May 16, 2015 at 6:00 AM, Sina Owolabi notify.s...@gmail.com wrote: Hi! I am running an IPA domain with two servers, one is a replica. Red Hat 6.6, with the following versions: libipa_hbac-1.11.6-30.el6_6.4.x86_64 ipa-server-selinux-3.0.0-42.el6.x86_64 libipa_hbac-python-1.11.6-30.el6_6.4.x86_64 ipa-admintools-3.0.0-42.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-client-3.0.0-42.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch device-mapper-multipath-libs-0.4.9-80.el6_6.3.x86_64 device-mapper-multipath-0.4.9-80.el6_6.3.x86_64 ipa-server-3.0.0-42.el6.x86_64 ipa-python-3.0.0-42.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch sssd-ipa-1.11.6-30.el6_6.4.x86_64 I noticed the replica did not seem to be in sync with the primary IPA server, as login requests to ipa clients using the replica for domain authentication failed with Too many authentication failures for user UNKNOWN. I forced a sync with the primary server and rebooted the replica afterwards. Now the replica is back up, but when I run ipactl status, only dirsrv is running: # ipactl status Directory Service: RUNNING This is strange, try # ipactl restart see which services fail to start and see the logs they produce. No other service shows up. I also tried editing /etc/krb5.conf to change the [realms] information to point to the primary server, but while I can now kinit admin, nothing else works. Please how can I fix this problem? Please what can I do fix this? First things first. You need to first see if all service start and operate properly, if not, we need to see their logs in order to help or advise. 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] Securing IPA Redux
On 05/15/2015 01:33 PM, Brian Topping wrote: In the (apparently) first message to the list in 2014, https://www.redhat.com/archives/freeipa-users/2014-January/msg0.html https://www.redhat.com/archives/freeipa-users/2014-January/msg0.html addressed questions about securing IPA and I don't see much other talk about it. Now that 4.x is prevalent, I wanted to bring it up again. This is the default by design. However, note that in FreeIPA 4.0+ you can change that default (permission-mod) and let users or some of the user attributes be only shown for authenticated users. https://www.freeipa.org/page/V4/Permissions_V2 So, from my POV, this is not a flaw. I'd like my installation to be allow hardened machines (i.e. in the cloud with encrypted filesystems) to be a part of the domain. I believe this means that I need to expose Kerberos and LDAP to the world, since the machines could live anywhere. I don't believe I need to worry about KRB5, but I am concerned about 389-DS since it seems somewhat difficult to force TLS (https://blog.routedlogic.net/?p=119 https://blog.routedlogic.net/?p=119) and maybe that's a bad idea under IPA for reasons I thought I'd ask here about. Last year's thread also referenced https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html and I thought I would check to see if that's still necessary under 4.x. 389-DS and TLS should be also fixed, since FreeIPA 4.1 (RHEL/CentOS 7.1): https://fedorahosted.org/freeipa/ticket/4653 This is an nmap test against the FreeIPA public demo (4.1.x): $ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-18 11:08 CEST Nmap scan report for ipa.demo1.freeipa.org (209.132.178.99) Host is up (0.19s latency). PORTSTATE SERVICE 636/tcp open ldapssl | ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA256 - strong | TLS_RSA_WITH_RC4_128_MD5 - strong | TLS_RSA_WITH_RC4_128_SHA - strong | compressors: | NULL |_ least strength: strong Nmap done: 1 IP address (1 host up) scanned in 6.19 seconds Setting up the firewall to allow cloud networks in is always an option, but if I can get a secure IPA setup going, it would also allow road warriors to kinit and use their credentials for configured intranet sites without having to turn on the VPN (which can really slow things down from remote parts of the globe). BTW, if you are concerned about exposed Kerberos traffic, FreeIPA 4.2 plans to offer Kerberos-over-HTTP functionality by default: https://fedorahosted.org/freeipa/ticket/4801 Even now, it can be manually configured. This is what GNOME used: https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/ So, if I am reading my notes correctly, there should be no blockers in using FreeIPA in your environment. If yes, please let me know. 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] 4.1.4 and OTP
On 05/18/2015 01:49 AM, Janelle wrote: On 4/28/15 6:44 AM, Nathaniel McCallum wrote: On Fri, 2015-04-17 at 20:21 -0700, Janelle wrote: On 4/17/15 5:59 PM, Dmitri Pal wrote: On 04/17/2015 08:07 PM, Janelle wrote: On Apr 17, 2015, at 16:36, Dmitri Pal d...@redhat.com wrote: snip for shorter thread Simple. And my test made it simple. Stand up new vm running fc21/freeipa. Configure user. Add password. Add token. Login to the vm with the user created using password. Kerberos ticket assigned, all is well. Login to web interface with admin. Change user to OTP only. Go to web UI and click sync OTP. Enter username, password and 2 OTP sequences. Click sync. Error appears. Now, ssh to same vm using OTP username. Enter password + OTP value. Login successful. I can reproduce this issue with demo instance. I will file a bug later today. I think it is a bug with sync. Which token do you use time based or event based? TOTP... Hmm, makes me wonder - with HOTP fail the same? Off to try it. This should just affect TOTP. I have posted a patch that should fix this problem. Are you able to test it? https://www.redhat.com/archives/freeipa-devel/2015-April/msg00282.html Sorry - I just got around to testing this and it does resolve the problem - HOWEVER, you took away the ability to Name the tokens? They are now assigned unique IDs?? Was this intentional? It was, we track this (half-done) change in this ticket: https://fedorahosted.org/freeipa/ticket/4456 The main problem here is that user token names share the same name space and we thus do not want to create completely arbitrary names as they would collide. Applications like FreeOTP allow users to set own labels, so this is IMO the way how to add friendly names to the OTP tokens. 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] username case sensitivity
-Original Message- From: Jakub Hrozek [mailto:jhro...@redhat.com] Sent: Monday, May 18, 2015 4:07 AM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] username case sensitivity On Sun, May 17, 2015 at 10:26:45PM +, Andy Thompson wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Sunday, May 17, 2015 5:23 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] username case sensitivity On Fri, May 15, 2015 at 09:44:31PM +0200, Lukas Slebodnik wrote: On (15/05/15 17:27), Andy Thompson wrote: Is there a way to enforce case sensitivity for trusted AD users? I am trying to use username for ssh chroots and I can authenticated with any case combination of UsERname but if ssh is set to match on username then the chroot is not enforced and the user is dropped to their usual home directory. I found a case_sensitive option for sssd but it does not seem to have any affect. Running RHEL6.6 clients. IPA domain is by default case sensitive. So You will not change anything if you put case_sensitive = true into domain section of sssd.conf. But SSSD will create subdomains for each AD domain. It is different id_provider therefore different default values are used for subdomains and for AD provider it is case *insensitive* by default. Currently there's no way how to change it for subdomains (AD trusted domains) What are you using for the SSH matching? The way the case insensitiveness is implemented in SSSD is that all usernames are forcibly lowercased on output, so as long as SSH uses the standard NSS calls, you should be good with using the lowecase usernames.. They were initially all in lower case and working when I tested and finalized the setup. I passed the credentials off and they used mixed case and the match stopped working. What is they ? I guess not SSSD but grabbing the data directly from LDAP? The match clauses in the sshd config were set to use lower case names. It is using sssd, just a regular ipa client installation. If I logged in using USERName insetad of username, the match clause did not work. -andy -- 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
