From jstormshak at cccis.com Tue Dec 1 10:45:02 2015 From: jstormshak at cccis.com (Jeffrey Stormshak) Date: Tue, 1 Dec 2015 10:45:02 +0000 Subject: [Freeipa-users] Oracle Linux 5.5 - Legacy Question In-Reply-To: References: <564F778B.5050106@redhat.com> <20151123075846.GA12432@hendrix> <5653CC54.5070609@redhat.com> <20151124082507.GU12432@hendrix> <20151124135748.GM9605@redhat.com> Message-ID: Looks like I needed to try a couple of options for the /etc/ldap.conf file. Eventually, the original line of 'pam_password md5? seemed to be causing the error message. I commented it out and I?ll assume by doing so, that its using ?clear text? for the LDAP call. I?m using SSL/TLS so I?ll try a few other options to the ?pam_password?. If this is the only way to get it to work, then I?ll take what I can here ? What options for legacy clients does the members of this group use or recommend? I also want to thank everyone here for all of the help getting my legacy clients functioning to date !! Jeffrey Stormshak, RHCSA | Sr. Linux Engineer Platform Systems | IT Operations Infrastructure CCC Information Services, Inc. Phone: (312) 229-2552 From: Jeffrey Stormshak > Date: Monday, November 30, 2015 at 12:34 PM To: Jeffrey Stormshak >, Alexander Bokovoy > Cc: "freeipa-users at redhat.com" > Subject: RE: [Freeipa-users] Oracle Linux 5.5 - Legacy Question Alex/Group --- I?ve implemented the ipa-advise script and authentication worked as expected on the legacy 5.5 client. Although, I continue to get closer, another bump in the road here. Anyone experienced this error and could provide some areas to review to correct it? Please advise ? Thanks for the continual help here !! $ passwd Changing password for user pmoss. Enter login(LDAP) password: New UNIX password: Retype new UNIX password: LDAP password information update failed: Constraint violation Pre-Encoded passwords are not valid passwd: Permission denied From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jeffrey Stormshak Sent: Tuesday, November 24, 2015 4:40 PM To: Alexander Bokovoy Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question Alex - Thank you for the details!! For right now, I?m using the IPA Server as a standalone Linux domain controller/server without any AD integration. This allows testing to prove that this could work with a large number of 5.5 clients in the enterprise to date. On the question being proposed ? You haven't answered earlier when people asked whether you are using cn=compat tree because you need to get information about Active Directory users or not. ANSWER: Yes. I?m trying to achieve full integration with AD but I?m only at the point where I started testing this in a standalone Linux mode. I was trying to see if these legacy 5.5 clients were even possible to configure and to work here as specified. I?ll review the IPA tools for better understanding here. Jeffrey Stormshak, RHCSA | Sr. Linux Engineer Platform Systems | IT Operations Infrastructure CCC Information Services, Inc. Phone: (312) 229-2552 From: Alexander Bokovoy > Date: Tuesday, November 24, 2015 at 7:57 AM To: Jeffrey Stormshak > Cc: Jakub Hrozek >, Rob Crittenden >, "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question On Tue, 24 Nov 2015, Jeffrey Stormshak wrote: I went to review the ?ip_provider? and that looks like a ?sssd.conf? setting. The sssd RPM isn?t located on the 5.5 clients; nor is it in the YUM Channels for 5.5 base and 5.5 patch. So is the recommendation here to find any 5.X version of sssd RPM and use that for this configuration? Sorry, being a newbie on this product realistically isn?t helping here I?m sure ? The ipa-advise, is that part of the ipa-client RPM? That too, doesn?t exist on the 5.5 distribution as well. Even the version required to fix the openssl only worked with the 5.7 base version. Am I complete doomed for 5.5? Cards are stacked for sure. Nonetheless ? ipa-advise is a tool on IPA server that provides recipes how to configure different clients for a typical scenarios involving trust to AD. Read the manual for the tool to get more information. For legacy clients where there is no recent enough SSSD to support trust to AD natively, ipa-advise recommends using schema compatibility plugin to expose both IPA and AD users under same LDAP tree. This is what you see in cn=users,cn=compat,dc=example,dc=com. If you see cn=compat in the LDAP base DN, you know you are looking into the compatibility tree. Compatibility tree is handled by a special plugin which combines data from the primary IPA tree (cn=accounts,dc=example,dc=com) and from SSSD on IPA server. It also exposes ou=SUDOers subtree to allow SUDO application to work with sudo rules stored in IPA LDAP (they are not in the same format as SUDO itself expects, thus _compatibility_ subtree). I feel so close though? Auth and Sudo works on 5.5 but something as simple as users changing passwords seems so simple to provide? Finally, password changes are not supported in cn=compat subtree. This is simply not implemented by schema compatibility plugin. You haven't answered earlier when people asked whether you are using cn=compat tree because you need to get information about Active Directory users or not. If you don't need integration with Active Directory, change LDAP base DN in your configuration to cn=accounts,dc=example,dc=com, to point your clients to the primary IPA subtree where all users and groups are available. That subtree is the main one and we do support password changes for DNs in it. -- / Alexander Bokovoy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Dec 1 11:57:29 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 1 Dec 2015 12:57:29 +0100 Subject: [Freeipa-users] FreeIPA AD password sync In-Reply-To: References: Message-ID: <565D8B29.8000402@redhat.com> On 11/30/2015 02:25 PM, Ga?per Bregar wrote: > I have been strugling with FreeIPA and AD password sync for a couple of > days now. At first everything was working fine, but then all of a sudden > the synchronization started to fail for me and another user. > > The error in passsync log was > > Ldap error in ModifyPassword >> 50: Insufficient access > > > It took me some time to figure out that it was failing just for the two us. > It was failing because we were in the admin user group in FreeIPA. Is this > intentional? Is it possible to somehow change this behaviour with a > setting? > > Regards, > Ga?per Hello Ga?per, I assume you are running with FreeIPA version 4.0 and above. At the moment, this is expected behavior, based on the permission configuration: 'System: Change User password': { 'ipapermright': {'write'}, 'ipapermtargetfilter': [ '(objectclass=posixaccount)', '(!(memberOf=%s))' % DN('cn=admins', api.env.container_group, api.env.basedn), ], 'ipapermdefaultattr': { 'krbprincipalkey', 'passwordhistory', 'sambalmpassword', 'sambantpassword', 'userpassword' }, ... 'default_privileges': { 'User Administrators', 'Modify Users and Reset passwords', 'PassSync Service', }, }, "PassSync Service" cannot indeed change passwords of admins group. I am wondering if we want to change the default, which was added so that lower-level administrators cannot change password of top level admins and impersonate them for example. Simo, any opinion? If you want to allow that, you could also add a new permission to allow changing admins group password and assign it to "PassSync Service" privilege. Martin From ssorce at redhat.com Tue Dec 1 13:41:51 2015 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 01 Dec 2015 08:41:51 -0500 Subject: [Freeipa-users] FreeIPA AD password sync In-Reply-To: <565D8B29.8000402@redhat.com> References: <565D8B29.8000402@redhat.com> Message-ID: <1448977311.9040.3.camel@redhat.com> On Tue, 2015-12-01 at 12:57 +0100, Martin Kosek wrote: > On 11/30/2015 02:25 PM, Ga?per Bregar wrote: > > I have been strugling with FreeIPA and AD password sync for a couple of > > days now. At first everything was working fine, but then all of a sudden > > the synchronization started to fail for me and another user. > > > > The error in passsync log was > > > > Ldap error in ModifyPassword > >> 50: Insufficient access > > > > > > It took me some time to figure out that it was failing just for the two us. > > It was failing because we were in the admin user group in FreeIPA. Is this > > intentional? Is it possible to somehow change this behaviour with a > > setting? > > > > Regards, > > Ga?per > > Hello Ga?per, > > I assume you are running with FreeIPA version 4.0 and above. At the moment, > this is expected behavior, based on the permission configuration: > > 'System: Change User password': { > 'ipapermright': {'write'}, > 'ipapermtargetfilter': [ > '(objectclass=posixaccount)', > '(!(memberOf=%s))' % DN('cn=admins', > api.env.container_group, > api.env.basedn), > ], > 'ipapermdefaultattr': { > 'krbprincipalkey', 'passwordhistory', 'sambalmpassword', > 'sambantpassword', 'userpassword' > }, > ... > 'default_privileges': { > 'User Administrators', > 'Modify Users and Reset passwords', > 'PassSync Service', > }, > }, > > > "PassSync Service" cannot indeed change passwords of admins group. I am > wondering if we want to change the default, which was added so that lower-level > administrators cannot change password of top level admins and impersonate them > for example. Simo, any opinion? We do not want to change the default behavior. Simo. > If you want to allow that, you could also add a new permission to allow > changing admins group password and assign it to "PassSync Service" privilege. > > Martin From mkosek at redhat.com Tue Dec 1 13:51:11 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 1 Dec 2015 14:51:11 +0100 Subject: [Freeipa-users] FreeIPA AD password sync In-Reply-To: <1448977311.9040.3.camel@redhat.com> References: <565D8B29.8000402@redhat.com> <1448977311.9040.3.camel@redhat.com> Message-ID: <565DA5CF.1090101@redhat.com> On 12/01/2015 02:41 PM, Simo Sorce wrote: > On Tue, 2015-12-01 at 12:57 +0100, Martin Kosek wrote: >> On 11/30/2015 02:25 PM, Ga?per Bregar wrote: >>> I have been strugling with FreeIPA and AD password sync for a couple of >>> days now. At first everything was working fine, but then all of a sudden >>> the synchronization started to fail for me and another user. >>> >>> The error in passsync log was >>> >>> Ldap error in ModifyPassword >>>> 50: Insufficient access >>> >>> >>> It took me some time to figure out that it was failing just for the two us. >>> It was failing because we were in the admin user group in FreeIPA. Is this >>> intentional? Is it possible to somehow change this behaviour with a >>> setting? >>> >>> Regards, >>> Ga?per >> >> Hello Ga?per, >> >> I assume you are running with FreeIPA version 4.0 and above. At the moment, >> this is expected behavior, based on the permission configuration: >> >> 'System: Change User password': { >> 'ipapermright': {'write'}, >> 'ipapermtargetfilter': [ >> '(objectclass=posixaccount)', >> '(!(memberOf=%s))' % DN('cn=admins', >> api.env.container_group, >> api.env.basedn), >> ], >> 'ipapermdefaultattr': { >> 'krbprincipalkey', 'passwordhistory', 'sambalmpassword', >> 'sambantpassword', 'userpassword' >> }, >> ... >> 'default_privileges': { >> 'User Administrators', >> 'Modify Users and Reset passwords', >> 'PassSync Service', >> }, >> }, >> >> >> "PassSync Service" cannot indeed change passwords of admins group. I am >> wondering if we want to change the default, which was added so that lower-level >> administrators cannot change password of top level admins and impersonate them >> for example. Simo, any opinion? > > We do not want to change the default behavior. > > Simo. Ok. I requested a Doc update: https://bugzilla.redhat.com/show_bug.cgi?id=1287092 Please feel free to comment in Bugzilla. Martin From gasper.bregar at nets.si Tue Dec 1 15:07:36 2015 From: gasper.bregar at nets.si (=?UTF-8?Q?Ga=C5=A1per_Bregar?=) Date: Tue, 1 Dec 2015 16:07:36 +0100 Subject: [Freeipa-users] FreeIPA AD password sync In-Reply-To: <565DA5CF.1090101@redhat.com> References: <565D8B29.8000402@redhat.com> <1448977311.9040.3.camel@redhat.com> <565DA5CF.1090101@redhat.com> Message-ID: Thank you for the quick reply and a solution. I will try it in the next couple of days. Regards, Ga?per On Tue, Dec 1, 2015 at 2:51 PM, Martin Kosek wrote: > On 12/01/2015 02:41 PM, Simo Sorce wrote: > > On Tue, 2015-12-01 at 12:57 +0100, Martin Kosek wrote: > >> On 11/30/2015 02:25 PM, Ga?per Bregar wrote: > >>> I have been strugling with FreeIPA and AD password sync for a couple of > >>> days now. At first everything was working fine, but then all of a > sudden > >>> the synchronization started to fail for me and another user. > >>> > >>> The error in passsync log was > >>> > >>> Ldap error in ModifyPassword > >>>> 50: Insufficient access > >>> > >>> > >>> It took me some time to figure out that it was failing just for the > two us. > >>> It was failing because we were in the admin user group in FreeIPA. Is > this > >>> intentional? Is it possible to somehow change this behaviour with a > >>> setting? > >>> > >>> Regards, > >>> Ga?per > >> > >> Hello Ga?per, > >> > >> I assume you are running with FreeIPA version 4.0 and above. At the > moment, > >> this is expected behavior, based on the permission configuration: > >> > >> 'System: Change User password': { > >> 'ipapermright': {'write'}, > >> 'ipapermtargetfilter': [ > >> '(objectclass=posixaccount)', > >> '(!(memberOf=%s))' % DN('cn=admins', > >> api.env.container_group, > >> api.env.basedn), > >> ], > >> 'ipapermdefaultattr': { > >> 'krbprincipalkey', 'passwordhistory', 'sambalmpassword', > >> 'sambantpassword', 'userpassword' > >> }, > >> ... > >> 'default_privileges': { > >> 'User Administrators', > >> 'Modify Users and Reset passwords', > >> 'PassSync Service', > >> }, > >> }, > >> > >> > >> "PassSync Service" cannot indeed change passwords of admins group. I am > >> wondering if we want to change the default, which was added so that > lower-level > >> administrators cannot change password of top level admins and > impersonate them > >> for example. Simo, any opinion? > > > > We do not want to change the default behavior. > > > > Simo. > > Ok. I requested a Doc update: > https://bugzilla.redhat.com/show_bug.cgi?id=1287092 > > Please feel free to comment in Bugzilla. > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.boorshtein at tremolosecurity.com Tue Dec 1 16:34:36 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 1 Dec 2015 11:34:36 -0500 Subject: [Freeipa-users] IPA + Java 8 + S4U2Self/Proxy In-Reply-To: References: <562FCD54.2080702@redhat.com> <562FDAAF.3050609@redhat.com> Message-ID: Simo & Team, After talking to the OpenJDK security list it turned out there is a bug in JDK8. The issue is fixed in JDK9 and after testing I'm running into a new issue. Same scenario described earlier in this email chain, but now it looks like the TGS-REP is not being marked as forwardable which is required for an s4u2self ticket is used in s4u2proxy (https://msdn.microsoft.com/en-us/library/cc246079.aspx) : "The S4U2proxy extension requires that the service ticket to the first service has the forwardable flag set (see Service 1 in the figure specifying Kerberos delegation with forwarded TGT, section 1.3.3). This ticket can be obtained through an S4U2self protocol exchange.". The TGS-REQ is asking for a forwardable ticket, but it doesn't look like the response is setting it as forwardable. Here's the exception: GSSException: Failure unspecified at GSS-API level (Mechanism level: Attempt to obtain S4U2self credentials failed!) at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:357) at sun.security.jgss.spnego.SpNegoCredElement.impersonate(SpNegoCredElement.java:92) at sun.security.jgss.GSSCredentialImpl.impersonate(GSSCredentialImpl.java:153) at test24u2.KerberosDemo$1.run(KerberosDemo.java:128) at test24u2.KerberosDemo$1.run(KerberosDemo.java:1) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at test24u2.KerberosDemo.impersonate(KerberosDemo.java:121) at test24u2.KerberosDemo.generateToken(KerberosDemo.java:179) at test24u2.KerberosDemo.main(KerberosDemo.java:215) Caused by: KrbException: S4U2self ticket must be FORWARDABLE at sun.security.krb5.internal.CredentialsUtil.acquireS4U2selfCreds(CredentialsUtil.java:75) at sun.security.krb5.Credentials.acquireS4U2selfCreds(Credentials.java:463) at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:353) ... 9 more Here's the entire debug output: >>> KeyTabInputStream, readName(): RHELENT.LAN >>> KeyTabInputStream, readName(): HTTP >>> KeyTabInputStream, readName(): s4u.rhelent.lan >>> KeyTab: load() entry length: 83; type: 18 >>> KeyTabInputStream, readName(): RHELENT.LAN >>> KeyTabInputStream, readName(): HTTP >>> KeyTabInputStream, readName(): s4u.rhelent.lan >>> KeyTab: load() entry length: 67; type: 17 >>> KeyTabInputStream, readName(): RHELENT.LAN >>> KeyTabInputStream, readName(): HTTP >>> KeyTabInputStream, readName(): s4u.rhelent.lan >>> KeyTab: load() entry length: 75; type: 16 >>> KeyTabInputStream, readName(): RHELENT.LAN >>> KeyTabInputStream, readName(): HTTP >>> KeyTabInputStream, readName(): s4u.rhelent.lan >>> KeyTab: load() entry length: 67; type: 23 Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN Java config name: null Native config name: /etc/krb5.conf Loading krb5 profile at /etc/krb5.conf Loaded from native config Added key: 23version: 1 Added key: 16version: 1 Added key: 17version: 1 Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN >>> KdcAccessibility: reset Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN Added key: 23version: 1 Added key: 16version: 1 Added key: 17version: 1 Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN default etypes for default_tkt_enctypes: 17 23 16. >>> KrbAsReq creating message >>> KrbKdcReq send: kdc=freeipa.rhelent.lan UDP:88, timeout=30000, number of retries =3, #bytes=175 >>> KDCCommunication: kdc=freeipa.rhelent.lan UDP:88, timeout=30000,Attempt =1, #bytes=175 >>> KrbKdcReq send: #bytes read=327 >>>Pre-Authentication Data: PA-DATA type = 136 >>>Pre-Authentication Data: PA-DATA type = 19 PA-ETYPE-INFO2 etype = 17, salt = 4k at PqWo9iUZZ$[r", s2kparams = null PA-ETYPE-INFO2 etype = 16, salt = KaQ|KB9)&A{.`Y;1k, s2kparams = null >>>Pre-Authentication Data: PA-DATA type = 2 PA-ENC-TIMESTAMP >>>Pre-Authentication Data: PA-DATA type = 133 >>> KdcAccessibility: remove freeipa.rhelent.lan >>> KDCRep: init() encoding tag is 126 req type is 11 >>>KRBError: cTime is Sat Jan 20 19:00:57 EST 1996 822182457000 sTime is Mon Nov 30 21:35:51 EST 2015 1448937351000 suSec is 558140 error code is 25 error Message is Additional pre-authentication required cname is HTTP/s4u.rhelent.lan at RHELENT.LAN sname is krbtgt/RHELENT.LAN at RHELENT.LAN eData provided. msgType is 30 >>>Pre-Authentication Data: PA-DATA type = 136 >>>Pre-Authentication Data: PA-DATA type = 19 PA-ETYPE-INFO2 etype = 17, salt = 4k at PqWo9iUZZ$[r", s2kparams = null PA-ETYPE-INFO2 etype = 16, salt = KaQ|KB9)&A{.`Y;1k, s2kparams = null >>>Pre-Authentication Data: PA-DATA type = 2 PA-ENC-TIMESTAMP >>>Pre-Authentication Data: PA-DATA type = 133 KRBError received: NEEDED_PREAUTH KrbAsReqBuilder: PREAUTH FAILED/REQ, re-send AS-REQ default etypes for default_tkt_enctypes: 17 23 16. Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN Added key: 23version: 1 Added key: 16version: 1 Added key: 17version: 1 Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN Added key: 23version: 1 Added key: 16version: 1 Added key: 17version: 1 Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN default etypes for default_tkt_enctypes: 17 23 16. >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType >>> KrbAsReq creating message >>> KrbKdcReq send: kdc=freeipa.rhelent.lan UDP:88, timeout=30000, number of retries =3, #bytes=264 >>> KDCCommunication: kdc=freeipa.rhelent.lan UDP:88, timeout=30000,Attempt =1, #bytes=264 >>> KrbKdcReq send: #bytes read=691 >>> KdcAccessibility: remove freeipa.rhelent.lan Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN Added key: 23version: 1 Added key: 16version: 1 Added key: 17version: 1 Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType >>> KrbAsRep cons in KrbAsReq.getReply HTTP/s4u.rhelent.lan Service subject: Subject: Principal: HTTP/s4u.rhelent.lan at RHELENT.LAN Private Credential: Ticket (hex) = 0000: 61 82 01 51 30 82 01 4D A0 03 02 01 05 A1 0D 1B a..Q0..M........ 0010: 0B 52 48 45 4C 45 4E 54 2E 4C 41 4E A2 20 30 1E .RHELENT.LAN. 0. 0020: A0 03 02 01 02 A1 17 30 15 1B 06 6B 72 62 74 67 .......0...krbtg 0030: 74 1B 0B 52 48 45 4C 45 4E 54 2E 4C 41 4E A3 82 t..RHELENT.LAN.. 0040: 01 13 30 82 01 0F A0 03 02 01 12 A1 03 02 01 01 ..0............. 0050: A2 82 01 01 04 81 FE 04 0B 24 5B A6 36 2A 4B C7 .........$[.6*K. 0060: 0D 58 1A EB 79 20 62 BE 16 44 28 93 5D 87 5B FD .X..y b..D(.].[. 0070: DE 20 7D CF 79 4C 0E CC 77 90 40 06 10 11 9F 70 . ..yL..w. at ....p 0080: 9E B4 7E B5 CA 14 27 23 DD CD D6 6E 31 1F FC CA ......'#...n1... 0090: 65 CB 98 47 2B F0 C8 3B 96 C3 D6 AF EB DB 91 2F e..G+..;......./ 00A0: 1D 88 66 53 4F 03 7B 47 3C 32 E8 F2 CE 3E B1 E7 ..fSO..G<2...>.. 00B0: 78 80 B3 37 6F 5E 18 76 68 F4 AE C6 C7 C2 B8 99 x..7o^.vh....... 00C0: 61 A3 42 A1 5D 32 69 BB 0D 42 C5 98 46 B8 8A C6 a.B.]2i..B..F... 00D0: 4A 68 88 E3 79 D0 E2 F7 DD 62 0F DD E6 6A 97 7B Jh..y....b...j.. 00E0: 4B A1 A0 1C 45 17 97 E4 CC 71 D2 86 61 52 40 34 K...E....q..aR at 4 00F0: DE EF 45 5E 21 94 AB 5C 76 91 CE 68 DB A1 94 5F ..E^!..\v..h..._ 0100: 14 CC 54 BB 35 85 EB 56 F0 FC 83 B5 CB 41 48 A1 ..T.5..V.....AH. 0110: AE C8 2F 22 C6 48 B9 14 CD 5F 9B B5 14 2B CC D5 ../".H..._...+.. 0120: B7 DC C3 74 4C 98 19 10 72 83 5D F6 BC A0 A1 9F ...tL...r.]..... 0130: 19 1F 63 07 AF C1 35 EE 1A 82 FE A5 88 CE 7A DF ..c...5.......z. 0140: 0F 43 E4 55 EC CC 0C 34 47 B4 B8 E1 C2 90 AC 63 .C.U...4G......c 0150: 19 01 A1 87 A5 ..... Client Principal = HTTP/s4u.rhelent.lan at RHELENT.LAN Server Principal = krbtgt/RHELENT.LAN at RHELENT.LAN Session Key = EncryptionKey: keyType=17 keyBytes (hex dump)= 0000: D9 D2 7F 9D 3F 5F 32 1A 41 10 4D 9F 0C 7D C5 D8 ....?_2.A.M..... Forwardable Ticket true Forwarded Ticket false Proxiable Ticket false Proxy Ticket false Postdated Ticket false Renewable Ticket true Initial Ticket true Auth Time = Mon Nov 30 21:35:51 EST 2015 Start Time = Mon Nov 30 21:35:51 EST 2015 End Time = Tue Dec 01 21:35:51 EST 2015 Renew Till = Mon Dec 07 21:35:51 EST 2015 Client Addresses Null Private Credential: /Users/mlb/Documents/localdev.keytab for HTTP/s4u.rhelent.lan at RHELENT.LAN Search Subject for Kerberos V5 INIT cred (<>, sun.security.jgss.krb5.Krb5InitCredential) Found ticket for HTTP/s4u.rhelent.lan at RHELENT.LAN to go to krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Tue Dec 01 21:35:51 EST 2015 Search Subject for SPNEGO INIT cred (<>, sun.security.jgss.spnego.SpNegoCredElement) Search Subject for Kerberos V5 INIT cred (<>, sun.security.jgss.krb5.Krb5InitCredential) Found ticket for HTTP/s4u.rhelent.lan at RHELENT.LAN to go to krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Tue Dec 01 21:35:51 EST 2015 >>> CksumType: sun.security.krb5.internal.crypto.HmacMd5ArcFourCksumType default etypes for default_tgs_enctypes: 17 23 16. >>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType >>> KrbKdcReq send: kdc=freeipa.rhelent.lan UDP:88, timeout=30000, number of retries =3, #bytes=772 >>> KDCCommunication: kdc=freeipa.rhelent.lan UDP:88, timeout=30000,Attempt =1, #bytes=772 >>> KrbKdcReq send: #bytes read=582 >>> KdcAccessibility: remove freeipa.rhelent.lan >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType GSSException: Failure unspecified at GSS-API level (Mechanism level: Attempt to obtain S4U2self credentials failed!) at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:357) at sun.security.jgss.spnego.SpNegoCredElement.impersonate(SpNegoCredElement.java:92) at sun.security.jgss.GSSCredentialImpl.impersonate(GSSCredentialImpl.java:153) at test24u2.KerberosDemo$1.run(KerberosDemo.java:128) at test24u2.KerberosDemo$1.run(KerberosDemo.java:1) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at test24u2.KerberosDemo.impersonate(KerberosDemo.java:121) at test24u2.KerberosDemo.generateToken(KerberosDemo.java:179) at test24u2.KerberosDemo.main(KerberosDemo.java:215) Caused by: KrbException: S4U2self ticket must be FORWARDABLE at sun.security.krb5.internal.CredentialsUtil.acquireS4U2selfCreds(CredentialsUtil.java:75) at sun.security.krb5.Credentials.acquireS4U2selfCreds(Credentials.java:463) at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:353) ... 9 more Here's the wireshark capture of the entire transaction: https://s3.amazonaws.com/ts-public-downloads/captures/java9-s4u2self.pcapng Is there something I need to configure in ipa? I've shown the steps I took to make s4u.rhelent.lan setup for delegation in the beginning of this chain. Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 On Tue, Oct 27, 2015 at 8:27 PM, Marc Boorshtein wrote: > Thanks Simo. It wouldn't surprise me that java's implementation is > wrong. The comments in the source even ask if its necessary to check. > > Thanks > Marc > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > (703) 828-4902 > > > On Tue, Oct 27, 2015 at 4:12 PM, Simo Sorce wrote: >> On 27/10/15 15:43, Marc Boorshtein wrote: >>>>> >>>>> >>>>> Looking at KrbKdcRep.java:73 it looks like the failure is happening >>>>> because java is setting the forwardable flag to true on the request >>>>> but the response has no options in it. Should the forwardable option >>>>> be false in the request? >>>> >>>> >>>> >>>> That's a fair guess. >>>> the whole point of constrained delegation (including protocol >>>> impersonation) >>>> is that you do not want to forward tickets, so you shouldn't ask for >>>> forwardable tickets methinks. >>>> >>>> Simo. >>>> >>> >>> Thanks Simio. I tried running kinit with forwarding disabled: >>> >>> $ kinit HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN -k -t >>> ./unison-freeipa.keytab -F >>> >>> $ klist -f >>> >>> Ticket cache: FILE:/tmp/krb5cc_500 >>> >>> Default principal: HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>> >>> >>> Valid starting Expires Service principal >>> >>> 10/27/15 15:32:52 10/28/15 15:32:52 krbtgt/RHELENT.LAN at RHELENT.LAN >>> >>> Flags: IA >>> >>> But when I try again Java refuses to generate the ticket: >>> >>> tremoloadmin at unison-freeipa ~]$ klist -f >>> Ticket cache: FILE:/tmp/krb5cc_500 >>> Default principal: HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>> >>> Valid starting Expires Service principal >>> 10/27/15 15:32:52 10/28/15 15:32:52 krbtgt/RHELENT.LAN at RHELENT.LAN >>> Flags: IA >>> >>> Hello World! >>> Search Subject for Kerberos V5 INIT cred (<>, >>> sun.security.jgss.krb5.Krb5InitCredential) >>> No Subject >>>>>> >>>>>> KinitOptions cache name is /tmp/krb5cc_500 >>>>>> DEBUG client principal is >>>>>> HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>>>> DEBUG server principal is >>>>>> krbtgt/RHELENT.LAN at RHELENT.LAN >>>>>> DEBUG key type: 18 >>>>>> DEBUG auth time: Tue Oct 27 15:32:52 EDT 2015 >>>>>> DEBUG start time: Tue Oct 27 15:32:52 EDT 2015 >>>>>> DEBUG end time: Wed Oct 28 15:32:52 EDT 2015 >>>>>> DEBUG renew_till time: null >>>>>> CCacheInputStream: readFlags() INITIAL; PRE_AUTH; >>>>>> DEBUG client principal is >>>>>> HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>> >>> Java config name: /home/tremoloadmin/krb5.conf >>> Loaded from Java config >>>>>> >>>>>> DEBUG server principal is >>>>>> X-CACHECONF:/krb5_ccache_conf_data/fast_avail/krbtgt/RHELENT.LAN at RHELENT.LAN@RHELENT.LAN >>>>>> DEBUG key type: 0 >>>>>> DEBUG auth time: Wed Dec 31 19:00:00 EST 1969 >>>>>> DEBUG start time: null >>>>>> DEBUG end time: Wed Dec 31 19:00:00 EST 1969 >>>>>> DEBUG renew_till time: null >>>>>> CCacheInputStream: readFlags() >>> >>> Found ticket for HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN to go to >>> krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Wed Oct 28 15:32:52 EDT >>> 2015 >>> Search Subject for SPNEGO INIT cred (<>, >>> sun.security.jgss.spnego.SpNegoCredElement) >>> No Subject >>> Search Subject for Kerberos V5 INIT cred (<>, >>> sun.security.jgss.krb5.Krb5InitCredential) >>> No Subject >>>>>> >>>>>> KinitOptions cache name is /tmp/krb5cc_500 >>>>>> DEBUG client principal is >>>>>> HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>>>> DEBUG server principal is >>>>>> krbtgt/RHELENT.LAN at RHELENT.LAN >>>>>> DEBUG key type: 18 >>>>>> DEBUG auth time: Tue Oct 27 15:32:52 EDT 2015 >>>>>> DEBUG start time: Tue Oct 27 15:32:52 EDT 2015 >>>>>> DEBUG end time: Wed Oct 28 15:32:52 EDT 2015 >>>>>> DEBUG renew_till time: null >>>>>> CCacheInputStream: readFlags() INITIAL; PRE_AUTH; >>>>>> DEBUG client principal is >>>>>> HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>>>> DEBUG server principal is >>>>>> X-CACHECONF:/krb5_ccache_conf_data/fast_avail/krbtgt/RHELENT.LAN at RHELENT.LAN@RHELENT.LAN >>>>>> DEBUG key type: 0 >>>>>> DEBUG auth time: Wed Dec 31 19:00:00 EST 1969 >>>>>> DEBUG start time: null >>>>>> DEBUG end time: Wed Dec 31 19:00:00 EST 1969 >>>>>> DEBUG renew_till time: null >>>>>> CCacheInputStream: readFlags() >>> >>> Found ticket for HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN to go to >>> krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Wed Oct 28 15:32:52 EDT >>> 2015 >>>>>> >>>>>> CksumType: sun.security.krb5.internal.crypto.HmacMd5ArcFourCksumType >>> >>> Exception in thread "main" GSSException: Failure unspecified at >>> GSS-API level (Mechanism level: Attempt to obtain S4U2self credentials >>> failed!) >>> at >>> sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:357) >>> at >>> sun.security.jgss.spnego.SpNegoCredElement.impersonate(SpNegoCredElement.java:94) >>> at >>> sun.security.jgss.GSSCredentialImpl.impersonate(GSSCredentialImpl.java:141) >>> at io.tremolo.App.main(App.java:27) >>> Caused by: KrbException: Invalid option setting in ticket request. (101) >>> at sun.security.krb5.KrbTgsReq.(KrbTgsReq.java:165) >>> at sun.security.krb5.KrbTgsReq.(KrbTgsReq.java:100) >>> at >>> sun.security.krb5.internal.CredentialsUtil.acquireS4U2selfCreds(CredentialsUtil.java:66) >>> at >>> sun.security.krb5.Credentials.acquireS4U2selfCreds(Credentials.java:463) >>> at >>> sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:353) >>> ... 3 more >>> >>> Looking at KrbTgsReq line 165: >>> >>> if (options.get(KDCOptions.FORWARDABLE) && >>> (!(asCreds.flags.get(Krb5.TKT_OPTS_FORWARDABLE)))) { >>> throw new KrbException(Krb5.KRB_AP_ERR_REQ_OPTIONS); >>> } >>> >>> If I read this correctly it has to be forwardable? If thats the case >>> is Java wrong for requiring the options to be there or is ipa wrong >>> for not sending the options with the response ticket? >> >> >> I think the best answer would be to look at what the MIT test program does >> and make sure Java does the same. >> This stuff works with the native libraries and is interoperable with Windows >> AD KDCs where the specification was born. >> >> Simo. >> >> >> -- >> Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Dec 1 16:49:35 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 01 Dec 2015 11:49:35 -0500 Subject: [Freeipa-users] IPA + Java 8 + S4U2Self/Proxy In-Reply-To: References: <562FCD54.2080702@redhat.com> <562FDAAF.3050609@redhat.com> Message-ID: <1448988575.9040.7.camel@redhat.com> On Tue, 2015-12-01 at 11:34 -0500, Marc Boorshtein wrote: > Simo & Team, > > After talking to the OpenJDK security list it turned out there is a > bug in JDK8. The issue is fixed in JDK9 and after testing I'm running > into a new issue. Same scenario described earlier in this email > chain, but now it looks like the TGS-REP is not being marked as > forwardable which is required for an s4u2self ticket is used in > s4u2proxy (https://msdn.microsoft.com/en-us/library/cc246079.aspx) : > "The S4U2proxy extension requires that the service ticket to the first > service has the forwardable flag set (see Service 1 in the figure > specifying Kerberos delegation with forwarded TGT, section 1.3.3). > This ticket can be obtained through an S4U2self protocol exchange.". > The TGS-REQ is asking for a forwardable ticket, but it doesn't look > like the response is setting it as forwardable. Here's the exception: > > GSSException: Failure unspecified at GSS-API level (Mechanism level: > Attempt to obtain S4U2self credentials failed!) > at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:357) > at sun.security.jgss.spnego.SpNegoCredElement.impersonate(SpNegoCredElement.java:92) > at sun.security.jgss.GSSCredentialImpl.impersonate(GSSCredentialImpl.java:153) > at test24u2.KerberosDemo$1.run(KerberosDemo.java:128) > at test24u2.KerberosDemo$1.run(KerberosDemo.java:1) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at test24u2.KerberosDemo.impersonate(KerberosDemo.java:121) > at test24u2.KerberosDemo.generateToken(KerberosDemo.java:179) > at test24u2.KerberosDemo.main(KerberosDemo.java:215) > Caused by: KrbException: S4U2self ticket must be FORWARDABLE > at sun.security.krb5.internal.CredentialsUtil.acquireS4U2selfCreds(CredentialsUtil.java:75) > at sun.security.krb5.Credentials.acquireS4U2selfCreds(Credentials.java:463) > at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:353) > ... 9 more > > Here's the entire debug output: > >>> KeyTabInputStream, readName(): RHELENT.LAN > >>> KeyTabInputStream, readName(): HTTP > >>> KeyTabInputStream, readName(): s4u.rhelent.lan > >>> KeyTab: load() entry length: 83; type: 18 > >>> KeyTabInputStream, readName(): RHELENT.LAN > >>> KeyTabInputStream, readName(): HTTP > >>> KeyTabInputStream, readName(): s4u.rhelent.lan > >>> KeyTab: load() entry length: 67; type: 17 > >>> KeyTabInputStream, readName(): RHELENT.LAN > >>> KeyTabInputStream, readName(): HTTP > >>> KeyTabInputStream, readName(): s4u.rhelent.lan > >>> KeyTab: load() entry length: 75; type: 16 > >>> KeyTabInputStream, readName(): RHELENT.LAN > >>> KeyTabInputStream, readName(): HTTP > >>> KeyTabInputStream, readName(): s4u.rhelent.lan > >>> KeyTab: load() entry length: 67; type: 23 > Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN > Java config name: null > Native config name: /etc/krb5.conf > Loading krb5 profile at /etc/krb5.conf > Loaded from native config > Added key: 23version: 1 > Added key: 16version: 1 > Added key: 17version: 1 > Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN > >>> KdcAccessibility: reset > Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN > Added key: 23version: 1 > Added key: 16version: 1 > Added key: 17version: 1 > Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN > default etypes for default_tkt_enctypes: 17 23 16. > >>> KrbAsReq creating message > >>> KrbKdcReq send: kdc=freeipa.rhelent.lan UDP:88, timeout=30000, number of retries =3, #bytes=175 > >>> KDCCommunication: kdc=freeipa.rhelent.lan UDP:88, timeout=30000,Attempt =1, #bytes=175 > >>> KrbKdcReq send: #bytes read=327 > >>>Pre-Authentication Data: > PA-DATA type = 136 > > >>>Pre-Authentication Data: > PA-DATA type = 19 > PA-ETYPE-INFO2 etype = 17, salt = 4k at PqWo9iUZZ$[r", s2kparams = null > PA-ETYPE-INFO2 etype = 16, salt = KaQ|KB PA-ETYPE-INFO2 etype = 23, salt = Wl=W>9)&A{.`Y;1k, s2kparams = null > > >>>Pre-Authentication Data: > PA-DATA type = 2 > PA-ENC-TIMESTAMP > >>>Pre-Authentication Data: > PA-DATA type = 133 > > >>> KdcAccessibility: remove freeipa.rhelent.lan > >>> KDCRep: init() encoding tag is 126 req type is 11 > >>>KRBError: > cTime is Sat Jan 20 19:00:57 EST 1996 822182457000 > sTime is Mon Nov 30 21:35:51 EST 2015 1448937351000 > suSec is 558140 > error code is 25 > error Message is Additional pre-authentication required > cname is HTTP/s4u.rhelent.lan at RHELENT.LAN > sname is krbtgt/RHELENT.LAN at RHELENT.LAN > eData provided. > msgType is 30 > >>>Pre-Authentication Data: > PA-DATA type = 136 > > >>>Pre-Authentication Data: > PA-DATA type = 19 > PA-ETYPE-INFO2 etype = 17, salt = 4k at PqWo9iUZZ$[r", s2kparams = null > PA-ETYPE-INFO2 etype = 16, salt = KaQ|KB PA-ETYPE-INFO2 etype = 23, salt = Wl=W>9)&A{.`Y;1k, s2kparams = null > > >>>Pre-Authentication Data: > PA-DATA type = 2 > PA-ENC-TIMESTAMP > >>>Pre-Authentication Data: > PA-DATA type = 133 > > KRBError received: NEEDED_PREAUTH > KrbAsReqBuilder: PREAUTH FAILED/REQ, re-send AS-REQ > default etypes for default_tkt_enctypes: 17 23 16. > Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN > Added key: 23version: 1 > Added key: 16version: 1 > Added key: 17version: 1 > Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN > Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN > Added key: 23version: 1 > Added key: 16version: 1 > Added key: 17version: 1 > Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN > default etypes for default_tkt_enctypes: 17 23 16. > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType > >>> KrbAsReq creating message > >>> KrbKdcReq send: kdc=freeipa.rhelent.lan UDP:88, timeout=30000, number of retries =3, #bytes=264 > >>> KDCCommunication: kdc=freeipa.rhelent.lan UDP:88, timeout=30000,Attempt =1, #bytes=264 > >>> KrbKdcReq send: #bytes read=691 > >>> KdcAccessibility: remove freeipa.rhelent.lan > Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN > Added key: 23version: 1 > Added key: 16version: 1 > Added key: 17version: 1 > Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType > >>> KrbAsRep cons in KrbAsReq.getReply HTTP/s4u.rhelent.lan > Service subject: Subject: > Principal: HTTP/s4u.rhelent.lan at RHELENT.LAN > Private Credential: Ticket (hex) = > 0000: 61 82 01 51 30 82 01 4D A0 03 02 01 05 A1 0D 1B a..Q0..M........ > 0010: 0B 52 48 45 4C 45 4E 54 2E 4C 41 4E A2 20 30 1E .RHELENT.LAN. 0. > 0020: A0 03 02 01 02 A1 17 30 15 1B 06 6B 72 62 74 67 .......0...krbtg > 0030: 74 1B 0B 52 48 45 4C 45 4E 54 2E 4C 41 4E A3 82 t..RHELENT.LAN.. > 0040: 01 13 30 82 01 0F A0 03 02 01 12 A1 03 02 01 01 ..0............. > 0050: A2 82 01 01 04 81 FE 04 0B 24 5B A6 36 2A 4B C7 .........$[.6*K. > 0060: 0D 58 1A EB 79 20 62 BE 16 44 28 93 5D 87 5B FD .X..y b..D(.].[. > 0070: DE 20 7D CF 79 4C 0E CC 77 90 40 06 10 11 9F 70 . ..yL..w. at ....p > 0080: 9E B4 7E B5 CA 14 27 23 DD CD D6 6E 31 1F FC CA ......'#...n1... > 0090: 65 CB 98 47 2B F0 C8 3B 96 C3 D6 AF EB DB 91 2F e..G+..;......./ > 00A0: 1D 88 66 53 4F 03 7B 47 3C 32 E8 F2 CE 3E B1 E7 ..fSO..G<2...>.. > 00B0: 78 80 B3 37 6F 5E 18 76 68 F4 AE C6 C7 C2 B8 99 x..7o^.vh....... > 00C0: 61 A3 42 A1 5D 32 69 BB 0D 42 C5 98 46 B8 8A C6 a.B.]2i..B..F... > 00D0: 4A 68 88 E3 79 D0 E2 F7 DD 62 0F DD E6 6A 97 7B Jh..y....b...j.. > 00E0: 4B A1 A0 1C 45 17 97 E4 CC 71 D2 86 61 52 40 34 K...E....q..aR at 4 > 00F0: DE EF 45 5E 21 94 AB 5C 76 91 CE 68 DB A1 94 5F ..E^!..\v..h..._ > 0100: 14 CC 54 BB 35 85 EB 56 F0 FC 83 B5 CB 41 48 A1 ..T.5..V.....AH. > 0110: AE C8 2F 22 C6 48 B9 14 CD 5F 9B B5 14 2B CC D5 ../".H..._...+.. > 0120: B7 DC C3 74 4C 98 19 10 72 83 5D F6 BC A0 A1 9F ...tL...r.]..... > 0130: 19 1F 63 07 AF C1 35 EE 1A 82 FE A5 88 CE 7A DF ..c...5.......z. > 0140: 0F 43 E4 55 EC CC 0C 34 47 B4 B8 E1 C2 90 AC 63 .C.U...4G......c > 0150: 19 01 A1 87 A5 ..... > > Client Principal = HTTP/s4u.rhelent.lan at RHELENT.LAN > Server Principal = krbtgt/RHELENT.LAN at RHELENT.LAN > Session Key = EncryptionKey: keyType=17 keyBytes (hex dump)= > 0000: D9 D2 7F 9D 3F 5F 32 1A 41 10 4D 9F 0C 7D C5 D8 ....?_2.A.M..... > > > Forwardable Ticket true > Forwarded Ticket false > Proxiable Ticket false > Proxy Ticket false > Postdated Ticket false > Renewable Ticket true > Initial Ticket true > Auth Time = Mon Nov 30 21:35:51 EST 2015 > Start Time = Mon Nov 30 21:35:51 EST 2015 > End Time = Tue Dec 01 21:35:51 EST 2015 > Renew Till = Mon Dec 07 21:35:51 EST 2015 > Client Addresses Null > Private Credential: /Users/mlb/Documents/localdev.keytab for > HTTP/s4u.rhelent.lan at RHELENT.LAN > > Search Subject for Kerberos V5 INIT cred (<>, > sun.security.jgss.krb5.Krb5InitCredential) > Found ticket for HTTP/s4u.rhelent.lan at RHELENT.LAN to go to > krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Tue Dec 01 21:35:51 EST > 2015 > Search Subject for SPNEGO INIT cred (<>, > sun.security.jgss.spnego.SpNegoCredElement) > Search Subject for Kerberos V5 INIT cred (<>, > sun.security.jgss.krb5.Krb5InitCredential) > Found ticket for HTTP/s4u.rhelent.lan at RHELENT.LAN to go to > krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Tue Dec 01 21:35:51 EST > 2015 > >>> CksumType: sun.security.krb5.internal.crypto.HmacMd5ArcFourCksumType > default etypes for default_tgs_enctypes: 17 23 16. > >>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType > >>> KrbKdcReq send: kdc=freeipa.rhelent.lan UDP:88, timeout=30000, number of retries =3, #bytes=772 > >>> KDCCommunication: kdc=freeipa.rhelent.lan UDP:88, timeout=30000,Attempt =1, #bytes=772 > >>> KrbKdcReq send: #bytes read=582 > >>> KdcAccessibility: remove freeipa.rhelent.lan > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType > GSSException: Failure unspecified at GSS-API level (Mechanism level: > Attempt to obtain S4U2self credentials failed!) > at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:357) > at sun.security.jgss.spnego.SpNegoCredElement.impersonate(SpNegoCredElement.java:92) > at sun.security.jgss.GSSCredentialImpl.impersonate(GSSCredentialImpl.java:153) > at test24u2.KerberosDemo$1.run(KerberosDemo.java:128) > at test24u2.KerberosDemo$1.run(KerberosDemo.java:1) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at test24u2.KerberosDemo.impersonate(KerberosDemo.java:121) > at test24u2.KerberosDemo.generateToken(KerberosDemo.java:179) > at test24u2.KerberosDemo.main(KerberosDemo.java:215) > Caused by: KrbException: S4U2self ticket must be FORWARDABLE > at sun.security.krb5.internal.CredentialsUtil.acquireS4U2selfCreds(CredentialsUtil.java:75) > at sun.security.krb5.Credentials.acquireS4U2selfCreds(Credentials.java:463) > at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:353) > ... 9 more > > Here's the wireshark capture of the entire transaction: > https://s3.amazonaws.com/ts-public-downloads/captures/java9-s4u2self.pcapng > > Is there something I need to configure in ipa? I've shown the steps I > took to make s4u.rhelent.lan setup for delegation in the beginning of > this chain. How do you acquire the user ticket ? Do you have the kdc log (/var/log/krb5kdc.log) that shows what the server has been requested and what it released ? Simo. > Thanks > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > (703) 828-4902 > > > On Tue, Oct 27, 2015 at 8:27 PM, Marc Boorshtein > wrote: > > Thanks Simo. It wouldn't surprise me that java's implementation is > > wrong. The comments in the source even ask if its necessary to check. > > > > Thanks > > Marc > > Marc Boorshtein > > CTO Tremolo Security > > marc.boorshtein at tremolosecurity.com > > (703) 828-4902 > > > > > > On Tue, Oct 27, 2015 at 4:12 PM, Simo Sorce wrote: > >> On 27/10/15 15:43, Marc Boorshtein wrote: > >>>>> > >>>>> > >>>>> Looking at KrbKdcRep.java:73 it looks like the failure is happening > >>>>> because java is setting the forwardable flag to true on the request > >>>>> but the response has no options in it. Should the forwardable option > >>>>> be false in the request? > >>>> > >>>> > >>>> > >>>> That's a fair guess. > >>>> the whole point of constrained delegation (including protocol > >>>> impersonation) > >>>> is that you do not want to forward tickets, so you shouldn't ask for > >>>> forwardable tickets methinks. > >>>> > >>>> Simo. > >>>> > >>> > >>> Thanks Simio. I tried running kinit with forwarding disabled: > >>> > >>> $ kinit HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN -k -t > >>> ./unison-freeipa.keytab -F > >>> > >>> $ klist -f > >>> > >>> Ticket cache: FILE:/tmp/krb5cc_500 > >>> > >>> Default principal: HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN > >>> > >>> > >>> Valid starting Expires Service principal > >>> > >>> 10/27/15 15:32:52 10/28/15 15:32:52 krbtgt/RHELENT.LAN at RHELENT.LAN > >>> > >>> Flags: IA > >>> > >>> But when I try again Java refuses to generate the ticket: > >>> > >>> tremoloadmin at unison-freeipa ~]$ klist -f > >>> Ticket cache: FILE:/tmp/krb5cc_500 > >>> Default principal: HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN > >>> > >>> Valid starting Expires Service principal > >>> 10/27/15 15:32:52 10/28/15 15:32:52 krbtgt/RHELENT.LAN at RHELENT.LAN > >>> Flags: IA > >>> > >>> Hello World! > >>> Search Subject for Kerberos V5 INIT cred (<>, > >>> sun.security.jgss.krb5.Krb5InitCredential) > >>> No Subject > >>>>>> > >>>>>> KinitOptions cache name is /tmp/krb5cc_500 > >>>>>> DEBUG client principal is > >>>>>> HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN > >>>>>> DEBUG server principal is > >>>>>> krbtgt/RHELENT.LAN at RHELENT.LAN > >>>>>> DEBUG key type: 18 > >>>>>> DEBUG auth time: Tue Oct 27 15:32:52 EDT 2015 > >>>>>> DEBUG start time: Tue Oct 27 15:32:52 EDT 2015 > >>>>>> DEBUG end time: Wed Oct 28 15:32:52 EDT 2015 > >>>>>> DEBUG renew_till time: null > >>>>>> CCacheInputStream: readFlags() INITIAL; PRE_AUTH; > >>>>>> DEBUG client principal is > >>>>>> HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN > >>> > >>> Java config name: /home/tremoloadmin/krb5.conf > >>> Loaded from Java config > >>>>>> > >>>>>> DEBUG server principal is > >>>>>> X-CACHECONF:/krb5_ccache_conf_data/fast_avail/krbtgt/RHELENT.LAN at RHELENT.LAN@RHELENT.LAN > >>>>>> DEBUG key type: 0 > >>>>>> DEBUG auth time: Wed Dec 31 19:00:00 EST 1969 > >>>>>> DEBUG start time: null > >>>>>> DEBUG end time: Wed Dec 31 19:00:00 EST 1969 > >>>>>> DEBUG renew_till time: null > >>>>>> CCacheInputStream: readFlags() > >>> > >>> Found ticket for HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN to go to > >>> krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Wed Oct 28 15:32:52 EDT > >>> 2015 > >>> Search Subject for SPNEGO INIT cred (<>, > >>> sun.security.jgss.spnego.SpNegoCredElement) > >>> No Subject > >>> Search Subject for Kerberos V5 INIT cred (<>, > >>> sun.security.jgss.krb5.Krb5InitCredential) > >>> No Subject > >>>>>> > >>>>>> KinitOptions cache name is /tmp/krb5cc_500 > >>>>>> DEBUG client principal is > >>>>>> HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN > >>>>>> DEBUG server principal is > >>>>>> krbtgt/RHELENT.LAN at RHELENT.LAN > >>>>>> DEBUG key type: 18 > >>>>>> DEBUG auth time: Tue Oct 27 15:32:52 EDT 2015 > >>>>>> DEBUG start time: Tue Oct 27 15:32:52 EDT 2015 > >>>>>> DEBUG end time: Wed Oct 28 15:32:52 EDT 2015 > >>>>>> DEBUG renew_till time: null > >>>>>> CCacheInputStream: readFlags() INITIAL; PRE_AUTH; > >>>>>> DEBUG client principal is > >>>>>> HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN > >>>>>> DEBUG server principal is > >>>>>> X-CACHECONF:/krb5_ccache_conf_data/fast_avail/krbtgt/RHELENT.LAN at RHELENT.LAN@RHELENT.LAN > >>>>>> DEBUG key type: 0 > >>>>>> DEBUG auth time: Wed Dec 31 19:00:00 EST 1969 > >>>>>> DEBUG start time: null > >>>>>> DEBUG end time: Wed Dec 31 19:00:00 EST 1969 > >>>>>> DEBUG renew_till time: null > >>>>>> CCacheInputStream: readFlags() > >>> > >>> Found ticket for HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN to go to > >>> krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Wed Oct 28 15:32:52 EDT > >>> 2015 > >>>>>> > >>>>>> CksumType: sun.security.krb5.internal.crypto.HmacMd5ArcFourCksumType > >>> > >>> Exception in thread "main" GSSException: Failure unspecified at > >>> GSS-API level (Mechanism level: Attempt to obtain S4U2self credentials > >>> failed!) > >>> at > >>> sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:357) > >>> at > >>> sun.security.jgss.spnego.SpNegoCredElement.impersonate(SpNegoCredElement.java:94) > >>> at > >>> sun.security.jgss.GSSCredentialImpl.impersonate(GSSCredentialImpl.java:141) > >>> at io.tremolo.App.main(App.java:27) > >>> Caused by: KrbException: Invalid option setting in ticket request. (101) > >>> at sun.security.krb5.KrbTgsReq.(KrbTgsReq.java:165) > >>> at sun.security.krb5.KrbTgsReq.(KrbTgsReq.java:100) > >>> at > >>> sun.security.krb5.internal.CredentialsUtil.acquireS4U2selfCreds(CredentialsUtil.java:66) > >>> at > >>> sun.security.krb5.Credentials.acquireS4U2selfCreds(Credentials.java:463) > >>> at > >>> sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:353) > >>> ... 3 more > >>> > >>> Looking at KrbTgsReq line 165: > >>> > >>> if (options.get(KDCOptions.FORWARDABLE) && > >>> (!(asCreds.flags.get(Krb5.TKT_OPTS_FORWARDABLE)))) { > >>> throw new KrbException(Krb5.KRB_AP_ERR_REQ_OPTIONS); > >>> } > >>> > >>> If I read this correctly it has to be forwardable? If thats the case > >>> is Java wrong for requiring the options to be there or is ipa wrong > >>> for not sending the options with the response ticket? > >> > >> > >> I think the best answer would be to look at what the MIT test program does > >> and make sure Java does the same. > >> This stuff works with the native libraries and is interoperable with Windows > >> AD KDCs where the specification was born. > >> > >> Simo. > >> > >> > >> -- > >> Simo Sorce * Red Hat, Inc * New York -- Simo Sorce * Red Hat, Inc * New York From marc.boorshtein at tremolosecurity.com Tue Dec 1 16:55:54 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 1 Dec 2015 11:55:54 -0500 Subject: [Freeipa-users] IPA + Java 8 + S4U2Self/Proxy In-Reply-To: <1448988575.9040.7.camel@redhat.com> References: <562FCD54.2080702@redhat.com> <562FDAAF.3050609@redhat.com> <1448988575.9040.7.camel@redhat.com> Message-ID: > > How do you acquire the user ticket ? > Using a keytab. Here's a link to the example code I'm using: https://github.com/ymartin59/java-kerberos-sfudemo I have Java set to use IPA as the DNS server and I'm passing in mmosley as the user to impersonate and HTTP/freeipa.rhelent.lan as the service that will consume the impersonated user's ticket. > Do you have the kdc log (/var/log/krb5kdc.log) that shows what the > server has been requested and what it released ? > Sure: Dec 01 11:55:17 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 etypes {17 23 16}) 10.8.0.2: NEEDED_PREAUTH: HTTP/s4u.rhelent.lan at RHELENT.LAN for krbtgt/RHELENT.LAN at RHELENT.LAN, Additional pre-authentication required Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 etypes {17 23 16}) 10.8.0.2: ISSUE: authtime 1448988918, etypes {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for krbtgt/RHELENT.LAN at RHELENT.LAN Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (3 etypes {17 23 16}) 10.8.0.2: ISSUE: authtime 1448988918, etypes {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for HTTP/s4u.rhelent.lan at RHELENT.LAN Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): ... PROTOCOL-TRANSITION s4u-client=mmosley at RHELENT.LAN Thanks From simo at redhat.com Tue Dec 1 17:42:24 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 01 Dec 2015 12:42:24 -0500 Subject: [Freeipa-users] IPA + Java 8 + S4U2Self/Proxy In-Reply-To: References: <562FCD54.2080702@redhat.com> <562FDAAF.3050609@redhat.com> <1448988575.9040.7.camel@redhat.com> Message-ID: <1448991744.9040.11.camel@redhat.com> On Tue, 2015-12-01 at 11:55 -0500, Marc Boorshtein wrote: > > > > How do you acquire the user ticket ? > > > > Using a keytab. Here's a link to the example code I'm using: > https://github.com/ymartin59/java-kerberos-sfudemo I have Java set to > use IPA as the DNS server and I'm passing in mmosley as the user to > impersonate and HTTP/freeipa.rhelent.lan as the service that will > consume the impersonated user's ticket. > > > Do you have the kdc log (/var/log/krb5kdc.log) that shows what the > > server has been requested and what it released ? > > > > Sure: > > Dec 01 11:55:17 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 > etypes {17 23 16}) 10.8.0.2: NEEDED_PREAUTH: > HTTP/s4u.rhelent.lan at RHELENT.LAN for krbtgt/RHELENT.LAN at RHELENT.LAN, > Additional pre-authentication required > Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 > etypes {17 23 16}) 10.8.0.2: ISSUE: authtime 1448988918, etypes > {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for > krbtgt/RHELENT.LAN at RHELENT.LAN > Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (3 > etypes {17 23 16}) 10.8.0.2: ISSUE: authtime 1448988918, etypes > {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for > HTTP/s4u.rhelent.lan at RHELENT.LAN > Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): ... > PROTOCOL-TRANSITION s4u-client=mmosley at RHELENT.LAN > > Thanks I think for s4u2self you may have missed a conf step (we primarily use s4u2proxy in the product *without* any s4u2self step). Can you check that you followed the procedure described here: https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-kdb/README.s4u2proxy.txt#n90 I think they key part is setting the +ok_to_auth_as_delegate flag which we do not provide an official higher level interface for yet. Simo. -- Simo Sorce * Red Hat, Inc * New York From marc.boorshtein at tremolosecurity.com Tue Dec 1 17:55:10 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 1 Dec 2015 12:55:10 -0500 Subject: [Freeipa-users] IPA + Java 8 + S4U2Self/Proxy In-Reply-To: <1448991744.9040.11.camel@redhat.com> References: <562FCD54.2080702@redhat.com> <562FDAAF.3050609@redhat.com> <1448988575.9040.7.camel@redhat.com> <1448991744.9040.11.camel@redhat.com> Message-ID: I can now get a ticket! This is how I originally created the user: $ kinit admin $ ipa service-add HTTP/s4u.rhelent.lan at rhelent.lan --ok-as-delegate=true Here's the object in the directory: dn: krbprincipalname=HTTP/s4u.rhelent.lan at RHELENT.LAN,cn=services,cn=accounts, dc=rhelent,dc=lan ipaKrbPrincipalAlias: HTTP/s4u.rhelent.lan at RHELENT.LAN objectClass: ipaobject objectClass: ipaservice objectClass: krbticketpolicyaux objectClass: ipakrbprincipal objectClass: krbprincipal objectClass: krbprincipalaux objectClass: pkiuser objectClass: top krbTicketFlags: 1048704 managedBy: fqdn=s4u.rhelent.lan,cn=computers,cn=accounts,dc=rhelent,dc=lan krbPrincipalName: HTTP/s4u.rhelent.lan at RHELENT.LAN ipaUniqueID: 3b563d36-88e0-11e5-917d-525400cab9fa krbLastPwdChange: 20151112021359Z krbExtraData:: AALn9UNWSFRUUC9zNHUucmhlbGVudC5sYW5AUkhFTEVOVC5MQU4A krbLastSuccessfulAuth: 20151201165518Z Just now, I ran: [root at freeipa ~]# kadmin.local Authenticating as principal admin/admin at RHELENT.LAN with password. kadmin.local: modprinc +ok_to_auth_as_delegate HTTP/s4u.rhelent.lan Principal "HTTP/s4u.rhelent.lan at RHELENT.LAN" modified. and now the directory object is dn: krbprincipalname=HTTP/s4u.rhelent.lan at RHELENT.LAN,cn=services,cn=accounts, dc=rhelent,dc=lan ipaKrbPrincipalAlias: HTTP/s4u.rhelent.lan at RHELENT.LAN objectClass: ipaobject objectClass: ipaservice objectClass: krbticketpolicyaux objectClass: ipakrbprincipal objectClass: krbprincipal objectClass: krbprincipalaux objectClass: pkiuser objectClass: top krbTicketFlags: 3145856 managedBy: fqdn=s4u.rhelent.lan,cn=computers,cn=accounts,dc=rhelent,dc=lan krbPrincipalName: HTTP/s4u.rhelent.lan at RHELENT.LAN ipaUniqueID: 3b563d36-88e0-11e5-917d-525400cab9fa krbLastPwdChange: 20151112021359Z krbExtraData:: AAIx3l1WYWRtaW4vYWRtaW5AUkhFTEVOVC5MQU4A krbLastSuccessfulAuth: 20151201175200Z Ticket flags clearly changed. Now to see if this works with ipa-web. Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 On Tue, Dec 1, 2015 at 12:42 PM, Simo Sorce wrote: > On Tue, 2015-12-01 at 11:55 -0500, Marc Boorshtein wrote: >> > >> > How do you acquire the user ticket ? >> > >> >> Using a keytab. Here's a link to the example code I'm using: >> https://github.com/ymartin59/java-kerberos-sfudemo I have Java set to >> use IPA as the DNS server and I'm passing in mmosley as the user to >> impersonate and HTTP/freeipa.rhelent.lan as the service that will >> consume the impersonated user's ticket. >> >> > Do you have the kdc log (/var/log/krb5kdc.log) that shows what the >> > server has been requested and what it released ? >> > >> >> Sure: >> >> Dec 01 11:55:17 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 >> etypes {17 23 16}) 10.8.0.2: NEEDED_PREAUTH: >> HTTP/s4u.rhelent.lan at RHELENT.LAN for krbtgt/RHELENT.LAN at RHELENT.LAN, >> Additional pre-authentication required >> Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 >> etypes {17 23 16}) 10.8.0.2: ISSUE: authtime 1448988918, etypes >> {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for >> krbtgt/RHELENT.LAN at RHELENT.LAN >> Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (3 >> etypes {17 23 16}) 10.8.0.2: ISSUE: authtime 1448988918, etypes >> {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for >> HTTP/s4u.rhelent.lan at RHELENT.LAN >> Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): ... >> PROTOCOL-TRANSITION s4u-client=mmosley at RHELENT.LAN >> >> Thanks > > I think for s4u2self you may have missed a conf step (we primarily use > s4u2proxy in the product *without* any s4u2self step). > > Can you check that you followed the procedure described here: > https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-kdb/README.s4u2proxy.txt#n90 > > I think they key part is setting the +ok_to_auth_as_delegate flag which > we do not provide an official higher level interface for yet. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > From marc.boorshtein at tremolosecurity.com Tue Dec 1 18:07:54 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 1 Dec 2015 13:07:54 -0500 Subject: [Freeipa-users] Documentation on the JSON format for ipa-web? Message-ID: FreeIPA Team, I've created a plugin for working with freeipa, but right now its using reverse engineered JSON that I then turned into Java POJOs. It works but I'd like to have something a bit better managed. Is there any documentation or a place in the code base I can look for a more formal definition of the JSON so I can build a better mapping? Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com From simo at redhat.com Tue Dec 1 18:14:10 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 01 Dec 2015 13:14:10 -0500 Subject: [Freeipa-users] IPA + Java 8 + S4U2Self/Proxy In-Reply-To: References: <562FCD54.2080702@redhat.com> <562FDAAF.3050609@redhat.com> <1448988575.9040.7.camel@redhat.com> <1448991744.9040.11.camel@redhat.com> Message-ID: <1448993650.9040.14.camel@redhat.com> On Tue, 2015-12-01 at 12:55 -0500, Marc Boorshtein wrote: > I can now get a ticket! This is how I originally created the user: > > $ kinit admin > $ ipa service-add HTTP/s4u.rhelent.lan at rhelent.lan --ok-as-delegate=true ok-as-delegate != ok_to_auth_as_delegate ... I know, it is a little confusing :-/ but these are the upstream flag names, and they both exist and do different things. Simo. > Here's the object in the directory: > > dn: krbprincipalname=HTTP/s4u.rhelent.lan at RHELENT.LAN,cn=services,cn=accounts, > dc=rhelent,dc=lan > ipaKrbPrincipalAlias: HTTP/s4u.rhelent.lan at RHELENT.LAN > objectClass: ipaobject > objectClass: ipaservice > objectClass: krbticketpolicyaux > objectClass: ipakrbprincipal > objectClass: krbprincipal > objectClass: krbprincipalaux > objectClass: pkiuser > objectClass: top > krbTicketFlags: 1048704 > managedBy: fqdn=s4u.rhelent.lan,cn=computers,cn=accounts,dc=rhelent,dc=lan > krbPrincipalName: HTTP/s4u.rhelent.lan at RHELENT.LAN > ipaUniqueID: 3b563d36-88e0-11e5-917d-525400cab9fa > krbLastPwdChange: 20151112021359Z > krbExtraData:: AALn9UNWSFRUUC9zNHUucmhlbGVudC5sYW5AUkhFTEVOVC5MQU4A > krbLastSuccessfulAuth: 20151201165518Z > > Just now, I ran: > [root at freeipa ~]# kadmin.local > Authenticating as principal admin/admin at RHELENT.LAN with password. > kadmin.local: modprinc +ok_to_auth_as_delegate HTTP/s4u.rhelent.lan > Principal "HTTP/s4u.rhelent.lan at RHELENT.LAN" modified. > > and now the directory object is > dn: krbprincipalname=HTTP/s4u.rhelent.lan at RHELENT.LAN,cn=services,cn=accounts, > dc=rhelent,dc=lan > ipaKrbPrincipalAlias: HTTP/s4u.rhelent.lan at RHELENT.LAN > objectClass: ipaobject > objectClass: ipaservice > objectClass: krbticketpolicyaux > objectClass: ipakrbprincipal > objectClass: krbprincipal > objectClass: krbprincipalaux > objectClass: pkiuser > objectClass: top > krbTicketFlags: 3145856 > managedBy: fqdn=s4u.rhelent.lan,cn=computers,cn=accounts,dc=rhelent,dc=lan > krbPrincipalName: HTTP/s4u.rhelent.lan at RHELENT.LAN > ipaUniqueID: 3b563d36-88e0-11e5-917d-525400cab9fa > krbLastPwdChange: 20151112021359Z > krbExtraData:: AAIx3l1WYWRtaW4vYWRtaW5AUkhFTEVOVC5MQU4A > krbLastSuccessfulAuth: 20151201175200Z > > Ticket flags clearly changed. Now to see if this works with ipa-web. > Thanks > > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > (703) 828-4902 > > > On Tue, Dec 1, 2015 at 12:42 PM, Simo Sorce wrote: > > On Tue, 2015-12-01 at 11:55 -0500, Marc Boorshtein wrote: > >> > > >> > How do you acquire the user ticket ? > >> > > >> > >> Using a keytab. Here's a link to the example code I'm using: > >> https://github.com/ymartin59/java-kerberos-sfudemo I have Java set to > >> use IPA as the DNS server and I'm passing in mmosley as the user to > >> impersonate and HTTP/freeipa.rhelent.lan as the service that will > >> consume the impersonated user's ticket. > >> > >> > Do you have the kdc log (/var/log/krb5kdc.log) that shows what the > >> > server has been requested and what it released ? > >> > > >> > >> Sure: > >> > >> Dec 01 11:55:17 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 > >> etypes {17 23 16}) 10.8.0.2: NEEDED_PREAUTH: > >> HTTP/s4u.rhelent.lan at RHELENT.LAN for krbtgt/RHELENT.LAN at RHELENT.LAN, > >> Additional pre-authentication required > >> Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 > >> etypes {17 23 16}) 10.8.0.2: ISSUE: authtime 1448988918, etypes > >> {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for > >> krbtgt/RHELENT.LAN at RHELENT.LAN > >> Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (3 > >> etypes {17 23 16}) 10.8.0.2: ISSUE: authtime 1448988918, etypes > >> {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for > >> HTTP/s4u.rhelent.lan at RHELENT.LAN > >> Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): ... > >> PROTOCOL-TRANSITION s4u-client=mmosley at RHELENT.LAN > >> > >> Thanks > > > > I think for s4u2self you may have missed a conf step (we primarily use > > s4u2proxy in the product *without* any s4u2self step). > > > > Can you check that you followed the procedure described here: > > https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-kdb/README.s4u2proxy.txt#n90 > > > > I think they key part is setting the +ok_to_auth_as_delegate flag which > > we do not provide an official higher level interface for yet. > > > > Simo. > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > -- Simo Sorce * Red Hat, Inc * New York From marc.boorshtein at tremolosecurity.com Tue Dec 1 18:28:44 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 1 Dec 2015 13:28:44 -0500 Subject: [Freeipa-users] IPA + Java 8 + S4U2Self/Proxy In-Reply-To: <1448993650.9040.14.camel@redhat.com> References: <562FCD54.2080702@redhat.com> <562FDAAF.3050609@redhat.com> <1448988575.9040.7.camel@redhat.com> <1448991744.9040.11.camel@redhat.com> <1448993650.9040.14.camel@redhat.com> Message-ID: Got it. BTW, with that java 8 s4u2self works too. Thanks again for the help! Marc Boorshtein CTO, Tremolo Security, Inc. On Dec 1, 2015 1:14 PM, "Simo Sorce" wrote: > On Tue, 2015-12-01 at 12:55 -0500, Marc Boorshtein wrote: > > I can now get a ticket! This is how I originally created the user: > > > > $ kinit admin > > $ ipa service-add HTTP/s4u.rhelent.lan at rhelent.lan --ok-as-delegate=true > > ok-as-delegate != ok_to_auth_as_delegate ... > > I know, it is a little confusing :-/ but these are the upstream flag > names, and they both exist and do different things. > > Simo. > > > Here's the object in the directory: > > > > dn: krbprincipalname=HTTP/s4u.rhelent.lan at RHELENT.LAN > ,cn=services,cn=accounts, > > dc=rhelent,dc=lan > > ipaKrbPrincipalAlias: HTTP/s4u.rhelent.lan at RHELENT.LAN > > objectClass: ipaobject > > objectClass: ipaservice > > objectClass: krbticketpolicyaux > > objectClass: ipakrbprincipal > > objectClass: krbprincipal > > objectClass: krbprincipalaux > > objectClass: pkiuser > > objectClass: top > > krbTicketFlags: 1048704 > > managedBy: > fqdn=s4u.rhelent.lan,cn=computers,cn=accounts,dc=rhelent,dc=lan > > krbPrincipalName: HTTP/s4u.rhelent.lan at RHELENT.LAN > > ipaUniqueID: 3b563d36-88e0-11e5-917d-525400cab9fa > > krbLastPwdChange: 20151112021359Z > > krbExtraData:: AALn9UNWSFRUUC9zNHUucmhlbGVudC5sYW5AUkhFTEVOVC5MQU4A > > krbLastSuccessfulAuth: 20151201165518Z > > > > Just now, I ran: > > [root at freeipa ~]# kadmin.local > > Authenticating as principal admin/admin at RHELENT.LAN with password. > > kadmin.local: modprinc +ok_to_auth_as_delegate HTTP/s4u.rhelent.lan > > Principal "HTTP/s4u.rhelent.lan at RHELENT.LAN" modified. > > > > and now the directory object is > > dn: krbprincipalname=HTTP/s4u.rhelent.lan at RHELENT.LAN > ,cn=services,cn=accounts, > > dc=rhelent,dc=lan > > ipaKrbPrincipalAlias: HTTP/s4u.rhelent.lan at RHELENT.LAN > > objectClass: ipaobject > > objectClass: ipaservice > > objectClass: krbticketpolicyaux > > objectClass: ipakrbprincipal > > objectClass: krbprincipal > > objectClass: krbprincipalaux > > objectClass: pkiuser > > objectClass: top > > krbTicketFlags: 3145856 > > managedBy: > fqdn=s4u.rhelent.lan,cn=computers,cn=accounts,dc=rhelent,dc=lan > > krbPrincipalName: HTTP/s4u.rhelent.lan at RHELENT.LAN > > ipaUniqueID: 3b563d36-88e0-11e5-917d-525400cab9fa > > krbLastPwdChange: 20151112021359Z > > krbExtraData:: AAIx3l1WYWRtaW4vYWRtaW5AUkhFTEVOVC5MQU4A > > krbLastSuccessfulAuth: 20151201175200Z > > > > Ticket flags clearly changed. Now to see if this works with ipa-web. > > > > > Thanks > > > > Marc Boorshtein > > CTO Tremolo Security > > marc.boorshtein at tremolosecurity.com > > (703) 828-4902 > > > > > > On Tue, Dec 1, 2015 at 12:42 PM, Simo Sorce wrote: > > > On Tue, 2015-12-01 at 11:55 -0500, Marc Boorshtein wrote: > > >> > > > >> > How do you acquire the user ticket ? > > >> > > > >> > > >> Using a keytab. Here's a link to the example code I'm using: > > >> https://github.com/ymartin59/java-kerberos-sfudemo I have Java set > to > > >> use IPA as the DNS server and I'm passing in mmosley as the user to > > >> impersonate and HTTP/freeipa.rhelent.lan as the service that will > > >> consume the impersonated user's ticket. > > >> > > >> > Do you have the kdc log (/var/log/krb5kdc.log) that shows what the > > >> > server has been requested and what it released ? > > >> > > > >> > > >> Sure: > > >> > > >> Dec 01 11:55:17 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 > > >> etypes {17 23 16}) 10.8.0.2: NEEDED_PREAUTH: > > >> HTTP/s4u.rhelent.lan at RHELENT.LAN for krbtgt/RHELENT.LAN at RHELENT.LAN, > > >> Additional pre-authentication required > > >> Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 > > >> etypes {17 23 16}) 10.8.0.2: ISSUE: authtime 1448988918, etypes > > >> {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for > > >> krbtgt/RHELENT.LAN at RHELENT.LAN > > >> Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (3 > > >> etypes {17 23 16}) 10.8.0.2: ISSUE: authtime 1448988918, etypes > > >> {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for > > >> HTTP/s4u.rhelent.lan at RHELENT.LAN > > >> Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): ... > > >> PROTOCOL-TRANSITION s4u-client=mmosley at RHELENT.LAN > > >> > > >> Thanks > > > > > > I think for s4u2self you may have missed a conf step (we primarily use > > > s4u2proxy in the product *without* any s4u2self step). > > > > > > Can you check that you followed the procedure described here: > > > > https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-kdb/README.s4u2proxy.txt#n90 > > > > > > I think they key part is setting the +ok_to_auth_as_delegate flag which > > > we do not provide an official higher level interface for yet. > > > > > > Simo. > > > > > > -- > > > Simo Sorce * Red Hat, Inc * New York > > > > > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Dec 1 18:39:36 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 1 Dec 2015 13:39:36 -0500 Subject: [Freeipa-users] Documentation on the JSON format for ipa-web? In-Reply-To: References: Message-ID: <565DE968.30007@redhat.com> Marc Boorshtein wrote: > FreeIPA Team, > > I've created a plugin for working with freeipa, but right now its > using reverse engineered JSON that I then turned into Java POJOs. It > works but I'd like to have something a bit better managed. Is there > any documentation or a place in the code base I can look for a more > formal definition of the JSON so I can build a better mapping? > IPA 4.2 has an experimental API browser in the GUI, IPA Server -> API browser. rob From marc.boorshtein at tremolosecurity.com Tue Dec 1 18:41:06 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 1 Dec 2015 13:41:06 -0500 Subject: [Freeipa-users] Documentation on the JSON format for ipa-web? In-Reply-To: <565DE968.30007@redhat.com> References: <565DE968.30007@redhat.com> Message-ID: > > IPA 4.2 has an experimental API browser in the GUI, IPA Server -> API > browser. > has 4.2 made it into centos 7 yet? or only in fedora? From rcritten at redhat.com Tue Dec 1 18:42:37 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 1 Dec 2015 13:42:37 -0500 Subject: [Freeipa-users] Documentation on the JSON format for ipa-web? In-Reply-To: References: <565DE968.30007@redhat.com> Message-ID: <565DEA1D.3030001@redhat.com> Marc Boorshtein wrote: >> >> IPA 4.2 has an experimental API browser in the GUI, IPA Server -> API >> browser. >> > > has 4.2 made it into centos 7 yet? or only in fedora? > It is in RHEL 7.2 and Fedora 23. rob From simo at redhat.com Tue Dec 1 18:46:26 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 01 Dec 2015 13:46:26 -0500 Subject: [Freeipa-users] IPA + Java 8 + S4U2Self/Proxy In-Reply-To: References: <562FCD54.2080702@redhat.com> <562FDAAF.3050609@redhat.com> <1448988575.9040.7.camel@redhat.com> <1448991744.9040.11.camel@redhat.com> <1448993650.9040.14.camel@redhat.com> Message-ID: <1448995586.9040.15.camel@redhat.com> On Tue, 2015-12-01 at 13:28 -0500, Marc Boorshtein wrote: > Got it. BTW, with that java 8 s4u2self works too. Thanks again for the help! Glad it works, and sorry it took so long to figure out. We definitely need some better docs around this point. Simo. > Marc Boorshtein > CTO, Tremolo Security, Inc. > On Dec 1, 2015 1:14 PM, "Simo Sorce" wrote: > > > On Tue, 2015-12-01 at 12:55 -0500, Marc Boorshtein wrote: > > > I can now get a ticket! This is how I originally created the user: > > > > > > $ kinit admin > > > $ ipa service-add HTTP/s4u.rhelent.lan at rhelent.lan --ok-as-delegate=true > > > > ok-as-delegate != ok_to_auth_as_delegate ... > > > > I know, it is a little confusing :-/ but these are the upstream flag > > names, and they both exist and do different things. > > > > Simo. > > > > > Here's the object in the directory: > > > > > > dn: krbprincipalname=HTTP/s4u.rhelent.lan at RHELENT.LAN > > ,cn=services,cn=accounts, > > > dc=rhelent,dc=lan > > > ipaKrbPrincipalAlias: HTTP/s4u.rhelent.lan at RHELENT.LAN > > > objectClass: ipaobject > > > objectClass: ipaservice > > > objectClass: krbticketpolicyaux > > > objectClass: ipakrbprincipal > > > objectClass: krbprincipal > > > objectClass: krbprincipalaux > > > objectClass: pkiuser > > > objectClass: top > > > krbTicketFlags: 1048704 > > > managedBy: > > fqdn=s4u.rhelent.lan,cn=computers,cn=accounts,dc=rhelent,dc=lan > > > krbPrincipalName: HTTP/s4u.rhelent.lan at RHELENT.LAN > > > ipaUniqueID: 3b563d36-88e0-11e5-917d-525400cab9fa > > > krbLastPwdChange: 20151112021359Z > > > krbExtraData:: AALn9UNWSFRUUC9zNHUucmhlbGVudC5sYW5AUkhFTEVOVC5MQU4A > > > krbLastSuccessfulAuth: 20151201165518Z > > > > > > Just now, I ran: > > > [root at freeipa ~]# kadmin.local > > > Authenticating as principal admin/admin at RHELENT.LAN with password. > > > kadmin.local: modprinc +ok_to_auth_as_delegate HTTP/s4u.rhelent.lan > > > Principal "HTTP/s4u.rhelent.lan at RHELENT.LAN" modified. > > > > > > and now the directory object is > > > dn: krbprincipalname=HTTP/s4u.rhelent.lan at RHELENT.LAN > > ,cn=services,cn=accounts, > > > dc=rhelent,dc=lan > > > ipaKrbPrincipalAlias: HTTP/s4u.rhelent.lan at RHELENT.LAN > > > objectClass: ipaobject > > > objectClass: ipaservice > > > objectClass: krbticketpolicyaux > > > objectClass: ipakrbprincipal > > > objectClass: krbprincipal > > > objectClass: krbprincipalaux > > > objectClass: pkiuser > > > objectClass: top > > > krbTicketFlags: 3145856 > > > managedBy: > > fqdn=s4u.rhelent.lan,cn=computers,cn=accounts,dc=rhelent,dc=lan > > > krbPrincipalName: HTTP/s4u.rhelent.lan at RHELENT.LAN > > > ipaUniqueID: 3b563d36-88e0-11e5-917d-525400cab9fa > > > krbLastPwdChange: 20151112021359Z > > > krbExtraData:: AAIx3l1WYWRtaW4vYWRtaW5AUkhFTEVOVC5MQU4A > > > krbLastSuccessfulAuth: 20151201175200Z > > > > > > Ticket flags clearly changed. Now to see if this works with ipa-web. > > > > > > > > > Thanks > > > > > > Marc Boorshtein > > > CTO Tremolo Security > > > marc.boorshtein at tremolosecurity.com > > > (703) 828-4902 > > > > > > > > > On Tue, Dec 1, 2015 at 12:42 PM, Simo Sorce wrote: > > > > On Tue, 2015-12-01 at 11:55 -0500, Marc Boorshtein wrote: > > > >> > > > > >> > How do you acquire the user ticket ? > > > >> > > > > >> > > > >> Using a keytab. Here's a link to the example code I'm using: > > > >> https://github.com/ymartin59/java-kerberos-sfudemo I have Java set > > to > > > >> use IPA as the DNS server and I'm passing in mmosley as the user to > > > >> impersonate and HTTP/freeipa.rhelent.lan as the service that will > > > >> consume the impersonated user's ticket. > > > >> > > > >> > Do you have the kdc log (/var/log/krb5kdc.log) that shows what the > > > >> > server has been requested and what it released ? > > > >> > > > > >> > > > >> Sure: > > > >> > > > >> Dec 01 11:55:17 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 > > > >> etypes {17 23 16}) 10.8.0.2: NEEDED_PREAUTH: > > > >> HTTP/s4u.rhelent.lan at RHELENT.LAN for krbtgt/RHELENT.LAN at RHELENT.LAN, > > > >> Additional pre-authentication required > > > >> Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 > > > >> etypes {17 23 16}) 10.8.0.2: ISSUE: authtime 1448988918, etypes > > > >> {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for > > > >> krbtgt/RHELENT.LAN at RHELENT.LAN > > > >> Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (3 > > > >> etypes {17 23 16}) 10.8.0.2: ISSUE: authtime 1448988918, etypes > > > >> {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for > > > >> HTTP/s4u.rhelent.lan at RHELENT.LAN > > > >> Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): ... > > > >> PROTOCOL-TRANSITION s4u-client=mmosley at RHELENT.LAN > > > >> > > > >> Thanks > > > > > > > > I think for s4u2self you may have missed a conf step (we primarily use > > > > s4u2proxy in the product *without* any s4u2self step). > > > > > > > > Can you check that you followed the procedure described here: > > > > > > https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-kdb/README.s4u2proxy.txt#n90 > > > > > > > > I think they key part is setting the +ok_to_auth_as_delegate flag which > > > > we do not provide an official higher level interface for yet. > > > > > > > > Simo. > > > > > > > > -- > > > > Simo Sorce * Red Hat, Inc * New York > > > > > > > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > > > -- Simo Sorce * Red Hat, Inc * New York From marc.boorshtein at tremolosecurity.com Tue Dec 1 18:49:15 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 1 Dec 2015 13:49:15 -0500 Subject: [Freeipa-users] IPA + Java 8 + S4U2Self/Proxy In-Reply-To: <1448995586.9040.15.camel@redhat.com> References: <562FCD54.2080702@redhat.com> <562FDAAF.3050609@redhat.com> <1448988575.9040.7.camel@redhat.com> <1448991744.9040.11.camel@redhat.com> <1448993650.9040.14.camel@redhat.com> <1448995586.9040.15.camel@redhat.com> Message-ID: What projects (including my own) doesn't need better docs? :-) Once I publish the work I'm doing part of that will have a step-by-step on getting this setup. It was pretty easy really if you are comfortable with LDAP. Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 On Tue, Dec 1, 2015 at 1:46 PM, Simo Sorce wrote: > On Tue, 2015-12-01 at 13:28 -0500, Marc Boorshtein wrote: >> Got it. BTW, with that java 8 s4u2self works too. Thanks again for the help! > > Glad it works, and sorry it took so long to figure out. > > We definitely need some better docs around this point. > > Simo. > >> Marc Boorshtein >> CTO, Tremolo Security, Inc. >> On Dec 1, 2015 1:14 PM, "Simo Sorce" wrote: >> >> > On Tue, 2015-12-01 at 12:55 -0500, Marc Boorshtein wrote: >> > > I can now get a ticket! This is how I originally created the user: >> > > >> > > $ kinit admin >> > > $ ipa service-add HTTP/s4u.rhelent.lan at rhelent.lan --ok-as-delegate=true >> > >> > ok-as-delegate != ok_to_auth_as_delegate ... >> > >> > I know, it is a little confusing :-/ but these are the upstream flag >> > names, and they both exist and do different things. >> > >> > Simo. >> > >> > > Here's the object in the directory: >> > > >> > > dn: krbprincipalname=HTTP/s4u.rhelent.lan at RHELENT.LAN >> > ,cn=services,cn=accounts, >> > > dc=rhelent,dc=lan >> > > ipaKrbPrincipalAlias: HTTP/s4u.rhelent.lan at RHELENT.LAN >> > > objectClass: ipaobject >> > > objectClass: ipaservice >> > > objectClass: krbticketpolicyaux >> > > objectClass: ipakrbprincipal >> > > objectClass: krbprincipal >> > > objectClass: krbprincipalaux >> > > objectClass: pkiuser >> > > objectClass: top >> > > krbTicketFlags: 1048704 >> > > managedBy: >> > fqdn=s4u.rhelent.lan,cn=computers,cn=accounts,dc=rhelent,dc=lan >> > > krbPrincipalName: HTTP/s4u.rhelent.lan at RHELENT.LAN >> > > ipaUniqueID: 3b563d36-88e0-11e5-917d-525400cab9fa >> > > krbLastPwdChange: 20151112021359Z >> > > krbExtraData:: AALn9UNWSFRUUC9zNHUucmhlbGVudC5sYW5AUkhFTEVOVC5MQU4A >> > > krbLastSuccessfulAuth: 20151201165518Z >> > > >> > > Just now, I ran: >> > > [root at freeipa ~]# kadmin.local >> > > Authenticating as principal admin/admin at RHELENT.LAN with password. >> > > kadmin.local: modprinc +ok_to_auth_as_delegate HTTP/s4u.rhelent.lan >> > > Principal "HTTP/s4u.rhelent.lan at RHELENT.LAN" modified. >> > > >> > > and now the directory object is >> > > dn: krbprincipalname=HTTP/s4u.rhelent.lan at RHELENT.LAN >> > ,cn=services,cn=accounts, >> > > dc=rhelent,dc=lan >> > > ipaKrbPrincipalAlias: HTTP/s4u.rhelent.lan at RHELENT.LAN >> > > objectClass: ipaobject >> > > objectClass: ipaservice >> > > objectClass: krbticketpolicyaux >> > > objectClass: ipakrbprincipal >> > > objectClass: krbprincipal >> > > objectClass: krbprincipalaux >> > > objectClass: pkiuser >> > > objectClass: top >> > > krbTicketFlags: 3145856 >> > > managedBy: >> > fqdn=s4u.rhelent.lan,cn=computers,cn=accounts,dc=rhelent,dc=lan >> > > krbPrincipalName: HTTP/s4u.rhelent.lan at RHELENT.LAN >> > > ipaUniqueID: 3b563d36-88e0-11e5-917d-525400cab9fa >> > > krbLastPwdChange: 20151112021359Z >> > > krbExtraData:: AAIx3l1WYWRtaW4vYWRtaW5AUkhFTEVOVC5MQU4A >> > > krbLastSuccessfulAuth: 20151201175200Z >> > > >> > > Ticket flags clearly changed. Now to see if this works with ipa-web. >> > >> > >> > >> > > Thanks >> > > >> > > Marc Boorshtein >> > > CTO Tremolo Security >> > > marc.boorshtein at tremolosecurity.com >> > > (703) 828-4902 >> > > >> > > >> > > On Tue, Dec 1, 2015 at 12:42 PM, Simo Sorce wrote: >> > > > On Tue, 2015-12-01 at 11:55 -0500, Marc Boorshtein wrote: >> > > >> > >> > > >> > How do you acquire the user ticket ? >> > > >> > >> > > >> >> > > >> Using a keytab. Here's a link to the example code I'm using: >> > > >> https://github.com/ymartin59/java-kerberos-sfudemo I have Java set >> > to >> > > >> use IPA as the DNS server and I'm passing in mmosley as the user to >> > > >> impersonate and HTTP/freeipa.rhelent.lan as the service that will >> > > >> consume the impersonated user's ticket. >> > > >> >> > > >> > Do you have the kdc log (/var/log/krb5kdc.log) that shows what the >> > > >> > server has been requested and what it released ? >> > > >> > >> > > >> >> > > >> Sure: >> > > >> >> > > >> Dec 01 11:55:17 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 >> > > >> etypes {17 23 16}) 10.8.0.2: NEEDED_PREAUTH: >> > > >> HTTP/s4u.rhelent.lan at RHELENT.LAN for krbtgt/RHELENT.LAN at RHELENT.LAN, >> > > >> Additional pre-authentication required >> > > >> Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 >> > > >> etypes {17 23 16}) 10.8.0.2: ISSUE: authtime 1448988918, etypes >> > > >> {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for >> > > >> krbtgt/RHELENT.LAN at RHELENT.LAN >> > > >> Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (3 >> > > >> etypes {17 23 16}) 10.8.0.2: ISSUE: authtime 1448988918, etypes >> > > >> {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for >> > > >> HTTP/s4u.rhelent.lan at RHELENT.LAN >> > > >> Dec 01 11:55:18 freeipa.rhelent.lan krb5kdc[7507](info): ... >> > > >> PROTOCOL-TRANSITION s4u-client=mmosley at RHELENT.LAN >> > > >> >> > > >> Thanks >> > > > >> > > > I think for s4u2self you may have missed a conf step (we primarily use >> > > > s4u2proxy in the product *without* any s4u2self step). >> > > > >> > > > Can you check that you followed the procedure described here: >> > > > >> > https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-kdb/README.s4u2proxy.txt#n90 >> > > > >> > > > I think they key part is setting the +ok_to_auth_as_delegate flag which >> > > > we do not provide an official higher level interface for yet. >> > > > >> > > > Simo. >> > > > >> > > > -- >> > > > Simo Sorce * Red Hat, Inc * New York >> > > > >> > >> > >> > -- >> > Simo Sorce * Red Hat, Inc * New York >> > >> > > > > -- > Simo Sorce * Red Hat, Inc * New York > From marc.boorshtein at tremolosecurity.com Tue Dec 1 18:56:37 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 1 Dec 2015 13:56:37 -0500 Subject: [Freeipa-users] Documentation on the JSON format for ipa-web? In-Reply-To: <565DEA1D.3030001@redhat.com> References: <565DE968.30007@redhat.com> <565DEA1D.3030001@redhat.com> Message-ID: Great. Doesn't look like its made it into CentOS yet (still at 7.1). OK, going to go ahead and get it running on Fedora 23. Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 On Tue, Dec 1, 2015 at 1:42 PM, Rob Crittenden wrote: > Marc Boorshtein wrote: >>> >>> IPA 4.2 has an experimental API browser in the GUI, IPA Server -> API >>> browser. >>> >> >> has 4.2 made it into centos 7 yet? or only in fedora? >> > > It is in RHEL 7.2 and Fedora 23. > > rob From mbabinsk at redhat.com Wed Dec 2 07:53:53 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 2 Dec 2015 08:53:53 +0100 Subject: [Freeipa-users] Documentation on the JSON format for ipa-web? In-Reply-To: References: <565DE968.30007@redhat.com> <565DEA1D.3030001@redhat.com> Message-ID: <565EA391.9030009@redhat.com> On 12/01/2015 07:56 PM, Marc Boorshtein wrote: > Great. Doesn't look like its made it into CentOS yet (still at 7.1). > OK, going to go ahead and get it running on Fedora 23. > > Thanks > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > (703) 828-4902 > > > On Tue, Dec 1, 2015 at 1:42 PM, Rob Crittenden wrote: >> Marc Boorshtein wrote: >>>> >>>> IPA 4.2 has an experimental API browser in the GUI, IPA Server -> API >>>> browser. >>>> >>> >>> has 4.2 made it into centos 7 yet? or only in fedora? >>> >> >> It is in RHEL 7.2 and Fedora 23. >> >> rob > Hi Marc, the FreeIPA public demo also features an API browser for you to inspect. See http://www.freeipa.org/page/Demo and then go to https://ipa.demo1.freeipa.org/ipa/ui/#/p/apibrowser/type=command -- Martin^3 Babinsky From ftweedal at redhat.com Wed Dec 2 11:10:31 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 2 Dec 2015 21:10:31 +1000 Subject: [Freeipa-users] FreeIPA and LetsEncrypt Question In-Reply-To: <20151130124613.GD9605@redhat.com> References: <2188056.Z0q5x72BSD@techz> <20151130124613.GD9605@redhat.com> Message-ID: <20151202111031.GT23644@dhcp-40-8.bne.redhat.com> On Mon, Nov 30, 2015 at 02:46:13PM +0200, Alexander Bokovoy wrote: > On Mon, 30 Nov 2015, G?nther J. Niederwimmer wrote: > >Hello , > > > >I have the question, know any from the FreeIPA "Gurus" ;-), are the new > >upcoming LetsEncrypt Certificates compatible and working with FreeIPA? > We have plans to support issuing certificates via Let's Encrypt. > G?nther, what are your specific wishes - to automatically acquire LE certs for FreeIPA server's HTTP and LDAP? Arbitrary hosts or services that are managed by FreeIPA? > However, right now Let's encrypt only issues server certificates, not > CA roots, so you cannot use them to bootstrap IPA CA. > This will probably always be the case. Cheers, Fraser > -- > / 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 From prasun.gera at gmail.com Tue Dec 1 23:18:51 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Tue, 1 Dec 2015 15:18:51 -0800 Subject: [Freeipa-users] FreeIPA and LetsEncrypt Question In-Reply-To: <20151130124613.GD9605@redhat.com> References: <2188056.Z0q5x72BSD@techz> <20151130124613.GD9605@redhat.com> Message-ID: Have a look at a recent thread that I had started. You might be able to do it manually for http/ldap certs. However, there were some issues which I haven't figured out yet. You might have better luck. Anyone should be able to try it out given that LE enters public beta in a couple of days. On Mon, Nov 30, 2015 at 4:46 AM, Alexander Bokovoy wrote: > On Mon, 30 Nov 2015, G?nther J. Niederwimmer wrote: > >> Hello , >> >> I have the question, know any from the FreeIPA "Gurus" ;-), are the new >> upcoming LetsEncrypt Certificates compatible and working with FreeIPA? >> > We have plans to support issuing certificates via Let's Encrypt. > > However, right now Let's encrypt only issues server certificates, not > CA roots, so you cannot use them to bootstrap IPA CA. > -- > / 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.boorshtein at tremolosecurity.com Wed Dec 2 14:02:00 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Wed, 2 Dec 2015 09:02:00 -0500 Subject: [Freeipa-users] Documentation on the JSON format for ipa-web? In-Reply-To: <565EA391.9030009@redhat.com> References: <565DE968.30007@redhat.com> <565DEA1D.3030001@redhat.com> <565EA391.9030009@redhat.com> Message-ID: Rob & Martin, Thanks. This is a great resource. Is there a way to generate sample JSONs for each command? For instance, when I make a call to user_search, I use the following: String lookupjson = "{\"method\":\"batch\",\"params\":[[{\"method\":\"user_show\",\"params\":[[\"" + userID + "\"],{\"all\":true,\"rights\":true}]},{\"method\":\"pwpolicy_show\",\"params\":[[],{\"user\":\"" + userID + "\",\"all\":true,\"rights\":true}]},{\"method\":\"krbtpolicy_show\",\"params\":[[\"" + userID + "\"],{\"all\":true,\"rights\":true}]}],{\"version\":\"2.112\"}]}"; This was figured out by reverse engineering the calls from the browser to IPA Web. Looking at the API browser its clear that using batch here is probably overkill. Based on the api browser I think I can do: { "method":"user_show", "params":[ ["myuser"], { "all":true, "rights":true } ] } Is that accurate? For the result object, is there something documented? Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 On Wed, Dec 2, 2015 at 2:53 AM, Martin Babinsky wrote: > On 12/01/2015 07:56 PM, Marc Boorshtein wrote: >> >> Great. Doesn't look like its made it into CentOS yet (still at 7.1). >> OK, going to go ahead and get it running on Fedora 23. >> >> Thanks >> Marc Boorshtein >> CTO Tremolo Security >> marc.boorshtein at tremolosecurity.com >> (703) 828-4902 >> >> >> On Tue, Dec 1, 2015 at 1:42 PM, Rob Crittenden >> wrote: >>> >>> Marc Boorshtein wrote: >>>>> >>>>> >>>>> IPA 4.2 has an experimental API browser in the GUI, IPA Server -> API >>>>> browser. >>>>> >>>> >>>> has 4.2 made it into centos 7 yet? or only in fedora? >>>> >>> >>> It is in RHEL 7.2 and Fedora 23. >>> >>> rob >> >> > > Hi Marc, > > the FreeIPA public demo also features an API browser for you to inspect. See > http://www.freeipa.org/page/Demo and then go to > https://ipa.demo1.freeipa.org/ipa/ui/#/p/apibrowser/type=command > > -- > Martin^3 Babinsky > > -- > 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 From abokovoy at redhat.com Wed Dec 2 14:06:33 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 2 Dec 2015 16:06:33 +0200 Subject: [Freeipa-users] Documentation on the JSON format for ipa-web? In-Reply-To: References: <565DE968.30007@redhat.com> <565DEA1D.3030001@redhat.com> <565EA391.9030009@redhat.com> Message-ID: <20151202140633.GA8374@redhat.com> On Wed, 02 Dec 2015, Marc Boorshtein wrote: >Rob & Martin, > >Thanks. This is a great resource. Is there a way to generate sample >JSONs for each command? For instance, when I make a call to >user_search, I use the following: > >String lookupjson = >"{\"method\":\"batch\",\"params\":[[{\"method\":\"user_show\",\"params\":[[\"" >+ userID + "\"],{\"all\":true,\"rights\":true}]},{\"method\":\"pwpolicy_show\",\"params\":[[],{\"user\":\"" >+ userID + "\",\"all\":true,\"rights\":true}]},{\"method\":\"krbtpolicy_show\",\"params\":[[\"" >+ userID + "\"],{\"all\":true,\"rights\":true}]}],{\"version\":\"2.112\"}]}"; > >This was figured out by reverse engineering the calls from the browser >to IPA Web. Looking at the API browser its clear that using batch >here is probably overkill. Based on the api browser I think I can do: > >{ > "method":"user_show", > "params":[ > ["myuser"], > { > "all":true, > "rights":true > } > ] >} > >Is that accurate? For the result object, is there something documented? just use 'ipa -vv user-show ...' to see formatted JSON. Did you read my article? https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ -- / Alexander Bokovoy From marc.boorshtein at tremolosecurity.com Wed Dec 2 14:09:34 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Wed, 2 Dec 2015 09:09:34 -0500 Subject: [Freeipa-users] Documentation on the JSON format for ipa-web? In-Reply-To: <20151202140633.GA8374@redhat.com> References: <565DE968.30007@redhat.com> <565DEA1D.3030001@redhat.com> <565EA391.9030009@redhat.com> <20151202140633.GA8374@redhat.com> Message-ID: > > just use 'ipa -vv user-show ...' to see formatted JSON. > excellent > Did you read my article? > https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ > > I hadn't, but this is exactly what I'm looking for. Perfect, this will help me clean up my implementation nicely. Thanks Marc From gjn at gjn.priv.at Wed Dec 2 14:25:09 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Wed, 02 Dec 2015 15:25:09 +0100 Subject: [Freeipa-users] FreeIPA and LetsEncrypt Question In-Reply-To: <20151202111031.GT23644@dhcp-40-8.bne.redhat.com> References: <2188056.Z0q5x72BSD@techz> <20151130124613.GD9605@redhat.com> <20151202111031.GT23644@dhcp-40-8.bne.redhat.com> Message-ID: <8476866.qmAgtZyVTT@techz> Hello All, Am Wednesday 02 December 2015, 21:10:31 schrieb Fraser Tweedale: > On Mon, Nov 30, 2015 at 02:46:13PM +0200, Alexander Bokovoy wrote: > > On Mon, 30 Nov 2015, G?nther J. Niederwimmer wrote: > > >Hello , > > > > > >I have the question, know any from the FreeIPA "Gurus" ;-), are the new > > >upcoming LetsEncrypt Certificates compatible and working with FreeIPA? > > > > We have plans to support issuing certificates via Let's Encrypt. > > G?nther, what are your specific wishes - to automatically acquire LE > certs for FreeIPA server's HTTP and LDAP? Arbitrary hosts or > services that are managed by FreeIPA? My wishes :-)). when I can have wishes, I mean all ;-) But I nice Integration for IMAP, SMTP, LDAP, HTTPS ... was a dream. Now I make a test with FreeIPA and "DANE" I hope this is working ?. > > However, right now Let's encrypt only issues server certificates, not > > CA roots, so you cannot use them to bootstrap IPA CA. > > This will probably always be the case. > > Cheers, > Fraser -- mit freundlichen Gr??en / best regards, G?nther J. Niederwimmer From Andy.Thompson at e-tcc.com Wed Dec 2 15:47:59 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Wed, 2 Dec 2015 15:47:59 +0000 Subject: [Freeipa-users] backup/restore best practices Message-ID: <2e99ce43962840a686f27c7bbe8bae77@TCCCORPEXCH02.TCC.local> What does everyone do for backup/restore of their IPA infrastructure? I've read over the backup and restore on freeipa.org just want some real world application out there. Right now all of our backups are done at the SAN level. We snap the SAN aggregate containing the VMs and have those snaps available to roll back to. I'm not sure how consistent those backups might end up being at the end of the day and I've never had to roll back in the environment to test or have an environment to test on that level. -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** From oliver at doerr-privat.de Wed Dec 2 18:57:04 2015 From: oliver at doerr-privat.de (=?UTF-8?Q?Oliver_D=c3=b6rr?=) Date: Wed, 2 Dec 2015 19:57:04 +0100 Subject: [Freeipa-users] Documentation on the JSON format for ipa-web? In-Reply-To: References: <565DE968.30007@redhat.com> Message-ID: <565F3F00.8010701@doerr-privat.de> Hmm, I've made a few tests against JSON API and the API browser was available. I've used RHEL 7.2 and so I expect CentOS 7.2 contaning the API browser. Oliver Am 01.12.2015 um 19:41 schrieb Marc Boorshtein: >> IPA 4.2 has an experimental API browser in the GUI, IPA Server -> API >> browser. >> > has 4.2 made it into centos 7 yet? or only in fedora? > From marc.boorshtein at tremolosecurity.com Wed Dec 2 19:17:42 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Wed, 2 Dec 2015 14:17:42 -0500 Subject: [Freeipa-users] Documentation on the JSON format for ipa-web? In-Reply-To: <565F3F00.8010701@doerr-privat.de> References: <565DE968.30007@redhat.com> <565F3F00.8010701@doerr-privat.de> Message-ID: I did an upgrade yesterday and was still at 7.1 so i don't think 7.2 has been officially released. Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 On Wed, Dec 2, 2015 at 1:57 PM, Oliver D?rr wrote: > Hmm, > > I've made a few tests against JSON API and the API browser was available. > I've used RHEL 7.2 and so I expect CentOS 7.2 contaning the API browser. > > Oliver > > > Am 01.12.2015 um 19:41 schrieb Marc Boorshtein: >>> >>> IPA 4.2 has an experimental API browser in the GUI, IPA Server -> API >>> browser. >>> >> has 4.2 made it into centos 7 yet? or only in fedora? >> > > -- > 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 From Andy.Thompson at e-tcc.com Wed Dec 2 20:42:47 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Wed, 2 Dec 2015 20:42:47 +0000 Subject: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system Message-ID: Since updating to RHEL 7.2 I've got issues with ns-slapd hanging the system up after a period of time. The directory becomes unresponsive to searches or any connections. After a restart I see [02/Dec/2015:15:27:41 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [02/Dec/2015:15:27:41 -0500] - Listening on All Interfaces port 636 for LDAPS requests [02/Dec/2015:15:27:41 -0500] - Listening on /var/run/slapd-MHBENP-LIN.socket for LDAPI requests [02/Dec/2015:15:27:44 -0500] NSMMReplicationPlugin - agmt="cn=meTomdhixnpipa02.mhbenp.lin" (mdhixnpipa02:389): Replication bind with GSSAPI auth resumed [02/Dec/2015:15:27:47 -0500] NSMMReplicationPlugin - replication keep alive entry already exists In the logs and occasionally the keepalive entry message is seen a few times and then eventually the ns-slapd taps the system. 100% util, system load crawls up between 30 and 40 and eventually I have to restart the service to get it to respond again. Memory usage is normal, db and entry cache is sufficient.. possibly a little on the high side but resource is sitting there asking to be used :) Running 389-ds-base-1.3.4.0-19.el7.x86_64 after the update yesterday. What additional information can I provide? -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** From abokovoy at redhat.com Wed Dec 2 21:02:09 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 2 Dec 2015 23:02:09 +0200 Subject: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system In-Reply-To: References: Message-ID: <20151202210209.GD8374@redhat.com> On Wed, 02 Dec 2015, Andy Thompson wrote: >Since updating to RHEL 7.2 I've got issues with ns-slapd hanging the >system up after a period of time. The directory becomes unresponsive >to searches or any connections. After a restart I see > >[02/Dec/2015:15:27:41 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests >[02/Dec/2015:15:27:41 -0500] - Listening on All Interfaces port 636 for LDAPS requests >[02/Dec/2015:15:27:41 -0500] - Listening on /var/run/slapd-MHBENP-LIN.socket for LDAPI requests >[02/Dec/2015:15:27:44 -0500] NSMMReplicationPlugin - agmt="cn=meTomdhixnpipa02.mhbenp.lin" (mdhixnpipa02:389): Replication bind with GSSAPI auth resumed >[02/Dec/2015:15:27:47 -0500] NSMMReplicationPlugin - replication keep alive entry already exists > >In the logs and occasionally the keepalive entry message is seen a few times and then eventually the ns-slapd taps the system. 100% util, system load crawls up between 30 and 40 and eventually I have to restart the service to get it to respond again. Memory usage is normal, db and entry cache is sufficient.. possibly a little on the high side but resource is sitting there asking to be used :) > >Running 389-ds-base-1.3.4.0-19.el7.x86_64 after the update yesterday. > >What additional information can I provide? install debuginfo for 389-ds-base and slapi-nis, and take a pstack output for ns-slapd pid. -- / Alexander Bokovoy From schogan at us.ibm.com Wed Dec 2 22:20:27 2015 From: schogan at us.ibm.com (Sean Hogan) Date: Wed, 2 Dec 2015 15:20:27 -0700 Subject: [Freeipa-users] Sudo question Message-ID: <201512022220.tB2MKecd023463@d03av03.boulder.ibm.com> Hi All, I have a significant amount of time on this and hoping some of you might have an idea. I want to limit user bob from getting to a root prompt on this test box. It seems to work until bob is able to run a command he is allowed via sudo such as cat. Sudo -i is on the deny command list in IPA and root is local (not in IPA) with nsswitch pointing to files first then sss. So logged on as user bob, first thing attempted was sudo -i which produces wrong pw message even though it is the correct pw but it is denying so fine. Then I issue sudo cat /etc/sysconfig/iptables and it allows it after I enter bob's pw which is fine. However right after that I try sudo -i again and get root prompt which is not good. I am thinking since root is local and files first then once I sudo up root is avail. Any suggestions are welcome [me at mine ~]$ ssh bob at server bob at servers password: Last login: Time: from IP Internal systems must only be used for conducting company business or for purposes authorized by company management Use is subject to audit at any time by company management [bob at server ~]$ sudo -i [sudo] password for bob: Sorry, try again. [bob at server ~]$ sudo -i [sudo] password for bob: Sorry, try again. [sudo] password for bob: Sorry, try again. [sudo] password for bob: sudo: 2 incorrect password attempts [bob at server ~]$ sudo cat /etc/sysconfig/iptables [sudo] password for bob: # Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter [bob at server ~]$ sudo -i server.example.local:/root# cat /etc/sysconfig/iptables # Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter ipa sudorule-show bob Rule name: bob Description: test sudo rule for user bob Enabled: TRUE Host category: all Users: bob Sudo Allow Commands: /sbin/iptables, /sbin/service, /bin/view, /bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat Sudo Deny Commands: /usr/bin/sudo -i, /usr/bin/sudo-i, /usr/bin/sudo -u root -i Is it just me or is white space ignored as well with sudo commands much like the sudo options? Sean Hogan Security Engineer Watson Security & Risk Assurance Watson Cloud Technology and Support email: schogan at us.ibm.com | Tel 919 486 1397 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0B986619.jpg Type: image/jpeg Size: 27085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0B213315.gif Type: image/gif Size: 1650 bytes Desc: not available URL: From rcritten at redhat.com Wed Dec 2 23:26:16 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 2 Dec 2015 18:26:16 -0500 Subject: [Freeipa-users] Sudo question In-Reply-To: <201512022220.tB2MKecd023463@d03av03.boulder.ibm.com> References: <201512022220.tB2MKecd023463@d03av03.boulder.ibm.com> Message-ID: <565F7E18.4060009@redhat.com> Sean Hogan wrote: > Hi All, > > I have a significant amount of time on this and hoping some of you might > have an idea. I want to limit user bob from getting to a root prompt on > this test box. > It seems to work until bob is able to run a command he is allowed via > sudo such as cat. Sudo -i is on the deny command list in IPA and root is > local(not in IPA) with > nsswitch pointing to files first then sss. > > So logged on as user bob, first thing attempted was sudo -i which > produces wrong pw message even though it is the correct pw but it is > denying so fine. Then I issue sudo cat /etc/sysconfig/iptables > and it allows it after I enter bob's pw which is fine. However right > after that I try sudo -i again and get root prompt which is not good. I > am thinking since root is local and files first then once I sudo up root > is avail. > Any suggestions are welcome I think you are better off using an HBAC rule to only grant sudo and not sudo -i. rob > > > > *[me at mine ~]$ ssh bob at server* > bob at servers password: > Last login: Time: from IP > Internal systems must only be used for conducting company business or > for purposes authorized by company management > Use is subject to audit at any time by company management > *[bob at server ~]$ sudo -i* > [sudo] password for bob: > Sorry, try again. > *[bob at server ~]$ sudo -i* > [sudo] password for bob: > Sorry, try again. > [sudo] password for bob: > Sorry, try again. > [sudo] password for bob: > sudo: 2 incorrect password attempts > *[bob at server ~]$ sudo cat /etc/sysconfig/iptables* > [sudo] password for bob: > # Firewall configuration written by system-config-firewall > # Manual customization of this file is not recommended. > *filter > *[bob at server ~]$ sudo -i* > *server.example.local:/root# cat /etc/sysconfig/iptables* > # Firewall configuration written by system-config-firewall > # Manual customization of this file is not recommended. > *filter > > > > ipa sudorule-show bob > Rule name: bob > Description: test sudo rule for user bob > Enabled: TRUE > Host category: all > Users: bob > Sudo Allow Commands: /sbin/iptables, /sbin/service, /bin/view, > /bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat > Sudo Deny Commands: /usr/bin/sudo -i, /usr/bin/sudo-i, /usr/bin/sudo -u > root -i > > Is it just me or is white space ignored as well with sudo commands much > like the sudo options? > > > > > > > Sean Hogan > Security Engineer > Watson Security & Risk Assurance > Watson Cloud Technology and Support > email: schogan at us.ibm.com | Tel 919 486 1397 > > > > > > > From pspacek at redhat.com Thu Dec 3 08:02:11 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 3 Dec 2015 09:02:11 +0100 Subject: [Freeipa-users] FreeIPA and LetsEncrypt Question In-Reply-To: <8476866.qmAgtZyVTT@techz> References: <2188056.Z0q5x72BSD@techz> <20151130124613.GD9605@redhat.com> <20151202111031.GT23644@dhcp-40-8.bne.redhat.com> <8476866.qmAgtZyVTT@techz> Message-ID: <565FF703.5050803@redhat.com> On 2.12.2015 15:25, G?nther J. Niederwimmer wrote: > Hello All, > > Am Wednesday 02 December 2015, 21:10:31 schrieb Fraser Tweedale: >> On Mon, Nov 30, 2015 at 02:46:13PM +0200, Alexander Bokovoy wrote: >>> On Mon, 30 Nov 2015, G?nther J. Niederwimmer wrote: >>>> Hello , >>>> >>>> I have the question, know any from the FreeIPA "Gurus" ;-), are the new >>>> upcoming LetsEncrypt Certificates compatible and working with FreeIPA? >>> >>> We have plans to support issuing certificates via Let's Encrypt. >> >> G?nther, what are your specific wishes - to automatically acquire LE >> certs for FreeIPA server's HTTP and LDAP? Arbitrary hosts or >> services that are managed by FreeIPA? > > My wishes :-)). > > when I can have wishes, I mean all ;-) > > But I nice Integration for IMAP, SMTP, LDAP, HTTPS ... was a dream. > > Now I make a test with FreeIPA and "DANE" I hope this is working ?. IPA allows you to DNSSEC-sign the domain, the rest is up to you. You have to create TLSA records for your certificates, put these into DNSSEC-signed domain and then get *clients* to respect them. In other words, IPA does nothing except DNSSEC-signing of DNS domains. >>> However, right now Let's encrypt only issues server certificates, not >>> CA roots, so you cannot use them to bootstrap IPA CA. >> >> This will probably always be the case. -- Petr^2 Spacek From wdh at dds.nl Thu Dec 3 08:03:34 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Thu, 3 Dec 2015 09:03:34 +0100 Subject: [Freeipa-users] compat tree refresh Message-ID: <565FF756.40909@dds.nl> An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Dec 3 08:03:53 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 3 Dec 2015 09:03:53 +0100 Subject: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system In-Reply-To: <20151202210209.GD8374@redhat.com> References: <20151202210209.GD8374@redhat.com> Message-ID: <565FF769.3010707@redhat.com> On 2.12.2015 22:02, Alexander Bokovoy wrote: > On Wed, 02 Dec 2015, Andy Thompson wrote: >> Since updating to RHEL 7.2 I've got issues with ns-slapd hanging the >> system up after a period of time. The directory becomes unresponsive >> to searches or any connections. After a restart I see >> >> [02/Dec/2015:15:27:41 -0500] - slapd started. Listening on All Interfaces >> port 389 for LDAP requests >> [02/Dec/2015:15:27:41 -0500] - Listening on All Interfaces port 636 for >> LDAPS requests >> [02/Dec/2015:15:27:41 -0500] - Listening on /var/run/slapd-MHBENP-LIN.socket >> for LDAPI requests >> [02/Dec/2015:15:27:44 -0500] NSMMReplicationPlugin - >> agmt="cn=meTomdhixnpipa02.mhbenp.lin" (mdhixnpipa02:389): Replication bind >> with GSSAPI auth resumed >> [02/Dec/2015:15:27:47 -0500] NSMMReplicationPlugin - replication keep alive >> entry already exists >> >> In the logs and occasionally the keepalive entry message is seen a few times >> and then eventually the ns-slapd taps the system. 100% util, system load >> crawls up between 30 and 40 and eventually I have to restart the service to >> get it to respond again. Memory usage is normal, db and entry cache is >> sufficient.. possibly a little on the high side but resource is sitting >> there asking to be used :) >> >> Running 389-ds-base-1.3.4.0-19.el7.x86_64 after the update yesterday. >> >> What additional information can I provide? > install debuginfo for 389-ds-base and slapi-nis, and take a pstack > output for ns-slapd pid. For detailed instructions please see http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug_hangs -- Petr^2 Spacek From ender at kofeina.net Thu Dec 3 10:52:17 2015 From: ender at kofeina.net (=?iso-8859-2?Q?=A3ukasz_Jaworski?=) Date: Thu, 3 Dec 2015 11:52:17 +0100 Subject: [Freeipa-users] Problem with ipa-csreplica reinitialize Message-ID: <8BAB19ED-DE92-4ABE-9982-83AA820316EA@kofeina.net> Hi, We have strange problems in our environment. After ipa-csreplica-manage re-initialize servers crash (it happens very often, after second or third try, all dc, and pki replication gone. I've reinstalled server and setup new replication). There aren't any information in logs. It looks like process stops without any notice. During ipa-csreplica-manage re-initialize server shows: Update in progress, 3 seconds elapsed Update succeeded but dirsrv is gone. ps -ax |grep dirsrv shows nothing. after start dirsrv, replication is broken: The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. some information about our setup: Fedora 23 (updated from 22) freeipa-server-4.1.4-4.fc22.x86_64 389-ds-base-1.3.4.4-1.fc22.x86_64 389-ds-base-libs-1.3.4.4-1.fc22.x86_64 krb5-server-1.13.2-7.fc22.x86_64 krb5-workstation-1.13.2-7.fc22.x86_64 krb5-pkinit-1.13.2-7.fc22.x86_64 krb5-libs-1.13.2-7.fc22.x86_64 Best regards, ?ukasz Jaworski Ender -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Dec 3 15:29:30 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 3 Dec 2015 10:29:30 -0500 Subject: [Freeipa-users] Sudo question In-Reply-To: <201512031516.tB3FGPp9011411@d01av04.pok.ibm.com> References: <201512022220.tB2MKecd023463@d03av03.boulder.ibm.com> <565F7E18.4060009@redhat.com> <201512031516.tB3FGPp9011411@d01av04.pok.ibm.com> Message-ID: <56605FDA.7050602@redhat.com> Sean Hogan wrote: > Hi Rob, > > Thanks for the suggestion. I think that is what I have though. The > sudorule applied for this user does not have sudo as an avail command > unless it picks up /usr/bin/sudo -u user -i which I was thinking would > only allow sudoing to user. > HBAC services I have for the user has sudo and no sudo -i. > Services > sshd > login > gdm > gdm-password > kdm > su > su-l > vsftpd > sudo > > Sudo Rule > *Sudo Allow Commands*: /sbin/iptables, /sbin/service, > /bin/view,/bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat > *Sudo Deny Commands*: /usr/bin/sudo -i, /usr/bin/sudo-i, /usr/bin/sudo > -u root -i > > Unfortunately I am really stumped on this one. You probably have the allow_all HBAC rule enabled. If sudo-i isn't allowed in HBAC then the pam service shouldn't be allowed at all. I'd suggest you bump up the sssd debug level to better see what is happening. rob > > > > > > Inactive hide details for Rob Crittenden ---12/02/2015 04:26:24 > PM---Sean Hogan wrote: > Hi All,Rob Crittenden ---12/02/2015 04:26:24 > PM---Sean Hogan wrote: > Hi All, > > From: Rob Crittenden > To: Sean Hogan/Durham/IBM at IBMUS, freeipa-users at redhat.com > Date: 12/02/2015 04:26 PM > Subject: Re: [Freeipa-users] Sudo question > > ------------------------------------------------------------------------ > > > > Sean Hogan wrote: >> Hi All, >> >> I have a significant amount of time on this and hoping some of you might >> have an idea. I want to limit user bob from getting to a root prompt on >> this test box. >> It seems to work until bob is able to run a command he is allowed via >> sudo such as cat. Sudo -i is on the deny command list in IPA and root is >> local(not in IPA) with >> nsswitch pointing to files first then sss. >> >> So logged on as user bob, first thing attempted was sudo -i which >> produces wrong pw message even though it is the correct pw but it is >> denying so fine. Then I issue sudo cat /etc/sysconfig/iptables >> and it allows it after I enter bob's pw which is fine. However right >> after that I try sudo -i again and get root prompt which is not good. I >> am thinking since root is local and files first then once I sudo up root >> is avail. >> Any suggestions are welcome > > I think you are better off using an HBAC rule to only grant sudo and not > sudo -i. > > rob > >> >> >> >> *[me at mine ~]$ ssh bob at server* >> bob at servers password: >> Last login: Time: from IP >> Internal systems must only be used for conducting company business or >> for purposes authorized by company management >> Use is subject to audit at any time by company management >> *[bob at server ~]$ sudo -i* >> [sudo] password for bob: >> Sorry, try again. >> *[bob at server ~]$ sudo -i* >> [sudo] password for bob: >> Sorry, try again. >> [sudo] password for bob: >> Sorry, try again. >> [sudo] password for bob: >> sudo: 2 incorrect password attempts >> *[bob at server ~]$ sudo cat /etc/sysconfig/iptables* >> [sudo] password for bob: >> # Firewall configuration written by system-config-firewall >> # Manual customization of this file is not recommended. >> *filter >> *[bob at server ~]$ sudo -i* >> *server.example.local:/root# cat /etc/sysconfig/iptables* >> # Firewall configuration written by system-config-firewall >> # Manual customization of this file is not recommended. >> *filter >> >> >> >> ipa sudorule-show bob >> Rule name: bob >> Description: test sudo rule for user bob >> Enabled: TRUE >> Host category: all >> Users: bob >> Sudo Allow Commands: /sbin/iptables, /sbin/service, /bin/view, >> /bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat >> Sudo Deny Commands: /usr/bin/sudo -i, /usr/bin/sudo-i, /usr/bin/sudo -u >> root -i >> >> Is it just me or is white space ignored as well with sudo commands much >> like the sudo options? >> >> >> >> >> >> >> Sean Hogan >> Security Engineer >> Watson Security & Risk Assurance >> Watson Cloud Technology and Support >> email: schogan at us.ibm.com | Tel 919 486 1397 >> >> >> >> >> >> >> > > > > From Andy.Thompson at e-tcc.com Thu Dec 3 15:33:26 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Thu, 3 Dec 2015 15:33:26 +0000 Subject: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system In-Reply-To: <565FF769.3010707@redhat.com> References: <20151202210209.GD8374@redhat.com> <565FF769.3010707@redhat.com> Message-ID: > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Petr Spacek > Sent: Thursday, December 3, 2015 3:04 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system > > On 2.12.2015 22:02, Alexander Bokovoy wrote: > > On Wed, 02 Dec 2015, Andy Thompson wrote: > >> Since updating to RHEL 7.2 I've got issues with ns-slapd hanging the > >> system up after a period of time. The directory becomes unresponsive > >> to searches or any connections. After a restart I see > >> > >> [02/Dec/2015:15:27:41 -0500] - slapd started. Listening on All > >> Interfaces port 389 for LDAP requests > >> [02/Dec/2015:15:27:41 -0500] - Listening on All Interfaces port 636 > >> for LDAPS requests > >> [02/Dec/2015:15:27:41 -0500] - Listening on > >> /var/run/slapd-MHBENP-LIN.socket for LDAPI requests > >> [02/Dec/2015:15:27:44 -0500] NSMMReplicationPlugin - > >> agmt="cn=meTomdhixnpipa02.mhbenp.lin" (mdhixnpipa02:389): > Replication > >> bind with GSSAPI auth resumed > >> [02/Dec/2015:15:27:47 -0500] NSMMReplicationPlugin - replication keep > >> alive entry already exists > >> > >> In the logs and occasionally the keepalive entry message is seen a > >> few times and then eventually the ns-slapd taps the system. 100% > >> util, system load crawls up between 30 and 40 and eventually I have > >> to restart the service to get it to respond again. Memory usage is > >> normal, db and entry cache is sufficient.. possibly a little on the > >> high side but resource is sitting there asking to be used :) > >> > >> Running 389-ds-base-1.3.4.0-19.el7.x86_64 after the update yesterday. > >> > >> What additional information can I provide? > > install debuginfo for 389-ds-base and slapi-nis, and take a pstack > > output for ns-slapd pid. > > For detailed instructions please see > http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug_hangs > Here is the resulting stacktrace during the last hang. -andy -------------- next part -------------- A non-text attachment was scrubbed... Name: stacktrace.1449156488.txt.gz Type: application/x-gzip Size: 12287 bytes Desc: stacktrace.1449156488.txt.gz URL: From rcritten at redhat.com Thu Dec 3 15:40:41 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 3 Dec 2015 10:40:41 -0500 Subject: [Freeipa-users] Problem with ipa-csreplica reinitialize In-Reply-To: <8BAB19ED-DE92-4ABE-9982-83AA820316EA@kofeina.net> References: <8BAB19ED-DE92-4ABE-9982-83AA820316EA@kofeina.net> Message-ID: <56606279.4090302@redhat.com> ?ukasz Jaworski wrote: > Hi, > > We have strange problems in our environment. > > After ipa-csreplica-manage re-initialize servers crash (it happens very > often, after second or third try, all dc, and pki replication gone. I've > reinstalled server and setup new replication). There aren't any > information in logs. It looks like process stops without any notice. > > During ipa-csreplica-manage re-initialize server shows: > > Update in progress, 3 seconds elapsed Update succeeded > > but dirsrv is gone. ps -ax |grep dirsrv shows nothing. > > after start dirsrv, replication is broken: The remote replica has a > different database generation ID than the local database. You may have > to reinitialize the remote replica, or the local replica. > > some information about our setup: Fedora 23 (updated from 22) > > freeipa-server-4.1.4-4.fc22.x86_64 389-ds-base-1.3.4.4-1.fc22.x86_64 > 389-ds-base-libs-1.3.4.4-1.fc22.x86_64 krb5-server-1.13.2-7.fc22.x86_64 > krb5-workstation-1.13.2-7.fc22.x86_64 krb5-pkinit-1.13.2-7.fc22.x86_64 > krb5-libs-1.13.2-7.fc22.x86_64 > > Best regards, ?ukasz Jaworski Ender > > > Install debuginfo for 389-ds-base and do another reinitialize and get a stack trace. See http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-crashes rob From rcritten at redhat.com Thu Dec 3 18:21:16 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 3 Dec 2015 13:21:16 -0500 Subject: [Freeipa-users] Sudo question In-Reply-To: <201512031713.tB3HDk65009814@d01av02.pok.ibm.com> References: <201512022220.tB2MKecd023463@d03av03.boulder.ibm.com> <565F7E18.4060009@redhat.com> <201512031516.tB3FGPp9011411@d01av04.pok.ibm.com> <56605FDA.7050602@redhat.com> <201512031713.tB3HDk65009814@d01av02.pok.ibm.com> Message-ID: <5660881C.10106@redhat.com> Sean Hogan wrote: > I had the log bumped to 8 and yes the allow_all HBAC rule is enabled > however not associated with this user at all. This test only allows this > user to hit 2 servers with individual HBAC rule to the 2 servers via the > services I provided earlier. > allow_all applies to everyone unless you've changed it. HBAC is deny by default so once allowed, always allowed. I'm not well-versed in the sssd logs so maybe one of those guys will chime in. rob > [bob at server ~]$ sudo -l > [sudo] password for bob: > Matching Defaults entries for bob on this host: > requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS > DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 > PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE > LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY > LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL > LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", > secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin, logfile=/var/log/sudo.log > > User bob may run the following commands on this host: > (root) !/usr/local/bin/sudo, !/usr/bin/sudo, !/bin/sudo > (root) /usr/bin/xclock > (root) /sbin/iptables, /sbin/service, /bin/vi, /bin/view, /usr/bin/vim, > /bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat, > !/usr/bin/sudo -i, !/usr/bin/sudo-i, !/usr/bin/sudo -u root -i > > > > sssd.conf > server.example.local:/var/log# cat /etc/sssd/sssd.conf > [domain/example.local] > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = example.local > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = server.example.local > chpass_provider = ipa > ipa_dyndns_update = True > ipa_server = _srv_, mastersrv.example.local > ldap_tls_cacert = /etc/ipa/ca.crt > [sssd] > services = nss, sudo, pam, ssh > config_file_version = 2 > debug_level = 8 > > domains = example.local > [nss] > homedir_substring = /home > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > [ifp] > > > Ran thru the commands again: > [me at mine ~]$ ssh bob at server > bob at server password: > Last login: Thu Dec 3 11:24:53 2015 from IP_ADDRESS > [bob at server ~]$ sudo -i > [sudo] password for bob: > Sorry, try again. > [sudo] password for bob: > sudo: 1 incorrect password attempt > [bob at server ~]$ sudo cat /etc/sysconfig/iptables > [sudo] password for bob: > # Firewall configuration written by system-config-firewall > # Manual customization of this file is not recommended. > *filter > [bob at server ~]$ sudo -i > server.example.local:/root# exit > > This is what the logs show for above conversations > Dec 3 11:49:52 server sshd[61682]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP_ADDRESS user=bob > Dec 3 11:49:53 server sshd[61682]: pam_sss(sshd:auth): authentication > success; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP_ADDRESS user=bob > Dec 3 11:49:53 server sshd[61682]: Accepted password for bob from > IP_ADDRESS port 50273 ssh2 > Dec 3 11:49:53 server sshd[61682]: pam_unix(sshd:session): session > opened for user bob by (uid=0) > Dec 3 11:49:53 server sshd[61682]: User child is on pid 61687 > > Attempt sudo -i which fails with bad pw but at least fails, PW is correct. > Dec 3 11:50:05 server sudo: pam_unix(sudo-i:auth): authentication > failure; logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob > rhost= user=bob > Dec 3 11:50:06 server sudo: pam_sss(sudo-i:auth): authentication > success; logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob > rhost= user=bob > Dec 3 11:50:06 server sudo: pam_sss(sudo-i:account): Access denied for > user bob: 6 (Permission denied) > Dec 3 11:50:11 server sudo: pam_unix(sudo-i:auth): conversation failed > Dec 3 11:50:11 server sudo: pam_unix(sudo-i:auth): auth could not > identify password for [bob] > Dec 3 11:50:11 server sudo: pam_sss(sudo-i:auth): authentication > failure; logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob > rhost= user=bob > Dec 3 11:50:11 server sudo: pam_sss(sudo-i:auth): received for user bob: > 7 (Authentication failure) > Dec 3 11:50:11 server sudo: bob : 1 incorrect password attempt ; > TTY=pts/2 ; PWD=/home/rusers/bob ; USER=root ; COMMAND=/bin/bash > > Cat /etc/syconfig/iptables which works after prompting for pw so good > Dec 3 11:50:42 server sudo: pam_unix(sudo:auth): authentication failure; > logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob rhost= user=bob > Dec 3 11:50:43 server sudo: pam_sss(sudo:auth): authentication success; > logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob rhost= user=bob > Dec 3 11:50:43 server sudo: bob : TTY=pts/2 ; PWD=/home/rusers/bob ; > USER=root ; COMMAND=/bin/cat /etc/sysconfig/iptables > > sudo -i now works even though it did not before > Dec 3 11:50:52 server sudo: bob : TTY=pts/2 ; PWD=/home/rusers/bob ; > USER=root ; COMMAND=/bin/bash > > > I expect the pam_unix fails as the accounts are not local.. I expect the > first set of fails for sudo -i even though its comes up a pw issue which > is not the case. I expect success when catting iptables which is good > but then sudo -i just works after that which is not expected. > > Client: > rpm -qa | grep ipa > python-iniparse-0.3.1-2.1.el6.noarch > libipa_hbac-python-1.11.6-30.el6_6.4.ppc64 > ipa-python-3.0.0-42.el6.ppc64 > libipa_hbac-1.11.6-30.el6_6.4.ppc64 > device-mapper-multipath-libs-0.4.9-80.el6_6.3.ppc64 > sssd-ipa-1.11.6-30.el6_6.4.ppc64 > ipa-client-3.0.0-42.el6.ppc64 > device-mapper-multipath-0.4.9-80.el6_6.3.ppc64 > > > Server: > rpm -qa | grep ipa > sssd-ipa-1.12.4-47.el6.x86_64 > ipa-admintools-3.0.0-47.el6.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > libipa_hbac-python-1.12.4-47.el6.x86_64 > ipa-client-3.0.0-47.el6.x86_64 > ipa-python-3.0.0-47.el6.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-server-selinux-3.0.0-47.el6.x86_64 > ipa-server-3.0.0-47.el6.x86_64 > python-iniparse-0.3.1-2.1.el6.noarch > libipa_hbac-1.12.4-47.el6.x86_64 > > > > Inactive hide details for Rob Crittenden ---12/03/2015 08:29:53 > AM---Sean Hogan wrote: > Hi Rob,Rob Crittenden ---12/03/2015 08:29:53 > AM---Sean Hogan wrote: > Hi Rob, > > From: Rob Crittenden > To: Sean Hogan/Durham/IBM at IBMUS, "Freeipa-users at redhat.com" > > Date: 12/03/2015 08:29 AM > Subject: Re: [Freeipa-users] Sudo question > > ------------------------------------------------------------------------ > > > > Sean Hogan wrote: >> Hi Rob, >> >> Thanks for the suggestion. I think that is what I have though. The >> sudorule applied for this user does not have sudo as an avail command >> unless it picks up /usr/bin/sudo -u user -i which I was thinking would >> only allow sudoing to user. >> HBAC services I have for the user has sudo and no sudo -i. >> Services >> sshd >> login >> gdm >> gdm-password >> kdm >> su >> su-l >> vsftpd >> sudo >> >> Sudo Rule >> *Sudo Allow Commands*: /sbin/iptables, /sbin/service, >> /bin/view,/bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat >> *Sudo Deny Commands*: /usr/bin/sudo -i, /usr/bin/sudo-i, /usr/bin/sudo >> -u root -i >> >> Unfortunately I am really stumped on this one. > > You probably have the allow_all HBAC rule enabled. If sudo-i isn't > allowed in HBAC then the pam service shouldn't be allowed at all. I'd > suggest you bump up the sssd debug level to better see what is happening. > > rob > >> >> >> >> >> >> Inactive hide details for Rob Crittenden ---12/02/2015 04:26:24 >> PM---Sean Hogan wrote: > Hi All,Rob Crittenden ---12/02/2015 04:26:24 >> PM---Sean Hogan wrote: > Hi All, >> >> From: Rob Crittenden >> To: Sean Hogan/Durham/IBM at IBMUS, freeipa-users at redhat.com >> Date: 12/02/2015 04:26 PM >> Subject: Re: [Freeipa-users] Sudo question >> >> ------------------------------------------------------------------------ >> >> >> >> Sean Hogan wrote: >>> Hi All, >>> >>> I have a significant amount of time on this and hoping some of you might >>> have an idea. I want to limit user bob from getting to a root prompt on >>> this test box. >>> It seems to work until bob is able to run a command he is allowed via >>> sudo such as cat. Sudo -i is on the deny command list in IPA and root is >>> local(not in IPA) with >>> nsswitch pointing to files first then sss. >>> >>> So logged on as user bob, first thing attempted was sudo -i which >>> produces wrong pw message even though it is the correct pw but it is >>> denying so fine. Then I issue sudo cat /etc/sysconfig/iptables >>> and it allows it after I enter bob's pw which is fine. However right >>> after that I try sudo -i again and get root prompt which is not good. I >>> am thinking since root is local and files first then once I sudo up root >>> is avail. >>> Any suggestions are welcome >> >> I think you are better off using an HBAC rule to only grant sudo and not >> sudo -i. >> >> rob >> >>> >>> >>> >>> *[me at mine ~]$ ssh bob at server* >>> bob at servers password: >>> Last login: Time: from IP >>> Internal systems must only be used for conducting company business or >>> for purposes authorized by company management >>> Use is subject to audit at any time by company management >>> *[bob at server ~]$ sudo -i* >>> [sudo] password for bob: >>> Sorry, try again. >>> *[bob at server ~]$ sudo -i* >>> [sudo] password for bob: >>> Sorry, try again. >>> [sudo] password for bob: >>> Sorry, try again. >>> [sudo] password for bob: >>> sudo: 2 incorrect password attempts >>> *[bob at server ~]$ sudo cat /etc/sysconfig/iptables* >>> [sudo] password for bob: >>> # Firewall configuration written by system-config-firewall >>> # Manual customization of this file is not recommended. >>> *filter >>> *[bob at server ~]$ sudo -i* >>> *server.example.local:/root# cat /etc/sysconfig/iptables* >>> # Firewall configuration written by system-config-firewall >>> # Manual customization of this file is not recommended. >>> *filter >>> >>> >>> >>> ipa sudorule-show bob >>> Rule name: bob >>> Description: test sudo rule for user bob >>> Enabled: TRUE >>> Host category: all >>> Users: bob >>> Sudo Allow Commands: /sbin/iptables, /sbin/service, /bin/view, >>> /bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat >>> Sudo Deny Commands: /usr/bin/sudo -i, /usr/bin/sudo-i, /usr/bin/sudo -u >>> root -i >>> >>> Is it just me or is white space ignored as well with sudo commands much >>> like the sudo options? >>> >>> >>> >>> >>> >>> >>> Sean Hogan >>> Security Engineer >>> Watson Security & Risk Assurance >>> Watson Cloud Technology and Support >>> email: schogan at us.ibm.com | Tel 919 486 1397 >>> >>> >>> >>> >>> >>> >>> >> >> >> >> > > > > From schogan at us.ibm.com Thu Dec 3 20:31:17 2015 From: schogan at us.ibm.com (Sean Hogan) Date: Thu, 3 Dec 2015 13:31:17 -0700 Subject: [Freeipa-users] Sudo question In-Reply-To: <5660881C.10106@redhat.com> References: <201512022220.tB2MKecd023463@d03av03.boulder.ibm.com> <565F7E18.4060009@redhat.com> <201512031516.tB3FGPp9011411@d01av04.pok.ibm.com> <56605FDA.7050602@redhat.com> <201512031713.tB3HDk65009814@d01av02.pok.ibm.com> <5660881C.10106@redhat.com> Message-ID: <201512032031.tB3KVUJq002356@d03av01.boulder.ibm.com> Rob, Yes.. in our setup allow_all has to be explicitly applied to a persons/group HBAC for it to be available to them. This user has one direct HBAC rule and its called Bob which only allows access to 2 servers and the services I provided below and one indirect HBAC rule which allows him access to our NFS server automouting home profiles and his own sudo rule called bob. I have removed /bin/bash from his sudo rule and it is working as expected now however I am thinking this will affect app owners from being able to sudo to app IDs so they will just have to su to them instead I am thinking. Is probably a better approach anyways as the app owner should know the app password and keep anyone else from sudoing to it with there own pw. output of working as required: [bob at server ~]$ sudo -i Sorry, user bob is not allowed to execute '/bin/bash' as root on server.example.local. [bob at server ~]$ sudo cat /etc/sysconfig/iptables # Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter [bob at server ~]$ sudo -i Sorry, user bob is not allowed to execute '/bin/bash' as root on server.example.local. [bob at server ~]$ Any comments or suggestions welcome Sean Hogan Security Engineer Watson Security & Risk Assurance Watson Cloud Technology and Support email: schogan at us.ibm.com | Tel 919 486 1397 From: Rob Crittenden To: Sean Hogan/Durham/IBM at IBMUS, "Freeipa-users at redhat.com" Date: 12/03/2015 11:21 AM Subject: Re: [Freeipa-users] Sudo question Sean Hogan wrote: > I had the log bumped to 8 and yes the allow_all HBAC rule is enabled > however not associated with this user at all. This test only allows this > user to hit 2 servers with individual HBAC rule to the 2 servers via the > services I provided earlier. > allow_all applies to everyone unless you've changed it. HBAC is deny by default so once allowed, always allowed. I'm not well-versed in the sssd logs so maybe one of those guys will chime in. rob > [bob at server ~]$ sudo -l > [sudo] password for bob: > Matching Defaults entries for bob on this host: > requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS > DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 > PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE > LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY > LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL > LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", > secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin, logfile=/var/log/sudo.log > > User bob may run the following commands on this host: > (root) !/usr/local/bin/sudo, !/usr/bin/sudo, !/bin/sudo > (root) /usr/bin/xclock > (root) /sbin/iptables, /sbin/service, /bin/vi, /bin/view, /usr/bin/vim, > /bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat, > !/usr/bin/sudo -i, !/usr/bin/sudo-i, !/usr/bin/sudo -u root -i > > > > sssd.conf > server.example.local:/var/log# cat /etc/sssd/sssd.conf > [domain/example.local] > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = example.local > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = server.example.local > chpass_provider = ipa > ipa_dyndns_update = True > ipa_server = _srv_, mastersrv.example.local > ldap_tls_cacert = /etc/ipa/ca.crt > [sssd] > services = nss, sudo, pam, ssh > config_file_version = 2 > debug_level = 8 > > domains = example.local > [nss] > homedir_substring = /home > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > [ifp] > > > Ran thru the commands again: > [me at mine ~]$ ssh bob at server > bob at server password: > Last login: Thu Dec 3 11:24:53 2015 from IP_ADDRESS > [bob at server ~]$ sudo -i > [sudo] password for bob: > Sorry, try again. > [sudo] password for bob: > sudo: 1 incorrect password attempt > [bob at server ~]$ sudo cat /etc/sysconfig/iptables > [sudo] password for bob: > # Firewall configuration written by system-config-firewall > # Manual customization of this file is not recommended. > *filter > [bob at server ~]$ sudo -i > server.example.local:/root# exit > > This is what the logs show for above conversations > Dec 3 11:49:52 server sshd[61682]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP_ADDRESS user=bob > Dec 3 11:49:53 server sshd[61682]: pam_sss(sshd:auth): authentication > success; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP_ADDRESS user=bob > Dec 3 11:49:53 server sshd[61682]: Accepted password for bob from > IP_ADDRESS port 50273 ssh2 > Dec 3 11:49:53 server sshd[61682]: pam_unix(sshd:session): session > opened for user bob by (uid=0) > Dec 3 11:49:53 server sshd[61682]: User child is on pid 61687 > > Attempt sudo -i which fails with bad pw but at least fails, PW is correct. > Dec 3 11:50:05 server sudo: pam_unix(sudo-i:auth): authentication > failure; logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob > rhost= user=bob > Dec 3 11:50:06 server sudo: pam_sss(sudo-i:auth): authentication > success; logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob > rhost= user=bob > Dec 3 11:50:06 server sudo: pam_sss(sudo-i:account): Access denied for > user bob: 6 (Permission denied) > Dec 3 11:50:11 server sudo: pam_unix(sudo-i:auth): conversation failed > Dec 3 11:50:11 server sudo: pam_unix(sudo-i:auth): auth could not > identify password for [bob] > Dec 3 11:50:11 server sudo: pam_sss(sudo-i:auth): authentication > failure; logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob > rhost= user=bob > Dec 3 11:50:11 server sudo: pam_sss(sudo-i:auth): received for user bob: > 7 (Authentication failure) > Dec 3 11:50:11 server sudo: bob : 1 incorrect password attempt ; > TTY=pts/2 ; PWD=/home/rusers/bob ; USER=root ; COMMAND=/bin/bash > > Cat /etc/syconfig/iptables which works after prompting for pw so good > Dec 3 11:50:42 server sudo: pam_unix(sudo:auth): authentication failure; > logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob rhost= user=bob > Dec 3 11:50:43 server sudo: pam_sss(sudo:auth): authentication success; > logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob rhost= user=bob > Dec 3 11:50:43 server sudo: bob : TTY=pts/2 ; PWD=/home/rusers/bob ; > USER=root ; COMMAND=/bin/cat /etc/sysconfig/iptables > > sudo -i now works even though it did not before > Dec 3 11:50:52 server sudo: bob : TTY=pts/2 ; PWD=/home/rusers/bob ; > USER=root ; COMMAND=/bin/bash > > > I expect the pam_unix fails as the accounts are not local.. I expect the > first set of fails for sudo -i even though its comes up a pw issue which > is not the case. I expect success when catting iptables which is good > but then sudo -i just works after that which is not expected. > > Client: > rpm -qa | grep ipa > python-iniparse-0.3.1-2.1.el6.noarch > libipa_hbac-python-1.11.6-30.el6_6.4.ppc64 > ipa-python-3.0.0-42.el6.ppc64 > libipa_hbac-1.11.6-30.el6_6.4.ppc64 > device-mapper-multipath-libs-0.4.9-80.el6_6.3.ppc64 > sssd-ipa-1.11.6-30.el6_6.4.ppc64 > ipa-client-3.0.0-42.el6.ppc64 > device-mapper-multipath-0.4.9-80.el6_6.3.ppc64 > > > Server: > rpm -qa | grep ipa > sssd-ipa-1.12.4-47.el6.x86_64 > ipa-admintools-3.0.0-47.el6.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > libipa_hbac-python-1.12.4-47.el6.x86_64 > ipa-client-3.0.0-47.el6.x86_64 > ipa-python-3.0.0-47.el6.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-server-selinux-3.0.0-47.el6.x86_64 > ipa-server-3.0.0-47.el6.x86_64 > python-iniparse-0.3.1-2.1.el6.noarch > libipa_hbac-1.12.4-47.el6.x86_64 > > > > Inactive hide details for Rob Crittenden ---12/03/2015 08:29:53 > AM---Sean Hogan wrote: > Hi Rob,Rob Crittenden ---12/03/2015 08:29:53 > AM---Sean Hogan wrote: > Hi Rob, > > From: Rob Crittenden > To: Sean Hogan/Durham/IBM at IBMUS, "Freeipa-users at redhat.com" > > Date: 12/03/2015 08:29 AM > Subject: Re: [Freeipa-users] Sudo question > > ------------------------------------------------------------------------ > > > > Sean Hogan wrote: >> Hi Rob, >> >> Thanks for the suggestion. I think that is what I have though. The >> sudorule applied for this user does not have sudo as an avail command >> unless it picks up /usr/bin/sudo -u user -i which I was thinking would >> only allow sudoing to user. >> HBAC services I have for the user has sudo and no sudo -i. >> Services >> sshd >> login >> gdm >> gdm-password >> kdm >> su >> su-l >> vsftpd >> sudo >> >> Sudo Rule >> *Sudo Allow Commands*: /sbin/iptables, /sbin/service, >> /bin/view,/bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat >> *Sudo Deny Commands*: /usr/bin/sudo -i, /usr/bin/sudo-i, /usr/bin/sudo >> -u root -i >> >> Unfortunately I am really stumped on this one. > > You probably have the allow_all HBAC rule enabled. If sudo-i isn't > allowed in HBAC then the pam service shouldn't be allowed at all. I'd > suggest you bump up the sssd debug level to better see what is happening. > > rob > >> >> >> >> >> >> Inactive hide details for Rob Crittenden ---12/02/2015 04:26:24 >> PM---Sean Hogan wrote: > Hi All,Rob Crittenden ---12/02/2015 04:26:24 >> PM---Sean Hogan wrote: > Hi All, >> >> From: Rob Crittenden >> To: Sean Hogan/Durham/IBM at IBMUS, freeipa-users at redhat.com >> Date: 12/02/2015 04:26 PM >> Subject: Re: [Freeipa-users] Sudo question >> >> ------------------------------------------------------------------------ >> >> >> >> Sean Hogan wrote: >>> Hi All, >>> >>> I have a significant amount of time on this and hoping some of you might >>> have an idea. I want to limit user bob from getting to a root prompt on >>> this test box. >>> It seems to work until bob is able to run a command he is allowed via >>> sudo such as cat. Sudo -i is on the deny command list in IPA and root is >>> local(not in IPA) with >>> nsswitch pointing to files first then sss. >>> >>> So logged on as user bob, first thing attempted was sudo -i which >>> produces wrong pw message even though it is the correct pw but it is >>> denying so fine. Then I issue sudo cat /etc/sysconfig/iptables >>> and it allows it after I enter bob's pw which is fine. However right >>> after that I try sudo -i again and get root prompt which is not good. I >>> am thinking since root is local and files first then once I sudo up root >>> is avail. >>> Any suggestions are welcome >> >> I think you are better off using an HBAC rule to only grant sudo and not >> sudo -i. >> >> rob >> >>> >>> >>> >>> *[me at mine ~]$ ssh bob at server* >>> bob at servers password: >>> Last login: Time: from IP >>> Internal systems must only be used for conducting company business or >>> for purposes authorized by company management >>> Use is subject to audit at any time by company management >>> *[bob at server ~]$ sudo -i* >>> [sudo] password for bob: >>> Sorry, try again. >>> *[bob at server ~]$ sudo -i* >>> [sudo] password for bob: >>> Sorry, try again. >>> [sudo] password for bob: >>> Sorry, try again. >>> [sudo] password for bob: >>> sudo: 2 incorrect password attempts >>> *[bob at server ~]$ sudo cat /etc/sysconfig/iptables* >>> [sudo] password for bob: >>> # Firewall configuration written by system-config-firewall >>> # Manual customization of this file is not recommended. >>> *filter >>> *[bob at server ~]$ sudo -i* >>> *server.example.local:/root# cat /etc/sysconfig/iptables* >>> # Firewall configuration written by system-config-firewall >>> # Manual customization of this file is not recommended. >>> *filter >>> >>> >>> >>> ipa sudorule-show bob >>> Rule name: bob >>> Description: test sudo rule for user bob >>> Enabled: TRUE >>> Host category: all >>> Users: bob >>> Sudo Allow Commands: /sbin/iptables, /sbin/service, /bin/view, >>> /bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat >>> Sudo Deny Commands: /usr/bin/sudo -i, /usr/bin/sudo-i, /usr/bin/sudo -u >>> root -i >>> >>> Is it just me or is white space ignored as well with sudo commands much >>> like the sudo options? >>> >>> >>> >>> >>> >>> >>> Sean Hogan >>> Security Engineer >>> Watson Security & Risk Assurance >>> Watson Cloud Technology and Support >>> email: schogan at us.ibm.com | Tel 919 486 1397 >>> >>> >>> >>> >>> >>> >>> >> >> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 07599701.jpg Type: image/jpeg Size: 27085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 07588255.gif Type: image/gif Size: 1650 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From rmeggins at redhat.com Thu Dec 3 21:44:15 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 3 Dec 2015 14:44:15 -0700 Subject: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system In-Reply-To: References: <20151202210209.GD8374@redhat.com> <565FF769.3010707@redhat.com> Message-ID: <5660B7AF.2070209@redhat.com> On 12/03/2015 08:33 AM, Andy Thompson wrote: > >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >> bounces at redhat.com] On Behalf Of Petr Spacek >> Sent: Thursday, December 3, 2015 3:04 AM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system >> >> On 2.12.2015 22:02, Alexander Bokovoy wrote: >>> On Wed, 02 Dec 2015, Andy Thompson wrote: >>>> Since updating to RHEL 7.2 I've got issues with ns-slapd hanging the >>>> system up after a period of time. The directory becomes unresponsive >>>> to searches or any connections. After a restart I see >>>> >>>> [02/Dec/2015:15:27:41 -0500] - slapd started. Listening on All >>>> Interfaces port 389 for LDAP requests >>>> [02/Dec/2015:15:27:41 -0500] - Listening on All Interfaces port 636 >>>> for LDAPS requests >>>> [02/Dec/2015:15:27:41 -0500] - Listening on >>>> /var/run/slapd-MHBENP-LIN.socket for LDAPI requests >>>> [02/Dec/2015:15:27:44 -0500] NSMMReplicationPlugin - >>>> agmt="cn=meTomdhixnpipa02.mhbenp.lin" (mdhixnpipa02:389): >> Replication >>>> bind with GSSAPI auth resumed >>>> [02/Dec/2015:15:27:47 -0500] NSMMReplicationPlugin - replication keep >>>> alive entry already exists >>>> >>>> In the logs and occasionally the keepalive entry message is seen a >>>> few times and then eventually the ns-slapd taps the system. 100% >>>> util, system load crawls up between 30 and 40 and eventually I have >>>> to restart the service to get it to respond again. Memory usage is >>>> normal, db and entry cache is sufficient.. possibly a little on the >>>> high side but resource is sitting there asking to be used :) >>>> >>>> Running 389-ds-base-1.3.4.0-19.el7.x86_64 after the update yesterday. >>>> >>>> What additional information can I provide? >>> install debuginfo for 389-ds-base and slapi-nis, and take a pstack >>> output for ns-slapd pid. >> For detailed instructions please see >> http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug_hangs >> > Here is the resulting stacktrace during the last hang. The server is idle at this point. None of the threads are doing any work, or are blocked/deadlocked. It does not appear hung at all. When the server is in the "hung" state again, use ldapsearch (e.g. -s base -b "") to "ping" the server to see if it is entirely unresponsive. > -andy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andy.Thompson at e-tcc.com Fri Dec 4 14:37:09 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Fri, 4 Dec 2015 14:37:09 +0000 Subject: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system In-Reply-To: <5660B7AF.2070209@redhat.com> References: <20151202210209.GD8374@redhat.com> <565FF769.3010707@redhat.com> <5660B7AF.2070209@redhat.com> Message-ID: <2864351c1611466d84893c4200a24416@TCCCORPEXCH02.TCC.local> > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Rich Megginson > Sent: Thursday, December 3, 2015 4:44 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system > > On 12/03/2015 08:33 AM, Andy Thompson wrote: > > > > > > -----Original Message----- > From: freeipa-users-bounces at redhat.com users-bounces at redhat.com> [mailto:freeipa-users- > bounces at redhat.com ] On > Behalf Of Petr Spacek > Sent: Thursday, December 3, 2015 3:04 AM > To: freeipa-users at redhat.com users at redhat.com> > Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd > hanging system > > On 2.12.2015 22:02, Alexander Bokovoy wrote: > > On Wed, 02 Dec 2015, Andy Thompson wrote: > > Since updating to RHEL 7.2 I've got issues with > ns-slapd hanging the > system up after a period of time. The > directory becomes unresponsive > to searches or any connections. After a > restart I see > > [02/Dec/2015:15:27:41 -0500] - slapd started. > Listening on All > Interfaces port 389 for LDAP requests > [02/Dec/2015:15:27:41 -0500] - Listening on > All Interfaces port 636 > for LDAPS requests > [02/Dec/2015:15:27:41 -0500] - Listening on > /var/run/slapd-MHBENP-LIN.socket for > LDAPI requests > [02/Dec/2015:15:27:44 -0500] > NSMMReplicationPlugin - > agmt="cn=meTomdhixnpipa02.mhbenp.lin" > (mdhixnpipa02:389): > > Replication > > bind with GSSAPI auth resumed > [02/Dec/2015:15:27:47 -0500] > NSMMReplicationPlugin - replication keep > alive entry 4,dc=mhbenp,dc=lin> already exists > > In the logs and occasionally the keepalive > entry message is seen a > few times and then eventually the ns-slapd > taps the system. 100% > util, system load crawls up between 30 and 40 > and eventually I have > to restart the service to get it to respond > again. Memory usage is > normal, db and entry cache is sufficient.. > possibly a little on the > high side but resource is sitting there asking > to be used :) > > Running 389-ds-base-1.3.4.0-19.el7.x86_64 > after the update yesterday. > > What additional information can I provide? > > install debuginfo for 389-ds-base and slapi-nis, and > take a pstack > output for ns-slapd pid. > > > For detailed instructions please see > > http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug > _hangs > > > > Here is the resulting stacktrace during the last hang. > > > The server is idle at this point. None of the threads are doing any work, or > are blocked/deadlocked. It does not appear hung at all. > > When the server is in the "hung" state again, use ldapsearch (e.g. -s base -b > "") to "ping" the server to see if it is entirely unresponsive. > > > No ldapsearch does not respond, it just hangs and doesn't ever return. -andy From rmeggins at redhat.com Fri Dec 4 16:12:07 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 4 Dec 2015 09:12:07 -0700 Subject: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system In-Reply-To: <2864351c1611466d84893c4200a24416@TCCCORPEXCH02.TCC.local> References: <20151202210209.GD8374@redhat.com> <565FF769.3010707@redhat.com> <5660B7AF.2070209@redhat.com> <2864351c1611466d84893c4200a24416@TCCCORPEXCH02.TCC.local> Message-ID: <5661BB57.7070001@redhat.com> On 12/04/2015 07:37 AM, Andy Thompson wrote: > >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >> bounces at redhat.com] On Behalf Of Rich Megginson >> Sent: Thursday, December 3, 2015 4:44 PM >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system >> >> On 12/03/2015 08:33 AM, Andy Thompson wrote: >> >> >> >> >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com > users-bounces at redhat.com> [mailto:freeipa-users- >> bounces at redhat.com ] On >> Behalf Of Petr Spacek >> Sent: Thursday, December 3, 2015 3:04 AM >> To: freeipa-users at redhat.com > users at redhat.com> >> Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd >> hanging system >> >> On 2.12.2015 22:02, Alexander Bokovoy wrote: >> >> On Wed, 02 Dec 2015, Andy Thompson wrote: >> >> Since updating to RHEL 7.2 I've got issues with >> ns-slapd hanging the >> system up after a period of time. The >> directory becomes unresponsive >> to searches or any connections. After a >> restart I see >> >> [02/Dec/2015:15:27:41 -0500] - slapd started. >> Listening on All >> Interfaces port 389 for LDAP requests >> [02/Dec/2015:15:27:41 -0500] - Listening on >> All Interfaces port 636 >> for LDAPS requests >> [02/Dec/2015:15:27:41 -0500] - Listening on >> /var/run/slapd-MHBENP-LIN.socket for >> LDAPI requests >> [02/Dec/2015:15:27:44 -0500] >> NSMMReplicationPlugin - >> agmt="cn=meTomdhixnpipa02.mhbenp.lin" >> (mdhixnpipa02:389): >> >> Replication >> >> bind with GSSAPI auth resumed >> [02/Dec/2015:15:27:47 -0500] >> NSMMReplicationPlugin - replication keep >> alive entry > 4,dc=mhbenp,dc=lin> already exists >> >> In the logs and occasionally the keepalive >> entry message is seen a >> few times and then eventually the ns-slapd >> taps the system. 100% >> util, system load crawls up between 30 and 40 >> and eventually I have >> to restart the service to get it to respond >> again. Memory usage is >> normal, db and entry cache is sufficient.. >> possibly a little on the >> high side but resource is sitting there asking >> to be used :) >> >> Running 389-ds-base-1.3.4.0-19.el7.x86_64 >> after the update yesterday. >> >> What additional information can I provide? >> >> install debuginfo for 389-ds-base and slapi-nis, and >> take a pstack >> output for ns-slapd pid. >> >> >> For detailed instructions please see >> >> http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug >> _hangs >> >> >> >> Here is the resulting stacktrace during the last hang. >> >> >> The server is idle at this point. None of the threads are doing any work, or >> are blocked/deadlocked. It does not appear hung at all. >> >> When the server is in the "hung" state again, use ldapsearch (e.g. -s base -b >> "") to "ping" the server to see if it is entirely unresponsive. >> >> >> > No ldapsearch does not respond, it just hangs and doesn't ever return. Try doing an strace of ldapsearch to see in what system call it is stuck in (or you can just do an strace/pstack on the running, hung ldapsearch process). > > -andy From Daryl.Fonseca-Holt at umanitoba.ca Fri Dec 4 19:42:29 2015 From: Daryl.Fonseca-Holt at umanitoba.ca (Daryl Fonseca-Holt) Date: Fri, 4 Dec 2015 13:42:29 -0600 Subject: [Freeipa-users] Mixing client and server versions Message-ID: <5661ECA5.2070700@umanitoba.ca> These has probably been asked before but I'm new to the list and haven't seen it answered. 1) Will an IPA 4.x client work with an IPA 3.0 server? 2) Will an IPA 3.0 client work with an IPA 4.x server? Thanks, Daryl -- -- Daryl Fonseca-Holt IST/CNS/Unix Server Team University of Manitoba 204.480.1079 From Jeff.Sauls at photomask.com Fri Dec 4 20:03:04 2015 From: Jeff.Sauls at photomask.com (Sauls, Jeff) Date: Fri, 4 Dec 2015 14:03:04 -0600 Subject: [Freeipa-users] HBAC access denied, all AD groups not detected Message-ID: Hello, We are having a problem with HBAC that appears to be related to group membership lookup. I am testing with a new install on RHEL 7.2 with a cross-forest trust with AD. When an AD user attempts to log into a client (RH 6.7 or 7.2) the "hbac_eval_user_element" can report a different number of groups each time and never seems to contain the full list. For the testing account, running the 'id' command returns 153 groups. The ipa group "ad_admin" has setup to be able to log in anywhere, everyone else is denied. With the default allow_all rule enabled, everything works as expected. Any ideas on where I can look next? Example grep from the client domain log (account had no changes to group membership): (Fri Dec 4 00:46:35 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): [113] groups for [testuser at AD.DOMAIN.COM] (Fri Dec 4 00:47:31 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): [112] groups for [testuser at AD.DOMAIN.COM] (Fri Dec 4 01:00:20 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): [72] groups for [testuser at AD.DOMAIN.COM] (Fri Dec 4 01:10:24 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): [72] groups for [testuser at AD.DOMAIN.COM] (Fri Dec 4 01:14:20 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): [72] groups for [testuser at AD.DOMAIN.COM] (Fri Dec 4 01:24:21 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): [72] groups for [testuser at AD.DOMAIN.COM] (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): [73] groups for [testuser at AD.DOMAIN.COM] Example of an HBAC rule passing: (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x2000): Skipping non-group memberOf [CN=] ... repeated for however many groups happened to be examined (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): Added group [ad_admins] for user [testuser at AD.DOMAIN.COM] (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2469f40 (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x2460080 (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Running timer event 0x2469f40 "ltdb_callback" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Destroying timer event 0x2460080 "ltdb_timeout" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Ending timer event 0x2469f40 "ltdb_callback" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x245aee0 (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x2460080 (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Running timer event 0x245aee0 "ltdb_callback" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Destroying timer event 0x2460080 "ltdb_timeout" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Ending timer event 0x245aee0 "ltdb_callback" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2469f40 (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x2460080 (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Running timer event 0x2469f40 "ltdb_callback" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Destroying timer event 0x2460080 "ltdb_timeout" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Ending timer event 0x2469f40 "ltdb_callback" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [admin-access] Example of an HBAC rule failing: (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x2000): Skipping non-group memberOf [CN=] ... repeated for however many groups happened to be examined (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x2000): Skipping non-group memberOf [CN=] (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x26f8d00 (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x26e18d0 (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Running timer event 0x26f8d00 "ltdb_callback" (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Destroying timer event 0x26e18d0 "ltdb_timeout" (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Ending timer event 0x26f8d00 "ltdb_callback" (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x27e51f0 (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x27f2230 (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Running timer event 0x27e51f0 "ltdb_callback" (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Destroying timer event 0x27f2230 "ltdb_timeout" (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Ending timer event 0x27e51f0 "ltdb_callback" (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2634520 (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x27f8a40 (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Running timer event 0x2634520 "ltdb_callback" (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Destroying timer event 0x27f8a40 "ltdb_timeout" (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Ending timer event 0x2634520 "ltdb_callback" (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access denied by HBAC rules Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at stefany.eu Fri Dec 4 20:11:19 2015 From: martin at stefany.eu (Martin =?UTF-8?Q?=C5=A0tefany?=) Date: Fri, 04 Dec 2015 21:11:19 +0100 Subject: [Freeipa-users] Mixing client and server versions In-Reply-To: <5661ECA5.2070700@umanitoba.ca> References: <5661ECA5.2070700@umanitoba.ca> Message-ID: <1449259879.5344.2.camel@stefany.eu> Hi Daryl, IPA client <-> IPA server are both backward and forward compatible, see: http://www.freeipa.org/page/Client#Compatibility Note: except ipa-admintools, that one is a (thick) client and is compatible only forward, see the page for better explanation. Martin On Pi, 2015-12-04 at 13:42 -0600, Daryl Fonseca-Holt wrote: > These has probably been asked before??but I'm new to the list and > haven't seen it answered. > > 1) Will an IPA 4.x client work with an IPA 3.0 server? > 2) Will an IPA 3.0 client work with an IPA 4.x server? > > Thanks, Daryl > > -- > ? -- > ? Daryl Fonseca-Holt > ? IST/CNS/Unix Server Team > ? University of Manitoba > ? 204.480.1079 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From stefano.cortese at ego-gw.it Sat Dec 5 17:44:45 2015 From: stefano.cortese at ego-gw.it (Stefano Cortese) Date: Sat, 05 Dec 2015 18:44:45 +0100 Subject: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7 Message-ID: <5663228D.7020808@ego-gw.it> Hello, we have a number of ipa 3.0 clients that have been upgraded from Scientific Linux 6.6 to 6.7 and after the upgrade both the .k5login authorization and auth_to_local_names mappings don't work anymore as before. The environment is linux only with no AD/Samba Essentially we are using those mechanism to manage the spawning of processes via kerberized rsh or GSS ssh using service principals that are mapped to IPA accounts on the remote clients. Basically process A on hostA runs as userA with service principal serviceA credentials from a local keytab and spawns a remote process on hostB via /usr/kerberos/bin/rsh -l userB hostB In userB homedir the .k5login file contains: the userB principal the serviceA principal The running of the remote command is denied on host B with an error like: "Principal serviceA for local user userB failed krb5_kuserok" The same problem occurs if instead of the .k5login file the mapping is done configuring the auth_to_local_names section in /etc/krb5.conf on hostB Digging on the sssd/kerberos and IPA topics I have found that the behaviour is caused by the introduction of the localauth sssd kerberos plugin configured in /var/lib/sss/pubconf/krb5.include.d/localauth_plugin (see https://fedorahosted.org/sssd/wiki/DesignDocs/NSSWithKerberosPrincipal ) To be sure I downgraded the krb5-libs package on SL6.7 from version 1.10.3-42 ( the one where the localauth krb5 interface has been backported https://rhn.redhat.com/errata/RHBA-2015-1410.html ) to version 1.10.3-37 and the mapping works correctly Indeed in this mail https://www.mail-archive.com/sssd-devel at lists.fedorahosted.org/msg19174.html it is made clear that the plugin overloads the standard kuserok() and krb5_aname_to_localname() calls in view of a better integration with Active Directory or the mapping managed centrally For the moment we don't need integration with Active Directory, so the solution was to comment the following line in /etc/krb5.conf: includedir /var/lib/sss/pubconf/krb5.include.d So the questions are: - is there another cleaner way to exclude the localauth sssd plugin (considering that the configuration snippet is recreated at every sssd restart)? - is there the possibility on IPA 4.1 (the version of our server) to manage the mapping letting the plugin in place, namely to associate or authorize one or multiple service principals with an ipa posix account so that the getpwent() works? - is there a more suitable way to obtain the above delegation and security context switching using other mechanisms supported by IPA? Thanks in advance Stefano From traiano at gmail.com Sun Dec 6 18:58:58 2015 From: traiano at gmail.com (Traiano Welcome) Date: Sun, 6 Dec 2015 21:58:58 +0300 Subject: [Freeipa-users] FreeIPA Clients behind unreliable network links at remote sites Message-ID: Hi List Current Scenario: ============= I have a number of stores on really unreliable network connections: It's quite possible for the links to have been down for 3 - 4 days at a time. In a given store is a single Linux "Back Office" server running Directory 389 which holds credentials for a number of tech support usernames. There are also a number of point of sale computers running linux which authenticate users against the 389 Directory server on the back office server. The Directory servers in the shops all synch their copy of the credential database from a central Directory Server, during normal operation. At some point a support engineer goes to the store to do maintenance on the point-of-sale computers and logs in with his Directory 389 credentials. Since the credential DB almost never changes (usernames and passwords stay static), a support technician can generally rely on the credentials being "as expected" even if the store has been out of contact with the master copy of 389 directory servers: The technician can log in to a PoS, do maintenance, even while the network link is in the process of being restored. Desired scenario: ============= I'd like to deploy FreeIPA to these stores, and replace 389 Directory server based system running on the Linux. The problem is that the point-of-sale machines will frequently lose contact with the primary replica, and credentials will timeout. So when the support technician walks in and the network link happens to have been down for some time, he'll not be able to log in to the point-of-sale computers. Note: There is no possibility of installing a freeipa replica on the Back Office server itself, it's got a whole pile of bespoke Java + tomcat crud running on it. There is also no possibility of installing an additional FreeIPA replica server in the store itself - the economics of the store won't allow it. Possible solution: ============= I think enabling offline authentication, with credential expiry disabled completely may do the trick, with the downside that user accounts that have been deleted in the 'main' FreeIPA replica may still linger in the store's copy ... https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-cache-cred.html "offline_credentials_expiration sets the number of days after a successful login that a single credentials entry for a user is preserved in cache. Setting this to zero (0) means that entries are kept forever." My expectation is that credentials will be updated while connectivity is there, but authentication will be possible even in loss of connectivity for quite some time. My question is: Is this the best approach to solving the reliable authentication problem, given that the client's may not be able to access a FreeIPA replica for long periods of time? Are there any key issues I'm overlooking in taking this approach, or possibly better approaches? Many thanks for any suggestions! Traiano From jhrozek at redhat.com Mon Dec 7 08:59:22 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 7 Dec 2015 09:59:22 +0100 Subject: [Freeipa-users] HBAC access denied, all AD groups not detected In-Reply-To: References: Message-ID: <20151207085922.GD3399@hendrix.redhat.com> On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote: > Hello, > > We are having a problem with HBAC that appears to be related to group > membership lookup. I am testing with a new install on RHEL 7.2 with a > cross-forest trust with AD. When an AD user attempts to log into a client > (RH 6.7 or 7.2) the "hbac_eval_user_element" can report a different > number of groups each time and never seems to contain the full list. > For the testing account, running the 'id' command returns 153 groups. > The ipa group "ad_admin" has setup to be able to log in anywhere, everyone > else is denied. With the default allow_all rule enabled, everything works > as expected. Any ideas on where I can look next? I assume the group membership is OK on the server, but not the client? Can you enable debugging and also include the full logs from the client after doing sss_cache -E on the client? From jhrozek at redhat.com Mon Dec 7 08:59:38 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 7 Dec 2015 09:59:38 +0100 Subject: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7 In-Reply-To: <5663228D.7020808@ego-gw.it> References: <5663228D.7020808@ego-gw.it> Message-ID: <20151207085938.GE3399@hendrix.redhat.com> On Sat, Dec 05, 2015 at 06:44:45PM +0100, Stefano Cortese wrote: > Hello, > we have a number of ipa 3.0 clients that have been upgraded from Scientific > Linux 6.6 to 6.7 and after the upgrade both the .k5login authorization and > auth_to_local_names mappings don't work anymore as before. > The environment is linux only with no AD/Samba > > Essentially we are using those mechanism to manage the spawning of processes > via kerberized rsh or GSS ssh using service principals that are mapped to > IPA accounts on the remote clients. > Basically process A on hostA runs as userA with service principal serviceA > credentials from a local keytab and spawns a remote process on hostB via > /usr/kerberos/bin/rsh -l userB hostB > In userB homedir the .k5login file contains: > the userB principal > the serviceA principal > > The running of the remote command is denied on host B with an error like: > "Principal serviceA for local user userB failed krb5_kuserok" > > The same problem occurs if instead of the .k5login file the mapping is done > configuring the auth_to_local_names section in /etc/krb5.conf on hostB > > Digging on the sssd/kerberos and IPA topics I have found that the behaviour > is caused by the introduction of the localauth sssd kerberos plugin > configured in /var/lib/sss/pubconf/krb5.include.d/localauth_plugin (see > https://fedorahosted.org/sssd/wiki/DesignDocs/NSSWithKerberosPrincipal ) > > To be sure I downgraded the krb5-libs package on SL6.7 from version > 1.10.3-42 ( the one where the localauth krb5 interface has been backported > https://rhn.redhat.com/errata/RHBA-2015-1410.html ) to version 1.10.3-37 > and the mapping works correctly > > Indeed in this mail > https://www.mail-archive.com/sssd-devel at lists.fedorahosted.org/msg19174.html > it is made clear that the plugin overloads the standard kuserok() and > krb5_aname_to_localname() calls in view of a better integration with Active > Directory or the mapping managed centrally > > For the moment we don't need integration with Active Directory, so the > solution was to comment the following line in /etc/krb5.conf: > includedir /var/lib/sss/pubconf/krb5.include.d > > So the questions are: > - is there another cleaner way to exclude the localauth sssd plugin > (considering that the configuration snippet is recreated at every sssd > restart)? Can you test if this hack would help: # service sssd stop # rm /var/lib/sss/pubconf/krb5.include.d/localauth_plugin # touch /var/lib/sss/pubconf/krb5.include.d/localauth_plugin # chattr +i /var/lib/sss/pubconf/krb5.include.d/localauth_plugin # service sssd start btw also check out this ticket: https://fedorahosted.org/sssd/ticket/2788 > - is there the possibility on IPA 4.1 (the version of our server) to manage > the mapping letting the plugin in place, namely to associate or authorize > one or multiple service principals with an ipa posix account so that the > getpwent() works? I wonder why the mapping fails, can you invalidate the cache with sss_cache and try to look up the principal from the command line, using getent passwd primary at REALM ? > - is there a more suitable way to obtain the above delegation and security > context switching using other mechanisms supported by IPA? > > Thanks in advance > Stefano > > > -- > 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 From jhrozek at redhat.com Mon Dec 7 09:00:02 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 7 Dec 2015 10:00:02 +0100 Subject: [Freeipa-users] FreeIPA Clients behind unreliable network links at remote sites In-Reply-To: References: Message-ID: <20151207090002.GF3399@hendrix.redhat.com> On Sun, Dec 06, 2015 at 09:58:58PM +0300, Traiano Welcome wrote: > Hi List > > > Current Scenario: > ============= > > I have a number of stores on really unreliable network connections: > It's quite possible for the links to have been down for 3 - 4 days at > a time. > > In a given store is a single Linux "Back Office" server running > Directory 389 which holds credentials for a number of tech support > usernames. > There are also a number of point of sale computers running linux which > authenticate users against the 389 Directory server on the back office > server. > The Directory servers in the shops all synch their copy of the > credential database from a central Directory Server, during normal > operation. > > At some point a support engineer goes to the store to do maintenance > on the point-of-sale computers and logs in with his Directory 389 > credentials. > Since the credential DB almost never changes (usernames and passwords > stay static), a support technician can generally rely on the > credentials being "as expected" even if the store has been out of > contact with the master copy of 389 directory servers: The technician > can log in to a PoS, do maintenance, even while the network link is in > the process of being restored. > > Desired scenario: > ============= > > I'd like to deploy FreeIPA to these stores, and replace 389 Directory > server based system running on the Linux. The problem is that the > point-of-sale machines will frequently lose contact with the primary > replica, and credentials will timeout. So when the support technician > walks in and the network link happens to have been down for some time, > he'll not be able to log in to the point-of-sale computers. > > Note: There is no possibility of installing a freeipa replica on the > Back Office server itself, it's got a whole pile of bespoke Java + > tomcat crud running on it. There is also no possibility of installing > an additional FreeIPA replica server in the store itself - the > economics of the store won't allow it. > > Possible solution: > ============= > > I think enabling offline authentication, with credential expiry > disabled completely may do the trick, with the downside that user > accounts that have been deleted in the 'main' FreeIPA replica may > still linger in the store's copy ... > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-cache-cred.html > > "offline_credentials_expiration sets the number of days after a > successful login that a single credentials entry for a user is > preserved in cache. Setting this to zero (0) means that entries are > kept forever." > > My expectation is that credentials will be updated while connectivity > is there, but authentication will be possible even in loss of > connectivity for quite some time. > > My question is: Is this the best approach to solving the reliable > authentication problem, given that the client's may not be able to > access a FreeIPA replica for long periods of time? Are there any key > issues I'm overlooking in taking this approach, or possibly better > approaches? I think this should work OK. The clients (SSSD) always try to log in offline, so as soon as the client would re-establish connection to the server, the client would check against server's database, otherwise consult the local cache. Just make sure noone removes the sssd database if they think the client is acting up as a 'troubleshooting', the credentials are cached there :-) From mkosek at redhat.com Mon Dec 7 11:32:21 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 7 Dec 2015 12:32:21 +0100 Subject: [Freeipa-users] Mixing client and server versions In-Reply-To: <1449259879.5344.2.camel@stefany.eu> References: <5661ECA5.2070700@umanitoba.ca> <1449259879.5344.2.camel@stefany.eu> Message-ID: <56656E45.4010408@redhat.com> On 12/04/2015 09:11 PM, Martin ?tefany wrote: > Hi Daryl, > > IPA client <-> IPA server are both backward and forward compatible, see: > > http://www.freeipa.org/page/Client#Compatibility > > Note: except ipa-admintools, that one is a (thick) client and is > compatible only forward, see the page for better explanation. Right. Note that for FreeIPA 4.4, there are plans to address also the ipa-admintools backwards incomatibility: https://fedorahosted.org/freeipa/ticket/4739 So stay tuned :-) > > Martin > > On Pi, 2015-12-04 at 13:42 -0600, Daryl Fonseca-Holt wrote: >> These has probably been asked before but I'm new to the list and >> haven't seen it answered. >> >> 1) Will an IPA 4.x client work with an IPA 3.0 server? >> 2) Will an IPA 3.0 client work with an IPA 4.x server? >> >> Thanks, Daryl >> >> -- >> -- >> Daryl Fonseca-Holt >> IST/CNS/Unix Server Team >> University of Manitoba >> 204.480.1079 >> >> From marc.boorshtein at tremolosecurity.com Mon Dec 7 15:04:34 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Mon, 7 Dec 2015 10:04:34 -0500 Subject: [Freeipa-users] Generation of /etc/krb5.conf file Message-ID: FreeIPA team, In doing some work with Java I came across an issue with = the krb5.conf file generated by the IPA client install process. Options in the krb5.conf file that are boolean are being set as yes/no instead of true/false. MIT Kerberos accepts it but per the docs it should be true/false. Here's a link to the issue in OpenJDK: https://bugs.openjdk.java.net/browse/JDK-8029995 Easy enough fix on my end, just changed the options in the krb5.conf file. Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com From simo at redhat.com Mon Dec 7 15:29:14 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 07 Dec 2015 10:29:14 -0500 Subject: [Freeipa-users] Generation of /etc/krb5.conf file In-Reply-To: References: Message-ID: <1449502154.17418.1.camel@redhat.com> On Mon, 2015-12-07 at 10:04 -0500, Marc Boorshtein wrote: > FreeIPA team, > > In doing some work with Java I came across an issue with = the > krb5.conf file generated by the IPA client install process. Options > in the krb5.conf file that are boolean are being set as yes/no instead > of true/false. MIT Kerberos accepts it but per the docs it should be > true/false. Here's a link to the issue in OpenJDK: > > https://bugs.openjdk.java.net/browse/JDK-8029995 > > Easy enough fix on my end, just changed the options in the krb5.conf file. Do you know if these options are generated by the installer or are those the ones included with the sssd generated file ? Would you mind filing a ticket? I think this should be fixed. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Mon Dec 7 15:30:03 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 7 Dec 2015 17:30:03 +0200 Subject: [Freeipa-users] Generation of /etc/krb5.conf file In-Reply-To: References: Message-ID: <20151207153003.GA8374@redhat.com> On Mon, 07 Dec 2015, Marc Boorshtein wrote: >FreeIPA team, > >In doing some work with Java I came across an issue with = the >krb5.conf file generated by the IPA client install process. Options >in the krb5.conf file that are boolean are being set as yes/no instead >of true/false. MIT Kerberos accepts it but per the docs it should be >true/false. Here's a link to the issue in OpenJDK: > >https://bugs.openjdk.java.net/browse/JDK-8029995 > >Easy enough fix on my end, just changed the options in the krb5.conf file. Looking into krb5/src/util/profile/prof_get.c, the code that supports 'yes'/'no' (y,yes,1,true,t,on and n,no,nil,off,false) was added in 2000 with the commit 97971c69b9389be08b7e9ffb742ca35f3706b3af (it was CVS at the time but the commit is traceable via git after import from SVN). So I would say this is documentation issue on MIT krb5 side rather than exception. Given that the code is supported for 15 years already, perhaps making JDK aware of it is a better idea? -- / Alexander Bokovoy From marc.boorshtein at tremolosecurity.com Mon Dec 7 15:45:09 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Mon, 7 Dec 2015 10:45:09 -0500 Subject: [Freeipa-users] Generation of /etc/krb5.conf file In-Reply-To: <1449502154.17418.1.camel@redhat.com> References: <1449502154.17418.1.camel@redhat.com> Message-ID: > > Do you know if these options are generated by the installer or are those > the ones included with the sssd generated file ? > I do not. I didn't setup any kerberos configurations other then running the ipa client install to join the domain. > Would you mind filing a ticket? I think this should be fixed. Done - https://fedorahosted.org/freeipa/ticket/5518 > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > From simo at redhat.com Mon Dec 7 15:47:07 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 07 Dec 2015 10:47:07 -0500 Subject: [Freeipa-users] Generation of /etc/krb5.conf file In-Reply-To: References: <1449502154.17418.1.camel@redhat.com> Message-ID: <1449503227.17418.5.camel@redhat.com> On Mon, 2015-12-07 at 10:45 -0500, Marc Boorshtein wrote: > > > > Do you know if these options are generated by the installer or are those > > the ones included with the sssd generated file ? > > > > I do not. I didn't setup any kerberos configurations other then > running the ipa client install to join the domain. > > > Would you mind filing a ticket? I think this should be fixed. > > Done - https://fedorahosted.org/freeipa/ticket/5518 Thanks! Simo. -- Simo Sorce * Red Hat, Inc * New York From marc.boorshtein at tremolosecurity.com Mon Dec 7 15:48:08 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Mon, 7 Dec 2015 10:48:08 -0500 Subject: [Freeipa-users] Generation of /etc/krb5.conf file In-Reply-To: <20151207153003.GA8374@redhat.com> References: <20151207153003.GA8374@redhat.com> Message-ID: > > Looking into krb5/src/util/profile/prof_get.c, the code that supports > 'yes'/'no' (y,yes,1,true,t,on and n,no,nil,off,false) was added in 2000 > with the commit 97971c69b9389be08b7e9ffb742ca35f3706b3af (it was CVS at > the time but the commit is traceable via git after import from SVN). > > So I would say this is documentation issue on MIT krb5 side rather than > exception. Given that the code is supported for 15 years already, > perhaps making JDK aware of it is a better idea? > While yes its clearly a documentation issue I'd say its probably worth changing on the IPA side as it doesn't affect how IPA functions and makes it easier for integrating applications that are built to those docs. I know I spent a couple of hours trying to figure out why I wasn't generating forwardable TGTs on a box that is part of the domain from an ipa client install vs a manually configured krb5.conf file. Thanks From abokovoy at redhat.com Mon Dec 7 15:54:13 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 7 Dec 2015 17:54:13 +0200 Subject: [Freeipa-users] Generation of /etc/krb5.conf file In-Reply-To: References: <20151207153003.GA8374@redhat.com> Message-ID: <20151207155413.GB8374@redhat.com> On Mon, 07 Dec 2015, Marc Boorshtein wrote: >> >> Looking into krb5/src/util/profile/prof_get.c, the code that supports >> 'yes'/'no' (y,yes,1,true,t,on and n,no,nil,off,false) was added in 2000 >> with the commit 97971c69b9389be08b7e9ffb742ca35f3706b3af (it was CVS at >> the time but the commit is traceable via git after import from SVN). >> >> So I would say this is documentation issue on MIT krb5 side rather than >> exception. Given that the code is supported for 15 years already, >> perhaps making JDK aware of it is a better idea? >> > >While yes its clearly a documentation issue I'd say its probably worth >changing on the IPA side as it doesn't affect how IPA functions and >makes it easier for integrating applications that are built to those >docs. I know I spent a couple of hours trying to figure out why I >wasn't generating forwardable TGTs on a box that is part of the domain >from an ipa client install vs a manually configured krb5.conf file. Yes, given that the rest of the code adds true/false, at least in ipa-client-install and ipa-replica-conncheck where we handle krb5.conf updates. -- / Alexander Bokovoy From stefano.cortese at ego-gw.it Mon Dec 7 17:04:30 2015 From: stefano.cortese at ego-gw.it (Stefano Cortese) Date: Mon, 07 Dec 2015 18:04:30 +0100 Subject: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7 Message-ID: <5665BC1E.3@ego-gw.it> > > So the questions are: > > - is there another cleaner way to exclude the localauth sssd plugin > > (considering that the configuration snippet is recreated at every sssd > > restart)? > > Can you test if this hack would help: > # service sssd stop > # rm /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > # touch /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > # chattr +i /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > # service sssd start It works, thanks > > btw also check out this ticket: > https://fedorahosted.org/sssd/ticket/2788 not needing principal switching from/to root for the moment > > > - is there the possibility on IPA 4.1 (the version of our server) to > manage > > the mapping letting the plugin in place, namely to associate or > authorize > > one or multiple service principals with an ipa posix account so that the > > getpwent() works? > > I wonder why the mapping fails, can you invalidate the cache with > sss_cache and try to look up the principal from the command line, using > getent passwd primary REALM ? > Maybe I wasn't clear in describing the setup. I am attempting to log from a local machine as "userA" using the credentials of a "service principal" defined in IPA to a remote machine as "userB" The userB principal is resolvable on the remote host via "getent passwd userB" because it is a user principal. Also the userA principal is resolvable on the local machine, but this should not play a role because the user's credentials are not used for the connection, only the service credentials, as a client. The service principal is not resolvable via "getent passwd" neither on the originating host nor on the destination host. The trick with .k5login is that the service principal used in the connection is granted access as userB because it is listed as one of the principals that correspond to the userB posix account on the remote host. > > - is there a more suitable way to obtain the above delegation and > security > > context switching using other mechanisms supported by IPA? > > > > Thanks in advance > > Stefano From APtashnik at cccis.com Mon Dec 7 17:08:06 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Mon, 7 Dec 2015 17:08:06 +0000 Subject: [Freeipa-users] "DNS resource record not found" error when searching or deleting records Message-ID: Dear Team, I?m trying to remove DNS records from IPA server and getting following error: "ipa: ERROR: webapps001.mz984: DNS resource record not found" I suspect that there was such server "webapps001.mz984" in the past properly added to IPA server via ?spa-client-install? utility , but it was probably crashed and removed from the network without running "ipa-client-install ?uninstall?. I?m able to locate this record via CLI: [root at ipa-idm]# ipa dnsrecord-find 123.xyz.com mz984 Record name: webapps001.mz984 A record: 10.16.9.232 ---------------------------- Number of entries returned 1 ---------------------------- [root at ipa-idm]# This is what happens when I?m trying to delete this record: [root at ipa-idm]# ipa dnsrecord-del 123.xyz.com. webapps001.mz984 --a-rec 10.16.9.232 ipa: ERROR: webapps001.mz984: DNS resource record not found [root at ipa-idm]# This is my DNS zone config: [root at ipa-idm]# ipa dnszone-show 123.xyz.com Zone name: 123.xyz.com. Active zone: TRUE Authoritative nameserver: ipa-idm.123.xyz.com. Administrator e-mail address: hostmaster.123.xyz.com. SOA serial: 1449502971 SOA refresh: 1800 SOA retry: 900 SOA expire: 604800 SOA minimum: 900 Allow query: any; Allow transfer: 10.xxx.xxx.xxx [root at ipa-idm]# [root at ipa-idm]# ipa dnsconfig-show Allow PTR sync: TRUE [root at ipa-idm]# In Web GUI when I?m trying to search for this particular record ?Operations Error? window appears with "DNS resource record not found? error message. Are there any ways to forcefully delete such stalled records or find out the root cause of this error message? Regards, Andrey Ptashnik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Dec 7 17:12:25 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 7 Dec 2015 18:12:25 +0100 Subject: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7 In-Reply-To: <5665BC1E.3@ego-gw.it> References: <5665BC1E.3@ego-gw.it> Message-ID: <20151207171225.GK5290@hendrix.arn.redhat.com> On Mon, Dec 07, 2015 at 06:04:30PM +0100, Stefano Cortese wrote: > >> So the questions are: > >> - is there another cleaner way to exclude the localauth sssd plugin > >> (considering that the configuration snippet is recreated at every sssd > >> restart)? > > > >Can you test if this hack would help: > > # service sssd stop > > # rm /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > > # touch /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > > # chattr +i /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > > # service sssd start > > It works, thanks > > > > >btw also check out this ticket: > > https://fedorahosted.org/sssd/ticket/2788 > not needing principal switching from/to root for the moment Yes, sorry, wrong ticket: https://fedorahosted.org/sssd/ticket/2707 > > > > >> - is there the possibility on IPA 4.1 (the version of our server) to > >manage > >> the mapping letting the plugin in place, namely to associate or > >authorize > >> one or multiple service principals with an ipa posix account so that the > >> getpwent() works? > > > >I wonder why the mapping fails, can you invalidate the cache with > >sss_cache and try to look up the principal from the command line, using > >getent passwd primary REALM ? > > > Maybe I wasn't clear in describing the setup. > > I am attempting to log from a local machine as "userA" using the > credentials of a "service principal" defined in IPA to a remote machine as > "userB" > The userB principal is resolvable on the remote host via "getent passwd > userB" because it is a user principal. > Also the userA principal is resolvable on the local machine, but this should > not play a role because the user's credentials are not used for the > connection, only the service credentials, as a client. > The service principal is not resolvable via "getent passwd" neither on the > originating host nor on the destination host. > The trick with .k5login is that the service principal used in the connection > is granted access as userB because it is listed as one of the principals > that correspond to the userB posix account on the remote host. Thank you, then I think #2707 would help you because you could configure that .k5login is still used. From sbose at redhat.com Mon Dec 7 17:25:22 2015 From: sbose at redhat.com (Sumit Bose) Date: Mon, 7 Dec 2015 18:25:22 +0100 Subject: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7 In-Reply-To: <5665BC1E.3@ego-gw.it> References: <5665BC1E.3@ego-gw.it> Message-ID: <20151207172522.GF16629@p.redhat.com> On Mon, Dec 07, 2015 at 06:04:30PM +0100, Stefano Cortese wrote: > >> So the questions are: > >> - is there another cleaner way to exclude the localauth sssd plugin > >> (considering that the configuration snippet is recreated at every sssd > >> restart)? > > > >Can you test if this hack would help: > > # service sssd stop > > # rm /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > > # touch /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > > # chattr +i /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > > # service sssd start > > It works, thanks Thank you for testing. The steps above disable the creation of the localauth_plugin file by SSSD since the file already exists and is immutable. SSSD tries to write: [plugins] localauth = { module = sssd:/usr/lib/sssd/modules/sssd_krb5_localauth_plugin.so enable_only = sssd } into this file to enable SSSD's localauth plugin. When I wrote the patch for this I guess I over-optimistically added 'enable_only = sssd' which disables all the default schemes available in libkrb5. I wonder if you can create /var/lib/sss/pubconf/krb5.include.d/localauth_plugin with this line missing: [plugins] localauth = { module = sssd:/usr/lib/sssd/modules/sssd_krb5_localauth_plugin.so } and try again? You might need to make it mutable again which 'chattr -i' and after editing it call 'chattr +i' again so the SSSD cannot write it's own version. If the version without 'enable_only = sssd' works for you I think I will prepare a patch for SSSD which does not add this line be default which then should fix your issue and other .k5login related tickets we have in trac. Thank you for for help. bye, Sumit > > > > >btw also check out this ticket: > > https://fedorahosted.org/sssd/ticket/2788 > not needing principal switching from/to root for the moment > > > > >> - is there the possibility on IPA 4.1 (the version of our server) to > >manage > >> the mapping letting the plugin in place, namely to associate or > >authorize > >> one or multiple service principals with an ipa posix account so that the > >> getpwent() works? > > > >I wonder why the mapping fails, can you invalidate the cache with > >sss_cache and try to look up the principal from the command line, using > >getent passwd primary REALM ? > > > Maybe I wasn't clear in describing the setup. > > I am attempting to log from a local machine as "userA" using the > credentials of a "service principal" defined in IPA to a remote machine as > "userB" > The userB principal is resolvable on the remote host via "getent passwd > userB" because it is a user principal. > Also the userA principal is resolvable on the local machine, but this should > not play a role because the user's credentials are not used for the > connection, only the service credentials, as a client. > The service principal is not resolvable via "getent passwd" neither on the > originating host nor on the destination host. > The trick with .k5login is that the service principal used in the connection > is granted access as userB because it is listed as one of the principals > that correspond to the userB posix account on the remote host. > > > >> - is there a more suitable way to obtain the above delegation and > >security > >> context switching using other mechanisms supported by IPA? > >> > >> Thanks in advance > >> Stefano > > -- > 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 From simo at redhat.com Mon Dec 7 17:27:45 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 07 Dec 2015 12:27:45 -0500 Subject: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7 In-Reply-To: <5665BC1E.3@ego-gw.it> References: <5665BC1E.3@ego-gw.it> Message-ID: <1449509265.17418.11.camel@redhat.com> On Mon, 2015-12-07 at 18:04 +0100, Stefano Cortese wrote: > > > So the questions are: > > > - is there another cleaner way to exclude the localauth sssd plugin > > > (considering that the configuration snippet is recreated at every sssd > > > restart)? > > > > Can you test if this hack would help: > > # service sssd stop > > # rm /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > > # touch /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > > # chattr +i /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > > # service sssd start > > It works, thanks > > > > > btw also check out this ticket: > > https://fedorahosted.org/sssd/ticket/2788 > not needing principal switching from/to root for the moment > > > > > > - is there the possibility on IPA 4.1 (the version of our server) to > > manage > > > the mapping letting the plugin in place, namely to associate or > > authorize > > > one or multiple service principals with an ipa posix account so that the > > > getpwent() works? > > > > I wonder why the mapping fails, can you invalidate the cache with > > sss_cache and try to look up the principal from the command line, using > > getent passwd primary REALM ? > > > Maybe I wasn't clear in describing the setup. > > I am attempting to log from a local machine as "userA" using the > credentials of a "service principal" defined in IPA to a remote machine > as "userB" > The userB principal is resolvable on the remote host via "getent passwd > userB" because it is a user principal. > Also the userA principal is resolvable on the local machine, but this > should not play a role because the user's credentials are not used for > the connection, only the service credentials, as a client. > The service principal is not resolvable via "getent passwd" neither on > the originating host nor on the destination host. > The trick with .k5login is that the service principal used in the > connection is granted access as userB because it is listed as one of the > principals that correspond to the userB posix account on the remote host. > > > > > - is there a more suitable way to obtain the above delegation and > > security > > > context switching using other mechanisms supported by IPA? > > > > > > Thanks in advance > > > Stefano FWIW a better way to solve this would be to use constrained delegation, allowing the service principal to obtain the target user credentials. This way you do not allow users to mess with .k5login files (which allows them to permit in an account whoever they please w/o central control. Simo. -- Simo Sorce * Red Hat, Inc * New York From traiano at gmail.com Mon Dec 7 16:38:19 2015 From: traiano at gmail.com (Traiano Welcome) Date: Mon, 7 Dec 2015 19:38:19 +0300 Subject: [Freeipa-users] FreeIPA Clients behind unreliable network links at remote sites In-Reply-To: <20151207090002.GF3399@hendrix.redhat.com> References: <20151207090002.GF3399@hendrix.redhat.com> Message-ID: Hi Jakub On Mon, Dec 7, 2015 at 12:00 PM, Jakub Hrozek wrote: > On Sun, Dec 06, 2015 at 09:58:58PM +0300, Traiano Welcome wrote: >> Hi List >> >> >> Current Scenario: >> ============= >> >> I have a number of stores on really unreliable network connections: >> It's quite possible for the links to have been down for 3 - 4 days at >> a time. >> >> In a given store is a single Linux "Back Office" server running >> Directory 389 which holds credentials for a number of tech support >> usernames. >> There are also a number of point of sale computers running linux which >> authenticate users against the 389 Directory server on the back office >> server. >> The Directory servers in the shops all synch their copy of the >> credential database from a central Directory Server, during normal >> operation. >> >> At some point a support engineer goes to the store to do maintenance >> on the point-of-sale computers and logs in with his Directory 389 >> credentials. >> Since the credential DB almost never changes (usernames and passwords >> stay static), a support technician can generally rely on the >> credentials being "as expected" even if the store has been out of >> contact with the master copy of 389 directory servers: The technician >> can log in to a PoS, do maintenance, even while the network link is in >> the process of being restored. >> >> Desired scenario: >> ============= >> >> I'd like to deploy FreeIPA to these stores, and replace 389 Directory >> server based system running on the Linux. The problem is that the >> point-of-sale machines will frequently lose contact with the primary >> replica, and credentials will timeout. So when the support technician >> walks in and the network link happens to have been down for some time, >> he'll not be able to log in to the point-of-sale computers. >> >> Note: There is no possibility of installing a freeipa replica on the >> Back Office server itself, it's got a whole pile of bespoke Java + >> tomcat crud running on it. There is also no possibility of installing >> an additional FreeIPA replica server in the store itself - the >> economics of the store won't allow it. >> >> Possible solution: >> ============= >> >> I think enabling offline authentication, with credential expiry >> disabled completely may do the trick, with the downside that user >> accounts that have been deleted in the 'main' FreeIPA replica may >> still linger in the store's copy ... >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-cache-cred.html >> >> "offline_credentials_expiration sets the number of days after a >> successful login that a single credentials entry for a user is >> preserved in cache. Setting this to zero (0) means that entries are >> kept forever." >> >> My expectation is that credentials will be updated while connectivity >> is there, but authentication will be possible even in loss of >> connectivity for quite some time. >> >> My question is: Is this the best approach to solving the reliable >> authentication problem, given that the client's may not be able to >> access a FreeIPA replica for long periods of time? Are there any key >> issues I'm overlooking in taking this approach, or possibly better >> approaches? > > I think this should work OK. The clients (SSSD) always try to log in > offline, so as soon as the client would re-establish connection to the > server, the client would check against server's database, otherwise > consult the local cache. > > Just make sure noone removes the sssd database if they think the client > is acting up as a 'troubleshooting', the credentials are cached there > :-) :-) Something to add to the techie training manuals ... > > -- > 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 From m3freak at thesandhufamily.ca Mon Dec 7 17:40:53 2015 From: m3freak at thesandhufamily.ca (Kanwar Ranbir Sandhu) Date: Mon, 07 Dec 2015 12:40:53 -0500 Subject: [Freeipa-users] IP error when creating a replica Message-ID: <1449510053.2531.54.camel@thesandhufamily.ca> Hello Everyone, I'm using IPA on a CentOS 7 box at home (because why not?). I'm running into a problem which so far has stumped me. The host running the IPA master is on the protected LAN subnet (let's call it 1.1.1.1). The replica I'm now trying to setup is running in the "dmz" subnet (this one can be 2.2.2.2). I've opened the required ports between them so they can communicate. When I do the replica install, everything appears to run along smoothly until this happens: [snip] Connection from master to replica is OK. ipa : DEBUG Process finished, return code=0 Connection check OK ipa : DEBUG Starting external process ipa : DEBUG args='/sbin/ip' '-family' 'inet' '-oneline' 'address' 'show' ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout=1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever 2: eth0 inet 2.2.2.2/32 brd 2.2.2.2 scope global eth0\ valid_lft forever preferred_lft forever ipa : DEBUG stderr= ipa : WARNING Invalid IP address 2.2.2.2 for ipa02.thedmzsubnet.dmz: cannot use IP network address Enter the IP address to use, or press Enter to finish. Please provide the IP address to be used for this host name: [snip] Why is this happening? DNS appears to be ok. The replica has the hostname and IP pair in /etc/hosts. The replica is also using the master as its DNS server. Any help is appreciated. -- Ranbir -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mbasti at redhat.com Mon Dec 7 18:39:44 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 7 Dec 2015 19:39:44 +0100 Subject: [Freeipa-users] IP error when creating a replica In-Reply-To: <1449510053.2531.54.camel@thesandhufamily.ca> References: <1449510053.2531.54.camel@thesandhufamily.ca> Message-ID: <5665D270.1030100@redhat.com> On 07.12.2015 18:40, Kanwar Ranbir Sandhu wrote: > Hello Everyone, > > I'm using IPA on a CentOS 7 box at home (because why not?). I'm running > into a problem which so far has stumped me. > > The host running the IPA master is on the protected LAN subnet (let's > call it 1.1.1.1). The replica I'm now trying to setup is running in the > "dmz" subnet (this one can be 2.2.2.2). I've opened the required ports > between them so they can communicate. > > When I do the replica install, everything appears to run along smoothly > until this happens: > > [snip] > > Connection from master to replica is OK. > > ipa : DEBUG Process finished, return code=0 > Connection check OK > ipa : DEBUG Starting external process > ipa : DEBUG args='/sbin/ip' '-family' 'inet' '-oneline' > 'address' 'show' > ipa : DEBUG Process finished, return code=0 > ipa : DEBUG stdout=1: lo inet 127.0.0.1/8 scope host lo\ > valid_lft forever preferred_lft forever > 2: eth0 inet 2.2.2.2/32 brd 2.2.2.2 scope global eth0\ > valid_lft forever preferred_lft forever > > ipa : DEBUG stderr= > ipa : WARNING Invalid IP address 2.2.2.2 for > ipa02.thedmzsubnet.dmz: cannot use IP network address > Enter the IP address to use, or press Enter to finish. > Please provide the IP address to be used for this host name: > > [snip] > > Why is this happening? DNS appears to be ok. The replica has the > hostname and IP pair in /etc/hosts. The replica is also using the > master as its DNS server. > > Any help is appreciated. > > > Hello, IMO 2.2.2.2/32 is why installation is failing, it should be something 2.2.2.2/24, please try to reconfigure your network interface. HTH Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Dec 7 18:45:43 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 7 Dec 2015 19:45:43 +0100 Subject: [Freeipa-users] "DNS resource record not found" error when searching or deleting records In-Reply-To: References: Message-ID: <5665D3D7.1090301@redhat.com> On 07.12.2015 18:08, Andrey Ptashnik wrote: > Dear Team, > > I?m trying to remove DNS records from IPA server and getting following > error: "ipa: ERROR: webapps001.mz984: DNS resource record not found" > I suspect that there was such server "webapps001.mz984" in the past > properly added to IPA server via ?spa-client-install? utility , but it > was probably crashed and removed from the network without running > "ipa-client-install ?uninstall?. > > I?m able to locate this record via CLI: > > [root at ipa-idm]# ipa dnsrecord-find 123.xyz.com mz984 > Record name: webapps001.mz984 > A record: 10.16.9.232 > ---------------------------- > Number of entries returned 1 > ---------------------------- > [root at ipa-idm]# > > This is what happens when I?m trying to delete this record: > > [root at ipa-idm]# ipa dnsrecord-del 123.xyz.com. webapps001.mz984 > --a-rec 10.16.9.232 > ipa: ERROR: webapps001.mz984: DNS resource record not found > [root at ipa-idm]# > > This is my DNS zone config: > > [root at ipa-idm]# ipa dnszone-show 123.xyz.com > Zone name: 123.xyz.com. > Active zone: TRUE > Authoritative nameserver: ipa-idm.123.xyz.com. > Administrator e-mail address: hostmaster.123.xyz.com. > SOA serial: 1449502971 > SOA refresh: 1800 > SOA retry: 900 > SOA expire: 604800 > SOA minimum: 900 > Allow query: any; > Allow transfer: 10.xxx.xxx.xxx > [root at ipa-idm]# > > [root at ipa-idm]# ipa dnsconfig-show > Allow PTR sync: TRUE > [root at ipa-idm]# > > In Web GUI when I?m trying to search for this particular record > ?Operations Error? window appears with "DNS resource record not found? > error message. > > Are there any ways to forcefully delete such stalled records or find > out the root cause of this error message? > > Regards, > > Andrey Ptashnik > > > > Hello, please execute: ipa dnsrecord-find 123.xyz.com mz984 --all --raw I suspect that they might be a replication conflict, I need to see output of command to be sure. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Dec 7 18:46:00 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 7 Dec 2015 13:46:00 -0500 Subject: [Freeipa-users] "DNS resource record not found" error when searching or deleting records In-Reply-To: References: Message-ID: <5665D3E8.3060802@redhat.com> Andrey Ptashnik wrote: > Dear Team, > > I?m trying to remove DNS records from IPA server and getting following > error: "ipa: ERROR: webapps001.mz984: DNS resource record not found" > I suspect that there was such server "webapps001.mz984" in the past > properly added to IPA server via ?spa-client-install? utility , but it > was probably crashed and removed from the network without running > "ipa-client-install ?uninstall?. > > I?m able to locate this record via CLI: > > [root at ipa-idm]# ipa dnsrecord-find 123.xyz.com mz984 > Record name: webapps001.mz984 > A record: 10.16.9.232 > ---------------------------- > Number of entries returned 1 > ---------------------------- > [root at ipa-idm]# > > This is what happens when I?m trying to delete this record: > > [root at ipa-idm]# ipa dnsrecord-del 123.xyz.com. webapps001.mz984 --a-rec > 10.16.9.232 > ipa: ERROR: webapps001.mz984: DNS resource record not found > [root at ipa-idm]# > > This is my DNS zone config: > > [root at ipa-idm]# ipa dnszone-show 123.xyz.com > Zone name: 123.xyz.com. > Active zone: TRUE > Authoritative nameserver: ipa-idm.123.xyz.com. > Administrator e-mail address: hostmaster.123.xyz.com. > SOA serial: 1449502971 > SOA refresh: 1800 > SOA retry: 900 > SOA expire: 604800 > SOA minimum: 900 > Allow query: any; > Allow transfer: 10.xxx.xxx.xxx > [root at ipa-idm]# > > [root at ipa-idm]# ipa dnsconfig-show > Allow PTR sync: TRUE > [root at ipa-idm]# > > In Web GUI when I?m trying to search for this particular record > ?Operations Error? window appears with "DNS resource record not found? > error message. > > Are there any ways to forcefully delete such stalled records or find out > the root cause of this error message? > > Regards, > > Andrey Ptashnik It is probably a replication-conflict entry. See https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html rob From gjn at gjn.priv.at Mon Dec 7 18:58:32 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Mon, 07 Dec 2015 19:58:32 +0100 Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? Message-ID: <3653974.reEb1zf8LJ@techz> Hello, I like to create a ip6.arpa with freeIPA but this is not possible ? I can't found the correct syntax for a IPv6 reverse Zone :-(. I Tested 16 Char x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2 x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa The last is working with named (bind) Can any tell me, is this working or have I link to read a Docu Thanks for a answer FreeIPA Version 4.2.0-15 -- mit freundlichen Gr??en / best regards, G?nther J. Niederwimmer From orion at cora.nwra.com Mon Dec 7 19:11:22 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 7 Dec 2015 12:11:22 -0700 Subject: [Freeipa-users] Issue with ipa 4.2.0 upgrade Message-ID: <5665D9DA.3010900@cora.nwra.com> I just upgraded my SL7 box to ipa-server-4.2.0, but this process appears to have broken ipa. From the ipaupgrade.log: 2015-12-07T17:47:46Z DEBUG Starting external process 2015-12-07T17:47:46Z DEBUG args='/bin/systemctl' 'is-active' 'certmonger.service' 2015-12-07T17:47:46Z DEBUG Process finished, return code=3 2015-12-07T17:47:46Z DEBUG stdout=unknown 2015-12-07T17:47:46Z DEBUG stderr= 2015-12-07T17:47:46Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run com mand ipa-server-upgrade manually. 2015-12-07T17:47:46Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 50, in ru n raise admintool.ScriptError(str(e)) 2015-12-07T17:47:46Z DEBUG The ipa-server-upgrade command failed, exception: ScriptError: Certmon ger is not running. Start certmonger and run upgrade again. 2015-12-07T17:47:46Z ERROR Certmonger is not running. Start certmonger and run upgrade again. I'm running in a CA-less mode and so certmonger is disabled on my system. I started certmonger and was able to complete the upgrade manually, but this looks like a bug in the upgrade script. Sound correct? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From ppicka at redhat.com Mon Dec 7 19:12:54 2015 From: ppicka at redhat.com (Pavel Picka) Date: Mon, 7 Dec 2015 14:12:54 -0500 (EST) Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? In-Reply-To: <3653974.reEb1zf8LJ@techz> References: <3653974.reEb1zf8LJ@techz> Message-ID: <1716142146.32161546.1449515574021.JavaMail.zimbra@redhat.com> Hello for me working if ipv6 address is e.g. 2002::101 so reverse zone will be : 0.2.0.0.2.ip6.arpa you can use more char as you mentioned ( 0.0.0.0.0.2.0.0.2.ip6.arpa will still be reverse for ip 2002::101 ) so if your IP start 2001:: have reverse 2.0.0.1.ip6.arpa hope it helps ----- Original Message ----- From: "G?nther J. Niederwimmer" To: freeipa-users at redhat.com Sent: Monday, December 7, 2015 7:58:32 PM Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? Hello, I like to create a ip6.arpa with freeIPA but this is not possible ? I can't found the correct syntax for a IPv6 reverse Zone :-(. I Tested 16 Char x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2 x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa The last is working with named (bind) Can any tell me, is this working or have I link to read a Docu Thanks for a answer FreeIPA Version 4.2.0-15 -- mit freundlichen Gr??en / best regards, G?nther J. Niederwimmer -- 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 From rcritten at redhat.com Mon Dec 7 19:17:18 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 7 Dec 2015 14:17:18 -0500 Subject: [Freeipa-users] Issue with ipa 4.2.0 upgrade In-Reply-To: <5665D9DA.3010900@cora.nwra.com> References: <5665D9DA.3010900@cora.nwra.com> Message-ID: <5665DB3E.60605@redhat.com> Orion Poplawski wrote: > I just upgraded my SL7 box to ipa-server-4.2.0, but this process appears to > have broken ipa. From the ipaupgrade.log: > > 2015-12-07T17:47:46Z DEBUG Starting external process > 2015-12-07T17:47:46Z DEBUG args='/bin/systemctl' 'is-active' 'certmonger.service' > 2015-12-07T17:47:46Z DEBUG Process finished, return code=3 > 2015-12-07T17:47:46Z DEBUG stdout=unknown > > 2015-12-07T17:47:46Z DEBUG stderr= > 2015-12-07T17:47:46Z ERROR IPA server upgrade failed: Inspect > /var/log/ipaupgrade.log and run com > mand ipa-server-upgrade manually. > 2015-12-07T17:47:46Z DEBUG File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line > 171, in execute > return_value = self.run() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", > line 50, in ru > n > raise admintool.ScriptError(str(e)) > > 2015-12-07T17:47:46Z DEBUG The ipa-server-upgrade command failed, exception: > ScriptError: Certmon > ger is not running. Start certmonger and run upgrade again. > 2015-12-07T17:47:46Z ERROR Certmonger is not running. Start certmonger and run > upgrade again. > > I'm running in a CA-less mode and so certmonger is disabled on my system. I > started certmonger and was able to complete the upgrade manually, but this > looks like a bug in the upgrade script. Sound correct? Sounds like it to me. rob From APtashnik at cccis.com Mon Dec 7 19:19:51 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Mon, 7 Dec 2015 19:19:51 +0000 Subject: [Freeipa-users] "DNS resource record not found" error when searching or deleting records In-Reply-To: <5665D3D7.1090301@redhat.com> References: <5665D3D7.1090301@redhat.com> Message-ID: <554C8CBB-4ADB-454E-8F04-267C3EFA7AE0@cccis.com> Martin, Here is the output you requested: [root at ipa-idm]# ipa dnsrecord-find 123.xyz.com mz984 --all --raw dn: idnsName=webapps001.mz984+nsuniqueid=650db4bc-88c511e5-90e7864e-76f6b2c3,idnsname=123.xyz.com.,cn=dns,dc=123,dc=xyz,dc=com idnsname: webapps001.mz984 arecord: 10.16.9.232 dNSTTL: 1200 objectClass: idnsRecord objectClass: top ---------------------------- Number of entries returned 1 ---------------------------- [root at ipa-idm]# Regards, Andrey Ptashnik From: Martin Basti > Date: Monday, December 7, 2015 at 12:45 PM To: Andrey Ptashnik >, "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] "DNS resource record not found" error when searching or deleting records On 07.12.2015 18:08, Andrey Ptashnik wrote: Dear Team, I?m trying to remove DNS records from IPA server and getting following error: "ipa: ERROR: webapps001.mz984: DNS resource record not found" I suspect that there was such server "webapps001.mz984" in the past properly added to IPA server via ?spa-client-install? utility , but it was probably crashed and removed from the network without running "ipa-client-install ?uninstall?. I?m able to locate this record via CLI: [root at ipa-idm]# ipa dnsrecord-find 123.xyz.com mz984 Record name: webapps001.mz984 A record: 10.16.9.232 ---------------------------- Number of entries returned 1 ---------------------------- [root at ipa-idm]# This is what happens when I?m trying to delete this record: [root at ipa-idm]# ipa dnsrecord-del 123.xyz.com. webapps001.mz984 --a-rec 10.16.9.232 ipa: ERROR: webapps001.mz984: DNS resource record not found [root at ipa-idm]# This is my DNS zone config: [root at ipa-idm]# ipa dnszone-show 123.xyz.com Zone name: 123.xyz.com. Active zone: TRUE Authoritative nameserver: ipa-idm.123.xyz.com. Administrator e-mail address: hostmaster.123.xyz.com. SOA serial: 1449502971 SOA refresh: 1800 SOA retry: 900 SOA expire: 604800 SOA minimum: 900 Allow query: any; Allow transfer: 10.xxx.xxx.xxx [root at ipa-idm]# [root at ipa-idm]# ipa dnsconfig-show Allow PTR sync: TRUE [root at ipa-idm]# In Web GUI when I?m trying to search for this particular record ?Operations Error? window appears with "DNS resource record not found? error message. Are there any ways to forcefully delete such stalled records or find out the root cause of this error message? Regards, Andrey Ptashnik Hello, please execute: ipa dnsrecord-find 123.xyz.com mz984 --all --raw I suspect that they might be a replication conflict, I need to see output of command to be sure. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Dec 7 19:24:57 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 7 Dec 2015 20:24:57 +0100 Subject: [Freeipa-users] "DNS resource record not found" error when searching or deleting records In-Reply-To: <554C8CBB-4ADB-454E-8F04-267C3EFA7AE0@cccis.com> References: <5665D3D7.1090301@redhat.com> <554C8CBB-4ADB-454E-8F04-267C3EFA7AE0@cccis.com> Message-ID: <5665DD09.3000709@redhat.com> Yes, it is replication conflict. Please follow: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html On 07.12.2015 20:19, Andrey Ptashnik wrote: > Martin, > > Here is the output you requested: > > [root at ipa-idm]# ipa dnsrecord-find 123.xyz.com mz984 --all --raw > dn: > idnsName=webapps001.mz984+nsuniqueid=650db4bc-88c511e5-90e7864e-76f6b2c3,idnsname=123.xyz.com.,cn=dns,dc=123,dc=xyz,dc=com > idnsname: webapps001.mz984 > arecord: 10.16.9.232 > dNSTTL: 1200 > objectClass: idnsRecord > objectClass: top > ---------------------------- > Number of entries returned 1 > ---------------------------- > [root at ipa-idm]# > > Regards, > > Andrey Ptashnik > > > From: Martin Basti > > Date: Monday, December 7, 2015 at 12:45 PM > To: Andrey Ptashnik >, "freeipa-users at redhat.com > " > > Subject: Re: [Freeipa-users] "DNS resource record not found" error > when searching or deleting records > > > > On 07.12.2015 18:08, Andrey Ptashnik wrote: >> Dear Team, >> >> I?m trying to remove DNS records from IPA server and getting >> following error: "ipa: ERROR: webapps001.mz984: DNS resource record >> not found" >> I suspect that there was such server "webapps001.mz984" in the past >> properly added to IPA server via ?spa-client-install? utility , but >> it was probably crashed and removed from the network without running >> "ipa-client-install ?uninstall?. >> >> I?m able to locate this record via CLI: >> >> [root at ipa-idm]# ipa dnsrecord-find 123.xyz.com mz984 >> Record name: webapps001.mz984 >> A record: 10.16.9.232 >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> [root at ipa-idm]# >> >> This is what happens when I?m trying to delete this record: >> >> [root at ipa-idm]# ipa dnsrecord-del 123.xyz.com. webapps001.mz984 >> --a-rec 10.16.9.232 >> ipa: ERROR: webapps001.mz984: DNS resource record not found >> [root at ipa-idm]# >> >> This is my DNS zone config: >> >> [root at ipa-idm]# ipa dnszone-show 123.xyz.com >> Zone name: 123.xyz.com. >> Active zone: TRUE >> Authoritative nameserver: ipa-idm.123.xyz.com. >> Administrator e-mail address: hostmaster.123.xyz.com. >> SOA serial: 1449502971 >> SOA refresh: 1800 >> SOA retry: 900 >> SOA expire: 604800 >> SOA minimum: 900 >> Allow query: any; >> Allow transfer: 10.xxx.xxx.xxx >> [root at ipa-idm]# >> >> [root at ipa-idm]# ipa dnsconfig-show >> Allow PTR sync: TRUE >> [root at ipa-idm]# >> >> In Web GUI when I?m trying to search for this particular record >> ?Operations Error? window appears with "DNS resource record not >> found? error message. >> >> Are there any ways to forcefully delete such stalled records or find >> out the root cause of this error message? >> >> Regards, >> >> Andrey Ptashnik >> >> >> >> > Hello, > > please execute: > ipa dnsrecord-find 123.xyz.com mz984 --all --raw > > I suspect that they might be a replication conflict, I need to see > output of command to be sure. > > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From APtashnik at cccis.com Mon Dec 7 19:27:46 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Mon, 7 Dec 2015 19:27:46 +0000 Subject: [Freeipa-users] "DNS resource record not found" error when searching or deleting records In-Reply-To: <5665DD09.3000709@redhat.com> References: <5665D3D7.1090301@redhat.com> <554C8CBB-4ADB-454E-8F04-267C3EFA7AE0@cccis.com> <5665DD09.3000709@redhat.com> Message-ID: Martin, For my education, how did you identify that from my output? Regards, Andrey Ptashnik From: Martin Basti > Date: Monday, December 7, 2015 at 1:24 PM To: Andrey Ptashnik >, "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] "DNS resource record not found" error when searching or deleting records Yes, it is replication conflict. Please follow: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html On 07.12.2015 20:19, Andrey Ptashnik wrote: Martin, Here is the output you requested: [root at ipa-idm]# ipa dnsrecord-find 123.xyz.com mz984 --all --raw dn: idnsName=webapps001.mz984+nsuniqueid=650db4bc-88c511e5-90e7864e-76f6b2c3,idnsname=123.xyz.com.,cn=dns,dc=123,dc=xyz,dc=com idnsname: webapps001.mz984 arecord: 10.16.9.232 dNSTTL: 1200 objectClass: idnsRecord objectClass: top ---------------------------- Number of entries returned 1 ---------------------------- [root at ipa-idm]# Regards, Andrey Ptashnik From: Martin Basti <mbasti at redhat.com> Date: Monday, December 7, 2015 at 12:45 PM To: Andrey Ptashnik >, "freeipa-users at redhat.com" > Subject: Re: [Freeipa-users] "DNS resource record not found" error when searching or deleting records On 07.12.2015 18:08, Andrey Ptashnik wrote: Dear Team, I?m trying to remove DNS records from IPA server and getting following error: "ipa: ERROR: webapps001.mz984: DNS resource record not found" I suspect that there was such server "webapps001.mz984" in the past properly added to IPA server via ?spa-client-install? utility , but it was probably crashed and removed from the network without running "ipa-client-install ?uninstall?. I?m able to locate this record via CLI: [root at ipa-idm]# ipa dnsrecord-find 123.xyz.com mz984 Record name: webapps001.mz984 A record: 10.16.9.232 ---------------------------- Number of entries returned 1 ---------------------------- [root at ipa-idm]# This is what happens when I?m trying to delete this record: [root at ipa-idm]# ipa dnsrecord-del 123.xyz.com. webapps001.mz984 --a-rec 10.16.9.232 ipa: ERROR: webapps001.mz984: DNS resource record not found [root at ipa-idm]# This is my DNS zone config: [root at ipa-idm]# ipa dnszone-show 123.xyz.com Zone name: 123.xyz.com. Active zone: TRUE Authoritative nameserver: ipa-idm.123.xyz.com. Administrator e-mail address: hostmaster.123.xyz.com. SOA serial: 1449502971 SOA refresh: 1800 SOA retry: 900 SOA expire: 604800 SOA minimum: 900 Allow query: any; Allow transfer: 10.xxx.xxx.xxx [root at ipa-idm]# [root at ipa-idm]# ipa dnsconfig-show Allow PTR sync: TRUE [root at ipa-idm]# In Web GUI when I?m trying to search for this particular record ?Operations Error? window appears with "DNS resource record not found? error message. Are there any ways to forcefully delete such stalled records or find out the root cause of this error message? Regards, Andrey Ptashnik Hello, please execute: ipa dnsrecord-find 123.xyz.com mz984 --all --raw I suspect that they might be a replication conflict, I need to see output of command to be sure. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Dec 7 19:30:16 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 7 Dec 2015 14:30:16 -0500 Subject: [Freeipa-users] "DNS resource record not found" error when searching or deleting records In-Reply-To: References: <5665D3D7.1090301@redhat.com> <554C8CBB-4ADB-454E-8F04-267C3EFA7AE0@cccis.com> <5665DD09.3000709@redhat.com> Message-ID: <5665DE48.3040903@redhat.com> Andrey Ptashnik wrote: > Martin, > > For my education, how did you identify that from my output? The +nsuniqueid= in the dn. When managing entries in IPA it constructs the DN based on the values provided which is why you got a notfound for webapps001.mz984, because it literally doesn't exist. It has a +nsuniqueid appended to it. There are plans to make conflict resolution simpler and more obvious. rob > > Regards, > > Andrey Ptashnik > > > From: Martin Basti > > Date: Monday, December 7, 2015 at 1:24 PM > To: Andrey Ptashnik >, > "freeipa-users at redhat.com " > > > Subject: Re: [Freeipa-users] "DNS resource record not found" error when > searching or deleting records > > Yes, it is replication conflict. > > Please follow: > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > > On 07.12.2015 20:19, Andrey Ptashnik wrote: >> Martin, >> >> Here is the output you requested: >> >> [root at ipa-idm]# ipa dnsrecord-find 123.xyz.com mz984 --all --raw >> dn: >> idnsName=webapps001.mz984+nsuniqueid=650db4bc-88c511e5-90e7864e-76f6b2c3,idnsname=123.xyz.com.,cn=dns,dc=123,dc=xyz,dc=com >> idnsname: webapps001.mz984 >> arecord: 10.16.9.232 >> dNSTTL: 1200 >> objectClass: idnsRecord >> objectClass: top >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> [root at ipa-idm]# >> >> Regards, >> >> Andrey Ptashnik >> >> >> From: Martin Basti <mbasti at redhat.com> >> Date: Monday, December 7, 2015 at 12:45 PM >> To: Andrey Ptashnik > >, "freeipa-users at redhat.com >> " > > >> Subject: Re: [Freeipa-users] "DNS resource record not found" error >> when searching or deleting records >> >> >> >> On 07.12.2015 18:08, Andrey Ptashnik wrote: >>> Dear Team, >>> >>> I?m trying to remove DNS records from IPA server and getting >>> following error: "ipa: ERROR: webapps001.mz984: DNS resource record >>> not found" >>> I suspect that there was such server "webapps001.mz984" in the past >>> properly added to IPA server via ?spa-client-install? utility , but >>> it was probably crashed and removed from the network without running >>> "ipa-client-install ?uninstall?. >>> >>> I?m able to locate this record via CLI: >>> >>> [root at ipa-idm]# ipa dnsrecord-find 123.xyz.com mz984 >>> Record name: webapps001.mz984 >>> A record: 10.16.9.232 >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> [root at ipa-idm]# >>> >>> This is what happens when I?m trying to delete this record: >>> >>> [root at ipa-idm]# ipa dnsrecord-del 123.xyz.com. webapps001.mz984 >>> --a-rec 10.16.9.232 >>> ipa: ERROR: webapps001.mz984: DNS resource record not found >>> [root at ipa-idm]# >>> >>> This is my DNS zone config: >>> >>> [root at ipa-idm]# ipa dnszone-show 123.xyz.com >>> Zone name: 123.xyz.com. >>> Active zone: TRUE >>> Authoritative nameserver: ipa-idm.123.xyz.com. >>> Administrator e-mail address: hostmaster.123.xyz.com. >>> SOA serial: 1449502971 >>> SOA refresh: 1800 >>> SOA retry: 900 >>> SOA expire: 604800 >>> SOA minimum: 900 >>> Allow query: any; >>> Allow transfer: 10.xxx.xxx.xxx >>> [root at ipa-idm]# >>> >>> [root at ipa-idm]# ipa dnsconfig-show >>> Allow PTR sync: TRUE >>> [root at ipa-idm]# >>> >>> In Web GUI when I?m trying to search for this particular record >>> ?Operations Error? window appears with "DNS resource record not >>> found? error message. >>> >>> Are there any ways to forcefully delete such stalled records or find >>> out the root cause of this error message? >>> >>> Regards, >>> >>> Andrey Ptashnik >>> >>> >>> >>> >> Hello, >> >> please execute: >> ipa dnsrecord-find 123.xyz.com mz984 --all --raw >> >> I suspect that they might be a replication conflict, I need to see >> output of command to be sure. >> >> Martin > > > From jhrozek at redhat.com Mon Dec 7 19:32:48 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 7 Dec 2015 20:32:48 +0100 Subject: [Freeipa-users] FreeIPA Clients behind unreliable network links at remote sites In-Reply-To: <20151207090002.GF3399@hendrix.redhat.com> References: <20151207090002.GF3399@hendrix.redhat.com> Message-ID: <20151207193248.GA3086@hendrix> On Mon, Dec 07, 2015 at 10:00:02AM +0100, Jakub Hrozek wrote: > On Sun, Dec 06, 2015 at 09:58:58PM +0300, Traiano Welcome wrote: > > Hi List > > > > > > Current Scenario: > > ============= > > > > I have a number of stores on really unreliable network connections: > > It's quite possible for the links to have been down for 3 - 4 days at > > a time. > > > > In a given store is a single Linux "Back Office" server running > > Directory 389 which holds credentials for a number of tech support > > usernames. > > There are also a number of point of sale computers running linux which > > authenticate users against the 389 Directory server on the back office > > server. > > The Directory servers in the shops all synch their copy of the > > credential database from a central Directory Server, during normal > > operation. > > > > At some point a support engineer goes to the store to do maintenance > > on the point-of-sale computers and logs in with his Directory 389 > > credentials. > > Since the credential DB almost never changes (usernames and passwords > > stay static), a support technician can generally rely on the > > credentials being "as expected" even if the store has been out of > > contact with the master copy of 389 directory servers: The technician > > can log in to a PoS, do maintenance, even while the network link is in > > the process of being restored. > > > > Desired scenario: > > ============= > > > > I'd like to deploy FreeIPA to these stores, and replace 389 Directory > > server based system running on the Linux. The problem is that the > > point-of-sale machines will frequently lose contact with the primary > > replica, and credentials will timeout. So when the support technician > > walks in and the network link happens to have been down for some time, > > he'll not be able to log in to the point-of-sale computers. > > > > Note: There is no possibility of installing a freeipa replica on the > > Back Office server itself, it's got a whole pile of bespoke Java + > > tomcat crud running on it. There is also no possibility of installing > > an additional FreeIPA replica server in the store itself - the > > economics of the store won't allow it. > > > > Possible solution: > > ============= > > > > I think enabling offline authentication, with credential expiry > > disabled completely may do the trick, with the downside that user > > accounts that have been deleted in the 'main' FreeIPA replica may > > still linger in the store's copy ... > > > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-cache-cred.html > > > > "offline_credentials_expiration sets the number of days after a > > successful login that a single credentials entry for a user is > > preserved in cache. Setting this to zero (0) means that entries are > > kept forever." > > > > My expectation is that credentials will be updated while connectivity > > is there, but authentication will be possible even in loss of > > connectivity for quite some time. > > > > My question is: Is this the best approach to solving the reliable > > authentication problem, given that the client's may not be able to > > access a FreeIPA replica for long periods of time? Are there any key > > issues I'm overlooking in taking this approach, or possibly better > > approaches? > > I think this should work OK. The clients (SSSD) always try to log in > offline, so as soon as the client would re-establish connection to the ~~~~~~~ Of course I meant to say online here.. > server, the client would check against server's database, otherwise > consult the local cache. > > Just make sure noone removes the sssd database if they think the client > is acting up as a 'troubleshooting', the credentials are cached there > :-) > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From mbasti at redhat.com Mon Dec 7 19:41:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 7 Dec 2015 20:41:29 +0100 Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? In-Reply-To: <1716142146.32161546.1449515574021.JavaMail.zimbra@redhat.com> References: <3653974.reEb1zf8LJ@techz> <1716142146.32161546.1449515574021.JavaMail.zimbra@redhat.com> Message-ID: <5665E0E9.5090506@redhat.com> On 07.12.2015 20:12, Pavel Picka wrote: > Hello > > for me working if ipv6 address is e.g. 2002::101 so reverse zone will be : > > 0.2.0.0.2.ip6.arpa > > you can use more char as you mentioned ( 0.0.0.0.0.2.0.0.2.ip6.arpa will still be reverse for ip 2002::101 ) > > so if your IP start 2001:: have reverse 2.0.0.1.ip6.arpa Nope. reverse zone of 2001::/16 is 1.0.0.2.ip6.arpa Martin > > hope it helps > > ----- Original Message ----- > From: "G?nther J. Niederwimmer" > To: freeipa-users at redhat.com > Sent: Monday, December 7, 2015 7:58:32 PM > Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? > > Hello, > > I like to create a ip6.arpa with freeIPA but this is not possible ? I can't > found the correct syntax for a IPv6 reverse Zone :-(. > I Tested > > 16 Char > x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2 > x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa > > The last is working with named (bind) > > Can any tell me, is this working or have I link to read a Docu > > Thanks for a answer > > FreeIPA Version 4.2.0-15 From Jeff.Sauls at photomask.com Mon Dec 7 20:04:26 2015 From: Jeff.Sauls at photomask.com (Sauls, Jeff) Date: Mon, 7 Dec 2015 14:04:26 -0600 Subject: [Freeipa-users] HBAC access denied, all AD groups not detected In-Reply-To: <20151207085922.GD3399@hendrix.redhat.com> References: <20151207085922.GD3399@hendrix.redhat.com> Message-ID: > Jakub Hrozek wrote: > > On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote: > > Hello, > > > > We are having a problem with HBAC that appears to be related to group > > membership lookup. I am testing with a new install on RHEL 7.2 with a > > cross-forest trust with AD. When an AD user attempts to log into a > > client (RH 6.7 or 7.2) the "hbac_eval_user_element" can report a > > different number of groups each time and never seems to contain the full list. > > For the testing account, running the 'id' command returns 153 groups. > > The ipa group "ad_admin" has setup to be able to log in anywhere, > > everyone else is denied. With the default allow_all rule enabled, > > everything works as expected. Any ideas on where I can look next? > > I assume the group membership is OK on the server, but not the client? Can you > enable debugging and also include the full logs from the client after doing > sss_cache -E on the client? I've done some more testing and installed a RHEL 6.6 client, the issue doesn't occur there since it is not pulling in AD groups, it only shows the single POSIX group. The server is running 7.2 and I get the same issue logging into it. This is the log section for a login that failed due to "Access denied by HBAC rules" http://pastebin.com/paiBjG96 It shows it failing with 112 groups, but I've had it pass at 113 and fail on another user at 66. From m3freak at thesandhufamily.ca Mon Dec 7 20:24:43 2015 From: m3freak at thesandhufamily.ca (Ranbir) Date: Mon, 07 Dec 2015 15:24:43 -0500 Subject: [Freeipa-users] IP error when creating a replica In-Reply-To: <5665D270.1030100@redhat.com> References: <1449510053.2531.54.camel@thesandhufamily.ca> <5665D270.1030100@redhat.com> Message-ID: <1449519883.2531.56.camel@thesandhufamily.ca> On Mon, 2015-12-07 at 19:39 +0100, Martin Basti wrote: > IMO 2.2.2.2/32 is why installation is failing, it should be something > 2.2.2.2/24, please try to reconfigure your network interface. Wow - I can't believe I missed the /32. I don't know _why_ the netmask was set to /32, but after changing it to /24 (which is what I thought it was), the replica install completed successfully. Thanks for pointing it out, Martin! -- Ranbir -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From gjn at gjn.priv.at Mon Dec 7 20:26:36 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Mon, 07 Dec 2015 21:26:36 +0100 Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? In-Reply-To: <5665E0E9.5090506@redhat.com> References: <3653974.reEb1zf8LJ@techz> <1716142146.32161546.1449515574021.JavaMail.zimbra@redhat.com> <5665E0E9.5090506@redhat.com> Message-ID: <3086889.g4U8V0LaX9@techz> Am Monday 07 December 2015, 20:41:29 schrieb Martin Basti: > On 07.12.2015 20:12, Pavel Picka wrote: > > Hello > > > > for me working if ipv6 address is e.g. 2002::101 so reverse zone will be : > > > > 0.2.0.0.2.ip6.arpa > > > > you can use more char as you mentioned ( 0.0.0.0.0.2.0.0.2.ip6.arpa will > > still be reverse for ip 2002::101 ) I tested also more chars ? > > so if your IP start 2001:: have reverse 2.0.0.1.ip6.arpa > > Nope. > > reverse zone of 2001::/16 is 1.0.0.2.ip6.arpa Is there a command line syntax for adding a reverse Zone, in the web Formula it is not possible to insert a reverse IPv6 zone. I have only the Message this is a wrong IP Address. > > hope it helps > > > > ----- Original Message ----- > > From: "G?nther J. Niederwimmer" > > To: freeipa-users at redhat.com > > Sent: Monday, December 7, 2015 7:58:32 PM > > Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? > > > > Hello, > > > > I like to create a ip6.arpa with freeIPA but this is not possible ? I > > can't > > found the correct syntax for a IPv6 reverse Zone :-(. > > I Tested > > > > 16 Char > > x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2 > > x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa > > > > The last is working with named (bind) > > > > Can any tell me, is this working or have I link to read a Docu > > > > Thanks for a answer > > > > FreeIPA Version 4.2.0-15 -- mit freundlichen Gr??en / best regards, G?nther J. Niederwimmer From orion at cora.nwra.com Mon Dec 7 20:46:34 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 7 Dec 2015 13:46:34 -0700 Subject: [Freeipa-users] Issue with ipa 4.2.0 upgrade In-Reply-To: <5665DB3E.60605@redhat.com> References: <5665D9DA.3010900@cora.nwra.com> <5665DB3E.60605@redhat.com> Message-ID: <5665F02A.2010402@cora.nwra.com> On 12/07/2015 12:17 PM, Rob Crittenden wrote: > Orion Poplawski wrote: >> I just upgraded my SL7 box to ipa-server-4.2.0, but this process appears to >> have broken ipa. From the ipaupgrade.log: >> >> 2015-12-07T17:47:46Z DEBUG Starting external process >> 2015-12-07T17:47:46Z DEBUG args='/bin/systemctl' 'is-active' 'certmonger.service' >> 2015-12-07T17:47:46Z DEBUG Process finished, return code=3 >> 2015-12-07T17:47:46Z DEBUG stdout=unknown >> >> 2015-12-07T17:47:46Z DEBUG stderr= >> 2015-12-07T17:47:46Z ERROR IPA server upgrade failed: Inspect >> /var/log/ipaupgrade.log and run com >> mand ipa-server-upgrade manually. >> 2015-12-07T17:47:46Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line >> 171, in execute >> return_value = self.run() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", >> line 50, in ru >> n >> raise admintool.ScriptError(str(e)) >> >> 2015-12-07T17:47:46Z DEBUG The ipa-server-upgrade command failed, exception: >> ScriptError: Certmon >> ger is not running. Start certmonger and run upgrade again. >> 2015-12-07T17:47:46Z ERROR Certmonger is not running. Start certmonger and run >> upgrade again. >> >> I'm running in a CA-less mode and so certmonger is disabled on my system. I >> started certmonger and was able to complete the upgrade manually, but this >> looks like a bug in the upgrade script. Sound correct? > > Sounds like it to me. > > rob Reported: https://fedorahosted.org/freeipa/ticket/5519 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From jhrozek at redhat.com Mon Dec 7 20:52:20 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 7 Dec 2015 21:52:20 +0100 Subject: [Freeipa-users] HBAC access denied, all AD groups not detected In-Reply-To: References: <20151207085922.GD3399@hendrix.redhat.com> Message-ID: <20151207205220.GB3086@hendrix> On Mon, Dec 07, 2015 at 02:04:26PM -0600, Sauls, Jeff wrote: > > Jakub Hrozek wrote: > > > > On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote: > > > Hello, > > > > > > We are having a problem with HBAC that appears to be related to group > > > membership lookup. I am testing with a new install on RHEL 7.2 with a > > > cross-forest trust with AD. When an AD user attempts to log into a > > > client (RH 6.7 or 7.2) the "hbac_eval_user_element" can report a > > > different number of groups each time and never seems to contain the full list. > > > For the testing account, running the 'id' command returns 153 groups. > > > The ipa group "ad_admin" has setup to be able to log in anywhere, > > > everyone else is denied. With the default allow_all rule enabled, > > > everything works as expected. Any ideas on where I can look next? > > > > I assume the group membership is OK on the server, but not the client? Can you > > enable debugging and also include the full logs from the client after doing > > sss_cache -E on the client? > > I've done some more testing and installed a RHEL 6.6 client, the issue doesn't occur there since it is not pulling in AD groups, it only shows the single POSIX group. The server is running 7.2 and I get the same issue logging into it. To make sure I understand -- the group you expect to be returned on the server is not either? So there is a consistent failure on the server as well? (It's important to see where the failure is, the server and the client use different methods to obtain the group memberships. The server talks directly to the AD, the clients talk to the server) > > This is the log section for a login that failed due to "Access denied by HBAC rules" http://pastebin.com/paiBjG96 > It shows it failing with 112 groups, but I've had it pass at 113 and fail on another user at 66. > > > -- > 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 From mbasti at redhat.com Mon Dec 7 21:46:45 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 7 Dec 2015 22:46:45 +0100 Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? In-Reply-To: <3086889.g4U8V0LaX9@techz> References: <3653974.reEb1zf8LJ@techz> <1716142146.32161546.1449515574021.JavaMail.zimbra@redhat.com> <5665E0E9.5090506@redhat.com> <3086889.g4U8V0LaX9@techz> Message-ID: <5665FE45.2030203@redhat.com> On 07.12.2015 21:26, G?nther J. Niederwimmer wrote: > Am Monday 07 December 2015, 20:41:29 schrieb Martin Basti: >> On 07.12.2015 20:12, Pavel Picka wrote: >>> Hello >>> >>> for me working if ipv6 address is e.g. 2002::101 so reverse zone will be : >>> >>> 0.2.0.0.2.ip6.arpa >>> >>> you can use more char as you mentioned ( 0.0.0.0.0.2.0.0.2.ip6.arpa will >>> still be reverse for ip 2002::101 ) > I tested also more chars ? > >>> so if your IP start 2001:: have reverse 2.0.0.1.ip6.arpa >> Nope. >> >> reverse zone of 2001::/16 is 1.0.0.2.ip6.arpa > > Is there a command line syntax for adding a reverse Zone, in the web Formula > it is not possible to insert a reverse IPv6 zone. I have only the Message this > is a wrong IP Address. It should work in webUI. Did you write ipv6 address with prefix? (2001:db8::/32) ? Martin >>> hope it helps >>> >>> ----- Original Message ----- >>> From: "G?nther J. Niederwimmer" >>> To: freeipa-users at redhat.com >>> Sent: Monday, December 7, 2015 7:58:32 PM >>> Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? >>> >>> Hello, >>> >>> I like to create a ip6.arpa with freeIPA but this is not possible ? I >>> can't >>> found the correct syntax for a IPv6 reverse Zone :-(. >>> I Tested >>> >>> 16 Char >>> x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2 >>> x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa >>> >>> The last is working with named (bind) >>> >>> Can any tell me, is this working or have I link to read a Docu >>> >>> Thanks for a answer >>> >>> FreeIPA Version 4.2.0-15 From mbasti at redhat.com Mon Dec 7 21:48:22 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 7 Dec 2015 22:48:22 +0100 Subject: [Freeipa-users] IP error when creating a replica [solved] In-Reply-To: <1449519883.2531.56.camel@thesandhufamily.ca> References: <1449510053.2531.54.camel@thesandhufamily.ca> <5665D270.1030100@redhat.com> <1449519883.2531.56.camel@thesandhufamily.ca> Message-ID: <5665FEA6.6050500@redhat.com> On 07.12.2015 21:24, Ranbir wrote: > On Mon, 2015-12-07 at 19:39 +0100, Martin Basti wrote: >> IMO 2.2.2.2/32 is why installation is failing, it should be something >> 2.2.2.2/24, please try to reconfigure your network interface. > Wow - I can't believe I missed the /32. I don't know _why_ the netmask > was set to /32, but after changing it to /24 (which is what I thought > it was), the replica install completed successfully. > > Thanks for pointing it out, Martin! > > You are welcome. From schogan at us.ibm.com Mon Dec 7 22:09:08 2015 From: schogan at us.ibm.com (Sean Hogan) Date: Mon, 7 Dec 2015 15:09:08 -0700 Subject: [Freeipa-users] Ldap search for enrolled boxes Message-ID: Hello, Does anyone have a ldapsearch syntax that will check the database for all enrolled hosts within IPA and ignore non-enrolled hosts? I am not familiar enough with the schema yet to know which containers contain what. I know there is a flag on the gui for enrolled or not so thinking its doable. Also.. any recommendations on a ldap query tool for use with IPA? Sean Hogan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 08210753.jpg Type: image/jpeg Size: 27085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 08860780.gif Type: image/gif Size: 1650 bytes Desc: not available URL: From rcritten at redhat.com Mon Dec 7 22:30:30 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 7 Dec 2015 17:30:30 -0500 Subject: [Freeipa-users] Ldap search for enrolled boxes In-Reply-To: References: Message-ID: <56660886.8050602@redhat.com> Sean Hogan wrote: > Hello, > > Does anyone have a ldapsearch syntax that will check the database for > all enrolled hosts within IPA and ignore non-enrolled hosts? I am not > familiar enough with the schema yet to know which containers contain > what. I know there is a flag on the gui for enrolled or not so thinking > its doable. Also.. any recommendations on a ldap query tool for use with > IPA? $ kinit admin $ ldapsearch -Y GSSAPI -b cn=computers,cn=accounts,dc=example,dc=com "krbprincipalkey=*" dn Any ldap query tool should work with IPA. rob From gjn at gjn.priv.at Tue Dec 8 11:52:09 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Tue, 08 Dec 2015 12:52:09 +0100 Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? In-Reply-To: <5665FE45.2030203@redhat.com> References: <3653974.reEb1zf8LJ@techz> <3086889.g4U8V0LaX9@techz> <5665FE45.2030203@redhat.com> Message-ID: <5578037.ydOcxGNYcb@techz> Hello, Am Monday 07 December 2015, 22:46:45 schrieb Martin Basti: > On 07.12.2015 21:26, G?nther J. Niederwimmer wrote: > > Am Monday 07 December 2015, 20:41:29 schrieb Martin Basti: > >> On 07.12.2015 20:12, Pavel Picka wrote: > >>> Hello > >>> > >>> for me working if ipv6 address is e.g. 2002::101 so reverse zone will be > >>> : > >>> > >>> 0.2.0.0.2.ip6.arpa > >>> > >>> you can use more char as you mentioned ( 0.0.0.0.0.2.0.0.2.ip6.arpa will > >>> still be reverse for ip 2002::101 ) > > > > I tested also more chars ? > > > >>> so if your IP start 2001:: have reverse 2.0.0.1.ip6.arpa > >> > >> Nope. > >> > >> reverse zone of 2001::/16 is 1.0.0.2.ip6.arpa > > > > Is there a command line syntax for adding a reverse Zone, in the web > > Formula it is not possible to insert a reverse IPv6 zone. I have only the > > Message this is a wrong IP Address. > > It should work in webUI. > Did you write ipv6 address with prefix? (2001:db8::/32) ? No I have in my Zone only this Addresses 2001:15c0:xxxx:xxxx::234 ? Have I to set all the 0. before the /64 Segment > >>> hope it helps ;-). > >>> > >>> ----- Original Message ----- > >>> From: "G?nther J. Niederwimmer" > >>> To: freeipa-users at redhat.com > >>> Sent: Monday, December 7, 2015 7:58:32 PM > >>> Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? > >>> > >>> Hello, > >>> > >>> I like to create a ip6.arpa with freeIPA but this is not possible ? I > >>> can't > >>> found the correct syntax for a IPv6 reverse Zone :-(. > >>> I Tested > >>> > >>> 16 Char > >>> x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2 > >>> x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa > >>> > >>> The last is working with named (bind) > >>> > >>> Can any tell me, is this working or have I link to read a Docu > >>> > >>> Thanks for a answer > >>> > >>> FreeIPA Version 4.2.0-15 -- mit freundlichen Gr??en / best regards, G?nther J. Niederwimmer From mbasti at redhat.com Tue Dec 8 12:10:57 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 8 Dec 2015 13:10:57 +0100 Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? In-Reply-To: <5578037.ydOcxGNYcb@techz> References: <3653974.reEb1zf8LJ@techz> <3086889.g4U8V0LaX9@techz> <5665FE45.2030203@redhat.com> <5578037.ydOcxGNYcb@techz> Message-ID: <5666C8D1.7050903@redhat.com> On 08.12.2015 12:52, G?nther J. Niederwimmer wrote: > Hello, > > Am Monday 07 December 2015, 22:46:45 schrieb Martin Basti: >> On 07.12.2015 21:26, G?nther J. Niederwimmer wrote: >>> Am Monday 07 December 2015, 20:41:29 schrieb Martin Basti: >>>> On 07.12.2015 20:12, Pavel Picka wrote: >>>>> Hello >>>>> >>>>> for me working if ipv6 address is e.g. 2002::101 so reverse zone will be >>>>> : >>>>> >>>>> 0.2.0.0.2.ip6.arpa >>>>> >>>>> you can use more char as you mentioned ( 0.0.0.0.0.2.0.0.2.ip6.arpa will >>>>> still be reverse for ip 2002::101 ) >>> I tested also more chars ? >>> >>>>> so if your IP start 2001:: have reverse 2.0.0.1.ip6.arpa >>>> Nope. >>>> >>>> reverse zone of 2001::/16 is 1.0.0.2.ip6.arpa >>> Is there a command line syntax for adding a reverse Zone, in the web >>> Formula it is not possible to insert a reverse IPv6 zone. I have only the >>> Message this is a wrong IP Address. >> It should work in webUI. >> Did you write ipv6 address with prefix? (2001:db8::/32) ? > No > > I have in my Zone only this Addresses > 2001:15c0:xxxx:xxxx::234 > > ? > Have I to set all the 0. before the /64 Segment No, you do not need to. Try to write in webUI 2001:15c0::/64 It is shortcut form of IPv6 address, zeroes will be added automatically Martin > >>>>> hope it helps > ;-). >>>>> ----- Original Message ----- >>>>> From: "G?nther J. Niederwimmer" >>>>> To: freeipa-users at redhat.com >>>>> Sent: Monday, December 7, 2015 7:58:32 PM >>>>> Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? >>>>> >>>>> Hello, >>>>> >>>>> I like to create a ip6.arpa with freeIPA but this is not possible ? I >>>>> can't >>>>> found the correct syntax for a IPv6 reverse Zone :-(. >>>>> I Tested >>>>> >>>>> 16 Char >>>>> x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2 >>>>> x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa >>>>> >>>>> The last is working with named (bind) >>>>> >>>>> Can any tell me, is this working or have I link to read a Docu >>>>> >>>>> Thanks for a answer >>>>> >>>>> FreeIPA Version 4.2.0-15 From harald.dunkel at aixigo.de Tue Dec 8 12:17:58 2015 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Tue, 8 Dec 2015 13:17:58 +0100 Subject: [Freeipa-users] mixed DNS subnets for FreeIPA and M$ AD Message-ID: <5666CA76.2090002@aixigo.de> Hi folks, currently I have a DNS domain "example.com" with several subdomains "s1.example.com", "s2.example.com", etc. (using NIS for IM). DNServer is bind9. There is a special stub zone "ws.example.com" provided by AD (including the correct TXT DNS records). Now I would like to move the Unix part to FreeIPA 4.2 (using integrated DNS) and to build a trust relationship to AD. I just wonder if this is possible without loosing the top level "example.com" for both DNS and Kerberos realm? Looking at http://www.freeipa.org/page/Deployment_Recommendations I got confused by expressions like "directly overlap" and "same DNS zone level". Obviously "ws.example.com" is on a different level than "example.com", but do they overlap "directly"? I had the impression that your recommendation is to move FreeIPA to "ipa.example.com", but will it still be possible to manage the old "s1.example.com", "s2.example.com", etc. subdomains in FreeIPA? Will I loose the bind integration? Every helpful comment is highly appreciated. Harri From gjn at gjn.priv.at Tue Dec 8 12:27:14 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Tue, 08 Dec 2015 13:27:14 +0100 Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? In-Reply-To: <5666C8D1.7050903@redhat.com> References: <3653974.reEb1zf8LJ@techz> <5578037.ydOcxGNYcb@techz> <5666C8D1.7050903@redhat.com> Message-ID: <1635154.y4sTCMuJhU@techz> Hello Martin, Am Tuesday 08 December 2015, 13:10:57 schrieb Martin Basti: > On 08.12.2015 12:52, G?nther J. Niederwimmer wrote: > > Hello, > > > > Am Monday 07 December 2015, 22:46:45 schrieb Martin Basti: > >> On 07.12.2015 21:26, G?nther J. Niederwimmer wrote: > >>> Am Monday 07 December 2015, 20:41:29 schrieb Martin Basti: > >>>> On 07.12.2015 20:12, Pavel Picka wrote: > >>>>> Hello > >>>>> > >>>>> for me working if ipv6 address is e.g. 2002::101 so reverse zone will > >>>>> be > >>>>> > >>>>> > >>>>> 0.2.0.0.2.ip6.arpa > >>>>> > >>>>> you can use more char as you mentioned ( 0.0.0.0.0.2.0.0.2.ip6.arpa > >>>>> will > >>>>> still be reverse for ip 2002::101 ) > >>> > >>> I tested also more chars ? > >>> > >>>>> so if your IP start 2001:: have reverse 2.0.0.1.ip6.arpa > >>>> > >>>> Nope. > >>>> > >>>> reverse zone of 2001::/16 is 1.0.0.2.ip6.arpa > >>> > >>> Is there a command line syntax for adding a reverse Zone, in the web > >>> Formula it is not possible to insert a reverse IPv6 zone. I have only > >>> the > >>> Message this is a wrong IP Address. > >> > >> It should work in webUI. > >> Did you write ipv6 address with prefix? (2001:db8::/32) ? > > > > No > > > > I have in my Zone only this Addresses > > 2001:15c0:xxxx:xxxx::234 > > > > ? > > Have I to set all the 0. before the /64 Segment > > No, you do not need to. > > Try to write in webUI 2001:15c0::/64 > It is shortcut form of IPv6 address, zeroes will be added automatically That is it !!!! I have to write a "normal" IPv6 Address with Prefix, afterward the reverse ZONE are created Many Thanks Martin > >>>>> hope it helps > > > > ;-). > > > >>>>> ----- Original Message ----- > >>>>> From: "G?nther J. Niederwimmer" > >>>>> To: freeipa-users at redhat.com > >>>>> Sent: Monday, December 7, 2015 7:58:32 PM > >>>>> Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? > >>>>> > >>>>> Hello, > >>>>> > >>>>> I like to create a ip6.arpa with freeIPA but this is not possible ? I > >>>>> can't > >>>>> found the correct syntax for a IPv6 reverse Zone :-(. > >>>>> I Tested > >>>>> > >>>>> 16 Char > >>>>> x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2 > >>>>> x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa > >>>>> > >>>>> The last is working with named (bind) > >>>>> > >>>>> Can any tell me, is this working or have I link to read a Docu > >>>>> > >>>>> Thanks for a answer > >>>>> > >>>>> FreeIPA Version 4.2.0-15 -- mit freundlichen Gr??en / best regards, G?nther J. Niederwimmer From mbasti at redhat.com Tue Dec 8 13:29:17 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 8 Dec 2015 14:29:17 +0100 Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? [solved] In-Reply-To: <1635154.y4sTCMuJhU@techz> References: <3653974.reEb1zf8LJ@techz> <5578037.ydOcxGNYcb@techz> <5666C8D1.7050903@redhat.com> <1635154.y4sTCMuJhU@techz> Message-ID: <5666DB2D.1050002@redhat.com> On 08.12.2015 13:27, G?nther J. Niederwimmer wrote: > Hello Martin, > > Am Tuesday 08 December 2015, 13:10:57 schrieb Martin Basti: >> On 08.12.2015 12:52, G?nther J. Niederwimmer wrote: >>> Hello, >>> >>> Am Monday 07 December 2015, 22:46:45 schrieb Martin Basti: >>>> On 07.12.2015 21:26, G?nther J. Niederwimmer wrote: >>>>> Am Monday 07 December 2015, 20:41:29 schrieb Martin Basti: >>>>>> On 07.12.2015 20:12, Pavel Picka wrote: >>>>>>> Hello >>>>>>> >>>>>>> for me working if ipv6 address is e.g. 2002::101 so reverse zone will >>>>>>> be >>>>>>> >>>>>>> >>>>>>> 0.2.0.0.2.ip6.arpa >>>>>>> >>>>>>> you can use more char as you mentioned ( 0.0.0.0.0.2.0.0.2.ip6.arpa >>>>>>> will >>>>>>> still be reverse for ip 2002::101 ) >>>>> I tested also more chars ? >>>>> >>>>>>> so if your IP start 2001:: have reverse 2.0.0.1.ip6.arpa >>>>>> Nope. >>>>>> >>>>>> reverse zone of 2001::/16 is 1.0.0.2.ip6.arpa >>>>> Is there a command line syntax for adding a reverse Zone, in the web >>>>> Formula it is not possible to insert a reverse IPv6 zone. I have only >>>>> the >>>>> Message this is a wrong IP Address. >>>> It should work in webUI. >>>> Did you write ipv6 address with prefix? (2001:db8::/32) ? >>> No >>> >>> I have in my Zone only this Addresses >>> 2001:15c0:xxxx:xxxx::234 >>> >>> ? >>> Have I to set all the 0. before the /64 Segment >> No, you do not need to. >> >> Try to write in webUI 2001:15c0::/64 >> It is shortcut form of IPv6 address, zeroes will be added automatically > That is it !!!! > > I have to write a "normal" IPv6 Address with Prefix, afterward the reverse ZONE > are created > > Many Thanks Martin You are welcome! I created usability ticket. https://fedorahosted.org/freeipa/ticket/5532 > >>>>>>> hope it helps >>> ;-). >>> >>>>>>> ----- Original Message ----- >>>>>>> From: "G?nther J. Niederwimmer" >>>>>>> To: freeipa-users at redhat.com >>>>>>> Sent: Monday, December 7, 2015 7:58:32 PM >>>>>>> Subject: [Freeipa-users] Reverse Zone IPv6 Syntax ? >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I like to create a ip6.arpa with freeIPA but this is not possible ? I >>>>>>> can't >>>>>>> found the correct syntax for a IPv6 reverse Zone :-(. >>>>>>> I Tested >>>>>>> >>>>>>> 16 Char >>>>>>> x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2 >>>>>>> x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa >>>>>>> >>>>>>> The last is working with named (bind) >>>>>>> >>>>>>> Can any tell me, is this working or have I link to read a Docu >>>>>>> >>>>>>> Thanks for a answer >>>>>>> >>>>>>> FreeIPA Version 4.2.0-15 From stefano.cortese at ego-gw.it Tue Dec 8 13:30:54 2015 From: stefano.cortese at ego-gw.it (Stefano Cortese) Date: Tue, 08 Dec 2015 14:30:54 +0100 Subject: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7 In-Reply-To: <20151207171225.GK5290@hendrix.arn.redhat.com> References: <5665BC1E.3@ego-gw.it> <20151207171225.GK5290@hendrix.arn.redhat.com> Message-ID: <5666DB8E.4010503@ego-gw.it> An HTML attachment was scrubbed... URL: From stefano.cortese at ego-gw.it Tue Dec 8 13:33:40 2015 From: stefano.cortese at ego-gw.it (Stefano Cortese) Date: Tue, 08 Dec 2015 14:33:40 +0100 Subject: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7 In-Reply-To: <20151207172522.GF16629@p.redhat.com> References: <5665BC1E.3@ego-gw.it> <20151207172522.GF16629@p.redhat.com> Message-ID: <5666DC34.1020600@ego-gw.it> An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Dec 8 14:08:48 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 8 Dec 2015 15:08:48 +0100 Subject: [Freeipa-users] mixed DNS subnets for FreeIPA and M$ AD In-Reply-To: <5666CA76.2090002@aixigo.de> References: <5666CA76.2090002@aixigo.de> Message-ID: <5666E470.1030000@redhat.com> On 8.12.2015 13:17, Harald Dunkel wrote: > Hi folks, > > currently I have a DNS domain "example.com" with several > subdomains "s1.example.com", "s2.example.com", etc. (using > NIS for IM). DNServer is bind9. There is a special stub zone > "ws.example.com" provided by AD (including the correct > TXT DNS records). > > Now I would like to move the Unix part to FreeIPA 4.2 > (using integrated DNS) and to build a trust relationship > to AD. I just wonder if this is possible without loosing > the top level "example.com" for both DNS and Kerberos > realm? > > Looking at http://www.freeipa.org/page/Deployment_Recommendations > I got confused by expressions like "directly overlap" and > "same DNS zone level". Obviously "ws.example.com" is on > a different level than "example.com", but do they overlap > "directly"? Does https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prerequisites.html#dns-reqs and https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#dns-realm-settings answer your questions? There are some examples in the second document. Petr^2 Spacek > I had the impression that your recommendation is to move > FreeIPA to "ipa.example.com", but will it still be > possible to manage the old "s1.example.com", "s2.example.com", > etc. subdomains in FreeIPA? Will I loose the bind integration? > > > Every helpful comment is highly appreciated. From stefano.cortese at ego-gw.it Tue Dec 8 13:15:31 2015 From: stefano.cortese at ego-gw.it (Stefano Cortese) Date: Tue, 08 Dec 2015 14:15:31 +0100 Subject: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7 In-Reply-To: <20151207172522.GF16629@p.redhat.com> References: <5665BC1E.3@ego-gw.it> <20151207172522.GF16629@p.redhat.com> Message-ID: <5666D7F3.8040305@ego-gw.it> An HTML attachment was scrubbed... URL: From stefano.cortese at ego-gw.it Tue Dec 8 15:45:43 2015 From: stefano.cortese at ego-gw.it (Stefano Cortese) Date: Tue, 08 Dec 2015 16:45:43 +0100 Subject: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7 In-Reply-To: <1449509265.17418.11.camel@redhat.com> References: <5665BC1E.3@ego-gw.it> <1449509265.17418.11.camel@redhat.com> Message-ID: <5666FB27.8070107@ego-gw.it> An HTML attachment was scrubbed... URL: From sbose at redhat.com Tue Dec 8 16:40:28 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 8 Dec 2015 17:40:28 +0100 Subject: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7 In-Reply-To: <5666DC34.1020600@ego-gw.it> References: <5665BC1E.3@ego-gw.it> <20151207172522.GF16629@p.redhat.com> <5666DC34.1020600@ego-gw.it> Message-ID: <20151208164028.GH16629@p.redhat.com> On Tue, Dec 08, 2015 at 02:33:40PM +0100, Stefano Cortese wrote: > Hi Sumit > yes it works commenting out the  line 'enable_only = sssd' and making > the file immutable , namely the .k5login file is read and enforced.
> But respect to the solution emptying completely the snippet, it is lost > the possibility to perform the same enforcement via an > 'auth_to_local_names' entry in /etc/krb5.conf for the given realm in > which the service' principal is mapped onto the destination posix > account
This is expected because if either the principal or the user name is known to SSSD the localauth plugin will take control because by default the added modules are registered first (see [plugins] section of man krb5.conf for details). To check auth_to_local_names first you can try enable_only=names,k5login,sssd HTH bye, Sumit From jhrozek at redhat.com Tue Dec 8 19:25:13 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 8 Dec 2015 20:25:13 +0100 Subject: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7 In-Reply-To: <5666DB8E.4010503@ego-gw.it> References: <5665BC1E.3@ego-gw.it> <20151207171225.GK5290@hendrix.arn.redhat.com> <5666DB8E.4010503@ego-gw.it> Message-ID: <20151208192513.GC2986@hendrix> On Tue, Dec 08, 2015 at 02:30:54PM +0100, Stefano Cortese wrote: > Jakub Hrozek wrote: > > On Mon, Dec 07, 2015 at 06:04:30PM +0100, Stefano Cortese wrote: > > > So the questions are: > - is there another cleaner way to exclude the localauth sssd plugin > (considering that the configuration snippet is recreated at every sssd > restart)? > > > Can you test if this hack would help: > # service sssd stop > # rm /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > # touch /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > # chattr +i /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > # service sssd start > > > It works, thanks > > > > btw also check out this ticket: > [1]https://fedorahosted.org/sssd/ticket/2788 > > > not needing principal switching from/to root for the moment > > > Yes, sorry, wrong ticket: > [2]https://fedorahosted.org/sssd/ticket/2707 > > > > > > Maybe I wasn't clear in describing the setup. > > I am attempting to log from a local machine as "userA" using the > credentials of a "service principal" defined in IPA to a remote machine as > "userB" > The userB principal is resolvable on the remote host via "getent passwd > userB" because it is a user principal. > Also the userA principal is resolvable on the local machine, but this should > not play a role because the user's credentials are not used for the > connection, only the service credentials, as a client. > The service principal is not resolvable via "getent passwd" neither on the > originating host nor on the destination host. > The trick with .k5login is that the service principal used in the connection > is granted access as userB because it is listed as one of the principals > that correspond to the userB posix account on the remote host. > > > Thank you, then I think #2707 would help you because you could configure > that .k5login is still used. > > > > Hi Jakub, > yes maybe it could help, even if I didn't find many details (bugzilla says > I am not authorized to access the RedHat Bug 1240302? with? my bugzilla? > account,? I? have tried also with our RedHat support licensed account) . Try now, there is nothing confidential in the bug, so I opened it. (I'm afraid there's nothing useful either, but the BZ might be useful in referencing for support..) > It seems having been filed for sssd 1.14 and RHEL7 , is there any hope > that it will be implemented also for 6.7 or 6.8 ?? we can't upgrade to 7 > for the IPA clients. > Bye > Stefano I can't promise anything because the scope of the changes is not totally clear, but can you please open a support case asking for the change in RHEL-6? Feel free to send me the case number, then. It might also be helpful to include why the workaround is not helpful/not feasible to you, because RHEL-6 already getting quite late in the cycle, so all changes should be justified.. From Jeff.Sauls at photomask.com Tue Dec 8 22:10:42 2015 From: Jeff.Sauls at photomask.com (Sauls, Jeff) Date: Tue, 8 Dec 2015 16:10:42 -0600 Subject: [Freeipa-users] HBAC access denied, all AD groups not detected In-Reply-To: <20151207205220.GB3086@hendrix> References: <20151207085922.GD3399@hendrix.redhat.com> <20151207205220.GB3086@hendrix> Message-ID: > Jakub Hrozek wrote: > > On Mon, Dec 07, 2015 at 02:04:26PM -0600, Sauls, Jeff wrote: > > > Jakub Hrozek wrote: > > > > > > On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote: > > > > Hello, > > > > > > > > We are having a problem with HBAC that appears to be related to > > > > group membership lookup. I am testing with a new install on RHEL > > > > 7.2 with a cross-forest trust with AD. When an AD user attempts > > > > to log into a client (RH 6.7 or 7.2) the "hbac_eval_user_element" > > > > can report a different number of groups each time and never seems to > contain the full list. > > > > For the testing account, running the 'id' command returns 153 groups. > > > > The ipa group "ad_admin" has setup to be able to log in anywhere, > > > > everyone else is denied. With the default allow_all rule enabled, > > > > everything works as expected. Any ideas on where I can look next? > > > > > > I assume the group membership is OK on the server, but not the > > > client? Can you enable debugging and also include the full logs from > > > the client after doing sss_cache -E on the client? > > > > I've done some more testing and installed a RHEL 6.6 client, the issue doesn't > occur there since it is not pulling in AD groups, it only shows the single POSIX > group. The server is running 7.2 and I get the same issue logging into it. > > To make sure I understand -- the group you expect to be returned on the server > is not either? So there is a consistent failure on the server as well? > > (It's important to see where the failure is, the server and the client use > different methods to obtain the group memberships. The server talks directly to > the AD, the clients talk to the server) > > > > > This is the log section for a login that failed due to "Access denied > > by HBAC rules" http://pastebin.com/paiBjG96 It shows it failing with 112 > groups, but I've had it pass at 113 and fail on another user at 66. > > > > The server and client show the same symptoms. If I clear the cache on both and log into each, the number of groups can change between cache clearings. The only group used in the HBAC rule "admin-access" is a POSIX group "ad_admins". Ad_admins contains an external group with the AD user account in it. I can't consistently repeat it nor find a pattern to the failure. After many cache clears and reboots testing with the server, I've managed to get it into a failure state. After the reboot, I successfully logged in with the AD account. It showed [113] groups in the log. I logged out and logged back in with the same account a few minutes later and was denied by HABC rules, the group count shows [71] for this session. Logging in 30 minutes later still fails, but show [112] groups now. On the client system, I cleared the cache and rebooted it, I'm able to log into it with the AD account and it shows [72] groups in the log. -Jeff From harald.dunkel at aixigo.de Wed Dec 9 07:36:11 2015 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Wed, 9 Dec 2015 08:36:11 +0100 Subject: [Freeipa-users] mixed DNS subnets for FreeIPA and M$ AD In-Reply-To: <5666E470.1030000@redhat.com> References: <5666CA76.2090002@aixigo.de> <5666E470.1030000@redhat.com> Message-ID: <5667D9EB.8010003@aixigo.de> On 12/08/2015 03:08 PM, Petr Spacek wrote: > > Does > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prerequisites.html#dns-reqs > > and > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#dns-realm-settings > > answer your questions? > Not really. All these documents bring up strings like "ipa.example.com". Sometimes thats a DNS domain, sometimes its a kerberos realm (even though its in lower case letters). The assumption that DNS and realm name match is based upon a recommendation, i.e. you cannot rely upon that. (Not to mention that "example.com" and "ad.example.com" *are* unique.) My point is: Currently I have a hierarchy between the DNS top level domain "example.com" and the windows DNS domain "ws.example.com". I do not have a hierarchy between the IM solutions for Unix and Windows (currently NIS and AD). Moving from NIS/bind to FreeIPA I would prefer to keep this setup. If this is not possible, then I can live with moving the IPA servers to "ipa.example.com" (DNS), but I cannot change the other DNS subnets. Changing existing host and domain names is *highly* expensive. I don't care very much about the realm name in Kerberos. IMU thats just a string. IPA.EXAMPLE.COM would be fine, if EXAMPLE.COM is not possible. What would be your suggestion? Harri From jhrozek at redhat.com Wed Dec 9 08:17:25 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 9 Dec 2015 09:17:25 +0100 Subject: [Freeipa-users] HBAC access denied, all AD groups not detected In-Reply-To: References: <20151207085922.GD3399@hendrix.redhat.com> <20151207205220.GB3086@hendrix> Message-ID: <20151209081725.GF2986@hendrix> On Tue, Dec 08, 2015 at 04:10:42PM -0600, Sauls, Jeff wrote: > > Jakub Hrozek wrote: > > > > On Mon, Dec 07, 2015 at 02:04:26PM -0600, Sauls, Jeff wrote: > > > > Jakub Hrozek wrote: > > > > > > > > On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote: > > > > > Hello, > > > > > > > > > > We are having a problem with HBAC that appears to be related to > > > > > group membership lookup. I am testing with a new install on RHEL > > > > > 7.2 with a cross-forest trust with AD. When an AD user attempts > > > > > to log into a client (RH 6.7 or 7.2) the "hbac_eval_user_element" > > > > > can report a different number of groups each time and never seems to > > contain the full list. > > > > > For the testing account, running the 'id' command returns 153 groups. > > > > > The ipa group "ad_admin" has setup to be able to log in anywhere, > > > > > everyone else is denied. With the default allow_all rule enabled, > > > > > everything works as expected. Any ideas on where I can look next? > > > > > > > > I assume the group membership is OK on the server, but not the > > > > client? Can you enable debugging and also include the full logs from > > > > the client after doing sss_cache -E on the client? > > > > > > I've done some more testing and installed a RHEL 6.6 client, the issue doesn't > > occur there since it is not pulling in AD groups, it only shows the single POSIX > > group. The server is running 7.2 and I get the same issue logging into it. > > > > To make sure I understand -- the group you expect to be returned on the server > > is not either? So there is a consistent failure on the server as well? > > > > (It's important to see where the failure is, the server and the client use > > different methods to obtain the group memberships. The server talks directly to > > the AD, the clients talk to the server) > > > > > > > > This is the log section for a login that failed due to "Access denied > > > by HBAC rules" http://pastebin.com/paiBjG96 It shows it failing with 112 > > groups, but I've had it pass at 113 and fail on another user at 66. > > > > > > > > The server and client show the same symptoms. Ah, OK, then it sounds different from the other cases we've seen recently and we need to fix the server first, because the clients read data from the server. If you can catch the failure with logs that update the cache (so sss_cache -E was run before the id attempt), please go ahead and file a bug against sssd. It would also be nice to list what groups are not displayed but should be (or which work intermittently) and describe the hierarchy if possible, at least the part that includes the faulty groups, so we can set a similar environment locally. > If I clear the cache on both and log into each, the number of groups can change between cache clearings. The only group used in the HBAC rule "admin-access" is a POSIX group "ad_admins". Ad_admins contains an external group with the AD user account in it. I can't consistently repeat it nor find a pattern to the failure. > > After many cache clears and reboots testing with the server, I've managed to get it into a failure state. After the reboot, I successfully logged in with the AD account. It showed [113] groups in the log. I logged out and logged back in with the same account a few minutes later and was denied by HABC rules, the group count shows [71] for this session. Logging in 30 minutes later still fails, but show [112] groups now. On the client system, I cleared the cache and rebooted it, I'm able to log into it with the AD account and it shows [72] groups in the log. > > -Jeff > > > -- > 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 From abokovoy at redhat.com Wed Dec 9 08:32:14 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 9 Dec 2015 10:32:14 +0200 Subject: [Freeipa-users] mixed DNS subnets for FreeIPA and M$ AD In-Reply-To: <5667D9EB.8010003@aixigo.de> References: <5666CA76.2090002@aixigo.de> <5666E470.1030000@redhat.com> <5667D9EB.8010003@aixigo.de> Message-ID: <20151209083214.GF4620@redhat.com> On Wed, 09 Dec 2015, Harald Dunkel wrote: >On 12/08/2015 03:08 PM, Petr Spacek wrote: >> >> Does >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prerequisites.html#dns-reqs >> >> and >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#dns-realm-settings >> >> answer your questions? >> > >Not really. All these documents bring up strings like >"ipa.example.com". Sometimes thats a DNS domain, sometimes >its a kerberos realm (even though its in lower case letters). >The assumption that DNS and realm name match is based upon a >recommendation, i.e. you cannot rely upon that. (Not to >mention that "example.com" and "ad.example.com" *are* unique.) In Active Directory Kerberos realm is always a capitalized version of the primary DNS domain occupied by this Active Directory domain. >My point is: Currently I have a hierarchy between the DNS top >level domain "example.com" and the windows DNS domain >"ws.example.com". I do not have a hierarchy between the IM >solutions for Unix and Windows (currently NIS and AD). Moving >from NIS/bind to FreeIPA I would prefer to keep this setup. If >this is not possible, then I can live with moving the IPA >servers to "ipa.example.com" (DNS), but I cannot change the >other DNS subnets. Changing existing host and domain names >is *highly* expensive. You can keep own arrangement if it doesn't conflict with your Active Directory deployment's ownership of DNS zones. You are saying ws.example.com is your AD DNS domain. Do you have machines from example.com enrolled into AD? If there are machines from DNS zone example.com in AD, you cannot have IPA deployed in DNS zone example.com because AD will not allow trust between something that claims to own DNS zone AD owns already. It is simple as that. When you create AD deployment, it establishes ownership over the DNS domain which is used to create the deployment. Later, each enrolled computer's DNS domain is added to the list of owned DNS domains. They all would belong to Active Directory and to have some other Active Directory to claim ownership over it would be seen as a conflict. -- / Alexander Bokovoy From wouter.hummelink at kpn.com Wed Dec 9 10:46:06 2015 From: wouter.hummelink at kpn.com (wouter.hummelink at kpn.com) Date: Wed, 9 Dec 2015 10:46:06 +0000 Subject: [Freeipa-users] Certificate Profile - Policy Set Not Found Message-ID: <2CA71D6C07ADB544847562573DC6BF061857806C@CPEMS-KPN309.KPNCNL.LOCAL> Hello, Im trying to import and use a certificate profile in IPAv4.2 on RHEL. I've exported the default caIPAServiceCert profile and did the following modification: < profileId=caIPAserviceCert --- > profileId=KPNWebhostingAEM 87c87 < policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, O=IPADOMAIN --- > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, OU=TESTAEM, O=IPADOMAIN Profile Profile ID: KPNWebhostingAEM Profile description: KPN Webhosting AEM Store issued certificates: TRUE CAACL ACL name: ING Intermediairs AEM Application Servers Enabled: TRUE Profiles: KPNWebhostingServiceCertAEM, KPNWebhostingAEM Host Groups: xxx_accp_applications, xxx_prod_applications Trying to request a certificate for a server ipa-getcert request -r -I mongo2 -f /etc/pki/tls/certs/host.crt -k /etc/pki/tls/certs/host.key -TKPNWebhostingAEM Results in: ipa-getcert list Number of certificates and requests being tracked: 1. Request ID 'mongo2': status: CA_UNREACHABLE ca-error: Server at https://pvlipa1001c.ipadomain/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Policy Set Not Found)). stuck: no key pair storage: type=FILE,location='/etc/pki/tls/certs/host.key' certificate: type=FILE,location='/etc/pki/tls/certs/host.crt' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes Since the same setup was working to request certificates on my lab environment I'm at a loss what is causing the error. Met vriendelijke groet, Wouter Hummelink Cloud Engineer [Description: Beschrijving: Beschrijving: cid:image003.gif at 01CC7CE9.FCFEC140] KPN IT Solutions Platform Organisation Cloud Services Mail: wouter.hummelink at kpn.com Telefoon: +31 (0)6 1288 2447 [cid:image002.png at 01D0DA65.706AE4B0] P Save Paper - Do you really need to print this e-mail? ********************************************************************************************************************************************************* KPN IT SOLUTIONS is de 'handelsnaam' voor KPN Corporate Market BV, Handelsregister 52959597 Amsterdam The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you. ********************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2045 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 49569 bytes Desc: image002.png URL: From wdh at dds.nl Wed Dec 9 11:58:23 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Wed, 9 Dec 2015 12:58:23 +0100 Subject: [Freeipa-users] Trusted Domain Users - entry_cache_timeout Message-ID: <5668175F.9080903@dds.nl> An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Dec 9 12:08:02 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 9 Dec 2015 13:08:02 +0100 Subject: [Freeipa-users] Trusted Domain Users - entry_cache_timeout In-Reply-To: <5668175F.9080903@dds.nl> References: <5668175F.9080903@dds.nl> Message-ID: <20151209120802.GB2920@hendrix> On Wed, Dec 09, 2015 at 12:58:23PM +0100, Winfried de Heiden wrote: > Hi all, > > Using entry_cache_timeout to set different cache timeout for sssd works > well. However, it doesn't seem to work for Trusted Domain Users (using AD > trust) > > I made some changes, cleaned the cache but expiry will stay on a (too > long) 10 (ten!) hours! > > How can I change the sssd cache timeout for Trusted AD users ? (using IPA > 4.1) > > Kind regards! Did you change the expiry on a client only or also on the server? Keep in mind that for identity lookups, only the IPA masters are connected to AD, the clients fetch data from IPA masters. (Authentication, however, is done against AD DCs directly) Another point to keep in mind is that the cache expiry is stored in the objects themselves, so you might want to refresh the cache. From gjn at gjn.priv.at Wed Dec 9 13:40:30 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Wed, 09 Dec 2015 14:40:30 +0100 Subject: [Freeipa-users] FreeIPA DNSSEC NSEC3PARAM record Message-ID: <3267566.oWNlBILFrx@techz> Hello, I like to create a NSEC3PARAM Record but my tests are not working :-(. Is there a documentation for this Problem I can't found a DOCU My test is I make a "Salt" with this head -c 512 /dev/random | sha1sum | cut -b 1-16 xxxxxxxxxxxxx... afterward i make with ldns-nsec3-hash -t 10 -s xxxxxxxxxxxxxxxxxx xxxxx.com xxxxx..... the result i like to insert in the WebUI but this is wrong ? What is the correct syntax to create a NSEC3PARAM record? Thanks for a answer, -- mit freundlichen Gr??en / best regards, G?nther J. Niederwimmer From randym at chem.byu.edu Wed Dec 9 14:52:04 2015 From: randym at chem.byu.edu (Randy Morgan) Date: Wed, 9 Dec 2015 07:52:04 -0700 Subject: [Freeipa-users] FreeRadius and FreeIPA Message-ID: <56684014.9060001@chem.byu.edu> Hello, We are setting up our wireless to authenticate against FreeRadius and FreeIPA. I am looking for any instructions on how to integrate radius with IPA. We can get them talking via kerberos, but when we have a wireless client attempt to authenticate against them, the password gets stripped out and only the username gets passed on, resulting in a failed logon attempt. As we have studied the problem we have identified the communication protocols used by wireless to pass on the user credentials to radius. Wireless uses EAP as it's primary protocol. We are running Xirrus wireless APs and from what we can learn, they act only as a pass through conduit for the client. Ideally we would like them to speak PEAP TTLS, this would allow kerberos to process from the client to the IPA server, we are still researching this. Are there any instructions on how to integrate FreeRadius 3.0.10 with FreeIPA 3.3.5? Any help would be appreciated. Randy -- Randy Morgan CSR Department of Chemistry and Biochemistry Brigham Young University 801-422-4100 From prasun.gera at gmail.com Wed Dec 9 15:32:32 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Wed, 9 Dec 2015 07:32:32 -0800 Subject: [Freeipa-users] yum update today broke ipa Message-ID: Ran yum update today. Pulled in https://rhn.redhat.com/errata/RHBA-2015-2562.html. Seeing this error: 2015-12-09T15:21:02Z DEBUG The ipa-server-upgrade command failed, exception: ScriptError: ("Unable to execute IPA upgrade: data are in newer version than IPA (data version '4.2.0-15.el7', IPA version '4.2.0-15.el7_2.3')", 1) 2015-12-09T15:21:02Z ERROR ("Unable to execute IPA upgrade: data are in newer version than IPA (data version '4.2.0-15.el7', IPA version '4.2.0-15.el7_2.3')", 1) "/var/log/ipaupgrade.log" 54696L, 5389464C ipactl won't start now. Luckily, I ran the update only on one replica. The other node is still running. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Dec 9 16:00:03 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 9 Dec 2015 17:00:03 +0100 Subject: [Freeipa-users] Trusted Domain Users - entry_cache_timeout In-Reply-To: <5668175F.9080903@dds.nl> References: <5668175F.9080903@dds.nl> Message-ID: <20151209160003.GN2920@hendrix> On Wed, Dec 09, 2015 at 12:58:23PM +0100, Winfried de Heiden wrote: > Hi all, > > Using entry_cache_timeout to set different cache timeout for sssd works > well. However, it doesn't seem to work for Trusted Domain Users (using AD > trust) > > I made some changes, cleaned the cache but expiry will stay on a (too > long) 10 (ten!) hours! > > How can I change the sssd cache timeout for Trusted AD users ? (using IPA > 4.1) > > Kind regards! (I thought I already replied but I don't see the reply on the list and neither in my Sent folder. Apologies if this is a duplicate). Since it's the IPA master that fetches the identity data from the AD server, you also need to change the cache timeouts on the server. In addition, the cache time lifetime is stored in the cache entry itself, so you might want to invalidate the cache with sss_cache on both the server and the client. From mbasti at redhat.com Wed Dec 9 16:14:43 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 9 Dec 2015 17:14:43 +0100 Subject: [Freeipa-users] yum update today broke ipa In-Reply-To: References: Message-ID: <56685373.5050701@redhat.com> On 09.12.2015 16:32, Prasun Gera wrote: > Ran yum update today. Pulled in > https://rhn.redhat.com/errata/RHBA-2015-2562.html. > > Seeing this error: > > 2015-12-09T15:21:02Z DEBUG The ipa-server-upgrade command failed, > exception: ScriptError: ("Unable to execute IPA upgrade: data are in > newer version than IPA (data version '4.2.0-15.el7', IPA version > '4.2.0-15.el7_2.3')", 1) > 2015-12-09T15:21:02Z ERROR ("Unable to execute IPA upgrade: data are > in newer version than IPA (data version '4.2.0-15.el7', IPA version > '4.2.0-15.el7_2.3')", 1) > "/var/log/ipaupgrade.log" 54696L, 5389464C > > ipactl won't start now. Luckily, I ran the update only on one replica. > The other node is still running. > > Hello, this is not good, something terrible wrong happened with parsing versions. You can run upgrade with ipa-server-upgrade --skip-version-check or --force -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Wed Dec 9 16:21:19 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Wed, 9 Dec 2015 08:21:19 -0800 Subject: [Freeipa-users] yum update today broke ipa In-Reply-To: <56685373.5050701@redhat.com> References: <56685373.5050701@redhat.com> Message-ID: Before I try this on the actual node, would it be better to roll back the last yum transaction ? I want to do whatever is safer. On Wed, Dec 9, 2015 at 8:14 AM, Martin Basti wrote: > > > On 09.12.2015 16:32, Prasun Gera wrote: > > Ran yum update today. Pulled in > > https://rhn.redhat.com/errata/RHBA-2015-2562.html. > > Seeing this error: > > 2015-12-09T15:21:02Z DEBUG The ipa-server-upgrade command failed, > exception: ScriptError: ("Unable to execute IPA upgrade: data are in newer > version than IPA (data version '4.2.0-15.el7', IPA version > '4.2.0-15.el7_2.3')", 1) > 2015-12-09T15:21:02Z ERROR ("Unable to execute IPA upgrade: data are in > newer version than IPA (data version '4.2.0-15.el7', IPA version > '4.2.0-15.el7_2.3')", 1) > "/var/log/ipaupgrade.log" 54696L, 5389464C > > ipactl won't start now. Luckily, I ran the update only on one replica. The > other node is still running. > > > Hello, this is not good, something terrible wrong happened with parsing > versions. > > You can run upgrade with ipa-server-upgrade --skip-version-check or --force > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Dec 9 16:22:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 9 Dec 2015 17:22:56 +0100 Subject: [Freeipa-users] yum update today broke ipa In-Reply-To: References: <56685373.5050701@redhat.com> Message-ID: <56685560.10308@redhat.com> Run upgrade manually, this is just error in checking function, obviously 4.2.0-15.el7_2.3 is never than 4.2.0-15.el7 On 09.12.2015 17:21, Prasun Gera wrote: > Before I try this on the actual node, would it be better to roll back > the last yum transaction ? I want to do whatever is safer. > > On Wed, Dec 9, 2015 at 8:14 AM, Martin Basti > wrote: > > > > On 09.12.2015 16:32, Prasun Gera wrote: >> Ran yum update today. Pulled in >> https://rhn.redhat.com/errata/RHBA-2015-2562.html. >> >> Seeing this error: >> >> 2015-12-09T15:21:02Z DEBUG The ipa-server-upgrade command failed, >> exception: ScriptError: ("Unable to execute IPA upgrade: data are >> in newer version than IPA (data version '4.2.0-15.el7', IPA >> version '4.2.0-15.el7_2.3')", 1) >> 2015-12-09T15:21:02Z ERROR ("Unable to execute IPA upgrade: data >> are in newer version than IPA (data version '4.2.0-15.el7', IPA >> version '4.2.0-15.el7_2.3')", 1) >> "/var/log/ipaupgrade.log" 54696L, 5389464C >> >> ipactl won't start now. Luckily, I ran the update only on one >> replica. The other node is still running. >> >> > Hello, this is not good, something terrible wrong happened with > parsing versions. > > You can run upgrade with ipa-server-upgrade --skip-version-check > or --force > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Wed Dec 9 16:30:26 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Wed, 9 Dec 2015 08:30:26 -0800 Subject: [Freeipa-users] yum update today broke ipa In-Reply-To: <56685560.10308@redhat.com> References: <56685373.5050701@redhat.com> <56685560.10308@redhat.com> Message-ID: Thanks! That worked. The command passed, and I don't see any other odd behaviour yet. I'll wait for a new fixed errata before upgrading the other node. That should be OK right ? i.e. Running replicas on slightly different versions. On Wed, Dec 9, 2015 at 8:22 AM, Martin Basti wrote: > Run upgrade manually, this is just error in checking function, obviously > 4.2.0-15.el7_2.3 is never than 4.2.0-15.el7 > > > On 09.12.2015 17:21, Prasun Gera wrote: > > Before I try this on the actual node, would it be better to roll back the > last yum transaction ? I want to do whatever is safer. > > On Wed, Dec 9, 2015 at 8:14 AM, Martin Basti wrote: > >> >> >> On 09.12.2015 16:32, Prasun Gera wrote: >> >> Ran yum update today. Pulled in >> >> https://rhn.redhat.com/errata/RHBA-2015-2562.html. >> >> Seeing this error: >> >> 2015-12-09T15:21:02Z DEBUG The ipa-server-upgrade command failed, >> exception: ScriptError: ("Unable to execute IPA upgrade: data are in newer >> version than IPA (data version '4.2.0-15.el7', IPA version >> '4.2.0-15.el7_2.3')", 1) >> 2015-12-09T15:21:02Z ERROR ("Unable to execute IPA upgrade: data are in >> newer version than IPA (data version '4.2.0-15.el7', IPA version >> '4.2.0-15.el7_2.3')", 1) >> "/var/log/ipaupgrade.log" 54696L, 5389464C >> >> ipactl won't start now. Luckily, I ran the update only on one replica. >> The other node is still running. >> >> >> Hello, this is not good, something terrible wrong happened with parsing >> versions. >> >> You can run upgrade with ipa-server-upgrade --skip-version-check or >> --force >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Dec 9 18:08:44 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 9 Dec 2015 19:08:44 +0100 Subject: [Freeipa-users] yum update today broke ipa In-Reply-To: References: <56685373.5050701@redhat.com> <56685560.10308@redhat.com> Message-ID: <56686E2C.1080208@redhat.com> You can safely upgrade all machines, this is just version check error. On 09.12.2015 17:30, Prasun Gera wrote: > Thanks! That worked. The command passed, and I don't see any other odd > behaviour yet. I'll wait for a new fixed errata before upgrading the > other node. That should be OK right ? i.e. Running replicas on > slightly different versions. > > On Wed, Dec 9, 2015 at 8:22 AM, Martin Basti > wrote: > > Run upgrade manually, this is just error in checking function, > obviously 4.2.0-15.el7_2.3 is never than 4.2.0-15.el7 > > > On 09.12.2015 17:21, Prasun Gera wrote: >> Before I try this on the actual node, would it be better to roll >> back the last yum transaction ? I want to do whatever is safer. >> >> On Wed, Dec 9, 2015 at 8:14 AM, Martin Basti > > wrote: >> >> >> >> On 09.12.2015 16:32, Prasun Gera wrote: >>> Ran yum update today. Pulled in >>> https://rhn.redhat.com/errata/RHBA-2015-2562.html. >>> >>> Seeing this error: >>> >>> 2015-12-09T15:21:02Z DEBUG The ipa-server-upgrade command >>> failed, exception: ScriptError: ("Unable to execute IPA >>> upgrade: data are in newer version than IPA (data version >>> '4.2.0-15.el7', IPA version '4.2.0-15.el7_2.3')", 1) >>> 2015-12-09T15:21:02Z ERROR ("Unable to execute IPA upgrade: >>> data are in newer version than IPA (data version >>> '4.2.0-15.el7', IPA version '4.2.0-15.el7_2.3')", 1) >>> "/var/log/ipaupgrade.log" 54696L, 5389464C >>> >>> ipactl won't start now. Luckily, I ran the update only on >>> one replica. The other node is still running. >>> >>> >> Hello, this is not good, something terrible wrong happened >> with parsing versions. >> >> You can run upgrade with ipa-server-upgrade >> --skip-version-check or --force >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schogan at us.ibm.com Tue Dec 8 16:27:02 2015 From: schogan at us.ibm.com (Sean Hogan) Date: Tue, 8 Dec 2015 09:27:02 -0700 Subject: [Freeipa-users] Ldap search for enrolled boxes In-Reply-To: <56660886.8050602@redhat.com> References: <56660886.8050602@redhat.com> Message-ID: <201512091834.tB9IYqJf009926@d03av02.boulder.ibm.com> Thanks Robert, Appreciated Sean Hogan Security Engineer From: Rob Crittenden To: Sean Hogan/Durham/IBM at IBMUS, freeipa-users at redhat.com Date: 12/07/2015 03:30 PM Subject: Re: [Freeipa-users] Ldap search for enrolled boxes Sean Hogan wrote: > Hello, > > Does anyone have a ldapsearch syntax that will check the database for > all enrolled hosts within IPA and ignore non-enrolled hosts? I am not > familiar enough with the schema yet to know which containers contain > what. I know there is a flag on the gui for enrolled or not so thinking > its doable. Also.. any recommendations on a ldap query tool for use with > IPA? $ kinit admin $ ldapsearch -Y GSSAPI -b cn=computers,cn=accounts,dc=example,dc=com "krbprincipalkey=*" dn Any ldap query tool should work with IPA. rob -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 55590262.jpg Type: image/jpeg Size: 27085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 55613256.gif Type: image/gif Size: 1650 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From m3freak at thesandhufamily.ca Wed Dec 9 18:34:29 2015 From: m3freak at thesandhufamily.ca (Ranbir) Date: Wed, 09 Dec 2015 13:34:29 -0500 Subject: [Freeipa-users] Add "mkhomedir" after install Message-ID: Hello Everyone, I installed a replica without passing the "mkhomedir" option to the install command. Sure enough, when I login to the replica, my home dir isn't created. I _could_ create it manually, but it would be nice if the first login triggered the creation. I've been trying to find an answer to this on my own, but so far I've had no luck. Thanks in advance! -- Ranbir From CWhite at skytouchtechnology.com Wed Dec 9 19:01:54 2015 From: CWhite at skytouchtechnology.com (Craig White) Date: Wed, 9 Dec 2015 19:01:54 +0000 Subject: [Freeipa-users] Add "mkhomedir" after install In-Reply-To: References: Message-ID: You can enable it at any time... authconfig --enablemkhomedir --update Craig White System Administrator O 623-201-8179?? M 602-377-9752 SkyTouch Technology???? 4225 E. Windrose Dr. ????Phoenix, AZ 85032 -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ranbir Sent: Wednesday, December 09, 2015 11:34 AM To: freeipa-users at redhat.com Subject: [Freeipa-users] Add "mkhomedir" after install Hello Everyone, I installed a replica without passing the "mkhomedir" option to the install command. Sure enough, when I login to the replica, my home dir isn't created. I _could_ create it manually, but it would be nice if the first login triggered the creation. I've been trying to find an answer to this on my own, but so far I've had no luck. Thanks in advance! -- Ranbir -- 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 From joshua.doll at gmail.com Wed Dec 9 19:45:23 2015 From: joshua.doll at gmail.com (Joshua Doll) Date: Wed, 09 Dec 2015 19:45:23 +0000 Subject: [Freeipa-users] Add "mkhomedir" after install In-Reply-To: References: Message-ID: I usually just run authconfig --enablemkhomedir --Joshua D Doll On Wed, Dec 9, 2015 at 1:46 PM Ranbir wrote: > Hello Everyone, > > I installed a replica without passing the "mkhomedir" option to the > install command. Sure enough, when I login to the replica, my home dir > isn't created. I _could_ create it manually, but it would be nice if the > first login triggered the creation. > > I've been trying to find an answer to this on my own, but so far I've > had no luck. > > Thanks in advance! > > -- > Ranbir > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m3freak at thesandhufamily.ca Wed Dec 9 19:55:00 2015 From: m3freak at thesandhufamily.ca (Ranbir) Date: Wed, 09 Dec 2015 14:55:00 -0500 Subject: [Freeipa-users] Add "mkhomedir" after install In-Reply-To: References: Message-ID: <87dd2e1226dd9219d6ae1919fa37eb54@thesandhufamily.ca> On 2015-12-09 14:01, Craig White wrote: > You can enable it at any time... > > authconfig --enablemkhomedir --update Crap! I didn't even consider doing it that way. For some reason I thought there was some ipa command I had to run. The ipa install does this too, I guess. :) Thanks for the pointer and for jogging my memory. -- Ranbir From martin at stefany.eu Wed Dec 9 19:49:43 2015 From: martin at stefany.eu (=?UTF-8?Q?Martin_=C5=A0tefany?=) Date: Wed, 09 Dec 2015 20:49:43 +0100 Subject: [Freeipa-users] Add "mkhomedir" after install In-Reply-To: Message-ID: <7a591739-3a88-4a19-9334-28c81dc2af10@email.android.com> Hello Ranbir, that installation option (as few more) just adjusts parameters passed to authconfig utility. To enable automatic home directory creation later on, just issue: # authconfig --enablemkhomedir --update More info is in manual pages of authconfig or use authconfig --help Kind regards, / S pozdravom, Martin ?tefany On Dec 9, 2015 7:34 PM, Ranbir wrote: > > Hello Everyone, > > I installed a replica without passing the "mkhomedir" option to the > install command. Sure enough, when I login to the replica, my home dir > isn't created. I _could_ create it manually, but it would be nice if the > first login triggered the creation. > > I've been trying to find an answer to this on my own, but so far I've > had no luck. > > Thanks in advance! > > -- > Ranbir > > -- > 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 From ftweedal at redhat.com Wed Dec 9 23:48:35 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 10 Dec 2015 09:48:35 +1000 Subject: [Freeipa-users] Certificate Profile - Policy Set Not Found In-Reply-To: <2CA71D6C07ADB544847562573DC6BF061857806C@CPEMS-KPN309.KPNCNL.LOCAL> References: <2CA71D6C07ADB544847562573DC6BF061857806C@CPEMS-KPN309.KPNCNL.LOCAL> Message-ID: <20151209234835.GR23644@dhcp-40-8.bne.redhat.com> On Wed, Dec 09, 2015 at 10:46:06AM +0000, wouter.hummelink at kpn.com wrote: > Hello, > > Im trying to import and use a certificate profile in IPAv4.2 on RHEL. > > I've exported the default caIPAServiceCert profile and did the following modification: > < profileId=caIPAserviceCert > --- > > profileId=KPNWebhostingAEM > 87c87 > < policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, O=IPADOMAIN > --- > > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, OU=TESTAEM, O=IPADOMAIN > > Profile > Profile ID: KPNWebhostingAEM > Profile description: KPN Webhosting AEM > Store issued certificates: TRUE > > CAACL > ACL name: ING Intermediairs AEM Application Servers > Enabled: TRUE > Profiles: KPNWebhostingServiceCertAEM, KPNWebhostingAEM > Host Groups: xxx_accp_applications, xxx_prod_applications > > Trying to request a certificate for a server > ipa-getcert request -r -I mongo2 -f /etc/pki/tls/certs/host.crt -k /etc/pki/tls/certs/host.key -TKPNWebhostingAEM > > Results in: > ipa-getcert list > Number of certificates and requests being tracked: 1. > Request ID 'mongo2': > status: CA_UNREACHABLE > ca-error: Server at https://pvlipa1001c.ipadomain/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Policy Set Not Found)). > stuck: no > key pair storage: type=FILE,location='/etc/pki/tls/certs/host.key' > certificate: type=FILE,location='/etc/pki/tls/certs/host.crt' > CA: IPA > issuer: > subject: > expires: unknown > pre-save command: > post-save command: > track: yes > auto-renew: yes > > Since the same setup was working to request certificates on my lab environment I'm at a loss what is causing the error. > > Met vriendelijke groet, > Hi Wouter, I'm looking into this; stay tuned. Fraser > Wouter Hummelink > Cloud Engineer > [Description: Beschrijving: Beschrijving: cid:image003.gif at 01CC7CE9.FCFEC140] > KPN IT Solutions > Platform Organisation Cloud Services > Mail: wouter.hummelink at kpn.com > Telefoon: +31 (0)6 1288 2447 > [cid:image002.png at 01D0DA65.706AE4B0] > P Save Paper - Do you really need to print this e-mail? > ********************************************************************************************************************************************************* > KPN IT SOLUTIONS is de 'handelsnaam' voor KPN Corporate Market BV, Handelsregister 52959597 Amsterdam > The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. > Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons > and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately > and delete the material. 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 From ftweedal at redhat.com Thu Dec 10 02:58:05 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 10 Dec 2015 12:58:05 +1000 Subject: [Freeipa-users] Certificate Profile - Policy Set Not Found In-Reply-To: <20151209234835.GR23644@dhcp-40-8.bne.redhat.com> References: <2CA71D6C07ADB544847562573DC6BF061857806C@CPEMS-KPN309.KPNCNL.LOCAL> <20151209234835.GR23644@dhcp-40-8.bne.redhat.com> Message-ID: <20151210025805.GS23644@dhcp-40-8.bne.redhat.com> On Thu, Dec 10, 2015 at 09:48:35AM +1000, Fraser Tweedale wrote: > On Wed, Dec 09, 2015 at 10:46:06AM +0000, wouter.hummelink at kpn.com wrote: > > Hello, > > > > Im trying to import and use a certificate profile in IPAv4.2 on RHEL. > > > > I've exported the default caIPAServiceCert profile and did the following modification: > > < profileId=caIPAserviceCert > > --- > > > profileId=KPNWebhostingAEM > > 87c87 > > < policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, O=IPADOMAIN > > --- > > > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, OU=TESTAEM, O=IPADOMAIN > > > > Profile > > Profile ID: KPNWebhostingAEM > > Profile description: KPN Webhosting AEM > > Store issued certificates: TRUE > > > > CAACL > > ACL name: ING Intermediairs AEM Application Servers > > Enabled: TRUE > > Profiles: KPNWebhostingServiceCertAEM, KPNWebhostingAEM > > Host Groups: xxx_accp_applications, xxx_prod_applications > > > > Trying to request a certificate for a server > > ipa-getcert request -r -I mongo2 -f /etc/pki/tls/certs/host.crt -k /etc/pki/tls/certs/host.key -TKPNWebhostingAEM > > > > Results in: > > ipa-getcert list > > Number of certificates and requests being tracked: 1. > > Request ID 'mongo2': > > status: CA_UNREACHABLE > > ca-error: Server at https://pvlipa1001c.ipadomain/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Policy Set Not Found)). > > stuck: no > > key pair storage: type=FILE,location='/etc/pki/tls/certs/host.key' > > certificate: type=FILE,location='/etc/pki/tls/certs/host.crt' > > CA: IPA > > issuer: > > subject: > > expires: unknown > > pre-save command: > > post-save command: > > track: yes > > auto-renew: yes > > > > Since the same setup was working to request certificates on my lab environment I'm at a loss what is causing the error. > > > > Met vriendelijke groet, > > > Hi Wouter, > > I'm looking into this; stay tuned. > OK, I could not reproduce. Is the issue reproducible for you? Did you execute the commands by hand or as part of a script? Can you provide your PKI debug log (/var/log/pki/pki-tomcat/ca/debug/)? Cheers, Fraser From ftweedal at redhat.com Thu Dec 10 03:04:33 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 10 Dec 2015 13:04:33 +1000 Subject: [Freeipa-users] Certificate Profile - Policy Set Not Found In-Reply-To: <20151210025805.GS23644@dhcp-40-8.bne.redhat.com> References: <2CA71D6C07ADB544847562573DC6BF061857806C@CPEMS-KPN309.KPNCNL.LOCAL> <20151209234835.GR23644@dhcp-40-8.bne.redhat.com> <20151210025805.GS23644@dhcp-40-8.bne.redhat.com> Message-ID: <20151210030433.GT23644@dhcp-40-8.bne.redhat.com> On Thu, Dec 10, 2015 at 12:58:05PM +1000, Fraser Tweedale wrote: > On Thu, Dec 10, 2015 at 09:48:35AM +1000, Fraser Tweedale wrote: > > On Wed, Dec 09, 2015 at 10:46:06AM +0000, wouter.hummelink at kpn.com wrote: > > > Hello, > > > > > > Im trying to import and use a certificate profile in IPAv4.2 on RHEL. > > > > > > I've exported the default caIPAServiceCert profile and did the following modification: > > > < profileId=caIPAserviceCert > > > --- > > > > profileId=KPNWebhostingAEM > > > 87c87 > > > < policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, O=IPADOMAIN > > > --- > > > > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, OU=TESTAEM, O=IPADOMAIN > > > > > > Profile > > > Profile ID: KPNWebhostingAEM > > > Profile description: KPN Webhosting AEM > > > Store issued certificates: TRUE > > > > > > CAACL > > > ACL name: ING Intermediairs AEM Application Servers > > > Enabled: TRUE > > > Profiles: KPNWebhostingServiceCertAEM, KPNWebhostingAEM > > > Host Groups: xxx_accp_applications, xxx_prod_applications > > > > > > Trying to request a certificate for a server > > > ipa-getcert request -r -I mongo2 -f /etc/pki/tls/certs/host.crt -k /etc/pki/tls/certs/host.key -TKPNWebhostingAEM > > > > > > Results in: > > > ipa-getcert list > > > Number of certificates and requests being tracked: 1. > > > Request ID 'mongo2': > > > status: CA_UNREACHABLE > > > ca-error: Server at https://pvlipa1001c.ipadomain/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Policy Set Not Found)). > > > stuck: no > > > key pair storage: type=FILE,location='/etc/pki/tls/certs/host.key' > > > certificate: type=FILE,location='/etc/pki/tls/certs/host.crt' > > > CA: IPA > > > issuer: > > > subject: > > > expires: unknown > > > pre-save command: > > > post-save command: > > > track: yes > > > auto-renew: yes > > > > > > Since the same setup was working to request certificates on my lab environment I'm at a loss what is causing the error. > > > > > > Met vriendelijke groet, > > > > > Hi Wouter, > > > > I'm looking into this; stay tuned. > > > OK, I could not reproduce. Is the issue reproducible for you? Did > you execute the commands by hand or as part of a script? Can you > provide your PKI debug log (/var/log/pki/pki-tomcat/ca/debug/)? > Oh, and did you make any changes to the profile configuration besides those you mentioned; the profileId and Subject Name pattern? > > Cheers, > Fraser From wouter.hummelink at kpn.com Thu Dec 10 07:01:38 2015 From: wouter.hummelink at kpn.com (wouter.hummelink at kpn.com) Date: Thu, 10 Dec 2015 07:01:38 +0000 Subject: [Freeipa-users] Certificate Profile - Policy Set Not Found In-Reply-To: <20151210030433.GT23644@dhcp-40-8.bne.redhat.com> References: <2CA71D6C07ADB544847562573DC6BF061857806C@CPEMS-KPN309.KPNCNL.LOCAL> <20151209234835.GR23644@dhcp-40-8.bne.redhat.com> <20151210025805.GS23644@dhcp-40-8.bne.redhat.com>, <20151210030433.GT23644@dhcp-40-8.bne.redhat.com> Message-ID: I did change profile Id as shown in the diff. No other changes. Verzonden vanaf mijn Samsung-apparaat -------- Oorspronkelijk bericht -------- Van: Fraser Tweedale Datum: 2015-12-10 04:04 (GMT+01:00) Aan: "Hummelink, Wouter" Cc: freeipa-users at redhat.com Onderwerp: Re: [Freeipa-users] Certificate Profile - Policy Set Not Found On Thu, Dec 10, 2015 at 12:58:05PM +1000, Fraser Tweedale wrote: > On Thu, Dec 10, 2015 at 09:48:35AM +1000, Fraser Tweedale wrote: > > On Wed, Dec 09, 2015 at 10:46:06AM +0000, wouter.hummelink at kpn.com wrote: > > > Hello, > > > > > > Im trying to import and use a certificate profile in IPAv4.2 on RHEL. > > > > > > I've exported the default caIPAServiceCert profile and did the following modification: > > > < profileId=caIPAserviceCert > > > --- > > > > profileId=KPNWebhostingAEM > > > 87c87 > > > < policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, O=IPADOMAIN > > > --- > > > > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, OU=TESTAEM, O=IPADOMAIN > > > > > > Profile > > > Profile ID: KPNWebhostingAEM > > > Profile description: KPN Webhosting AEM > > > Store issued certificates: TRUE > > > > > > CAACL > > > ACL name: ING Intermediairs AEM Application Servers > > > Enabled: TRUE > > > Profiles: KPNWebhostingServiceCertAEM, KPNWebhostingAEM > > > Host Groups: xxx_accp_applications, xxx_prod_applications > > > > > > Trying to request a certificate for a server > > > ipa-getcert request -r -I mongo2 -f /etc/pki/tls/certs/host.crt -k /etc/pki/tls/certs/host.key -TKPNWebhostingAEM > > > > > > Results in: > > > ipa-getcert list > > > Number of certificates and requests being tracked: 1. > > > Request ID 'mongo2': > > > status: CA_UNREACHABLE > > > ca-error: Server at https://pvlipa1001c.ipadomain/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Policy Set Not Found)). > > > stuck: no > > > key pair storage: type=FILE,location='/etc/pki/tls/certs/host.key' > > > certificate: type=FILE,location='/etc/pki/tls/certs/host.crt' > > > CA: IPA > > > issuer: > > > subject: > > > expires: unknown > > > pre-save command: > > > post-save command: > > > track: yes > > > auto-renew: yes > > > > > > Since the same setup was working to request certificates on my lab environment I'm at a loss what is causing the error. > > > > > > Met vriendelijke groet, > > > > > Hi Wouter, > > > > I'm looking into this; stay tuned. > > > OK, I could not reproduce. Is the issue reproducible for you? Did > you execute the commands by hand or as part of a script? Can you > provide your PKI debug log (/var/log/pki/pki-tomcat/ca/debug/)? > Oh, and did you make any changes to the profile configuration besides those you mentioned; the profileId and Subject Name pattern? > > Cheers, > Fraser -------------- next part -------------- An HTML attachment was scrubbed... URL: From wouter.hummelink at kpn.com Thu Dec 10 07:04:33 2015 From: wouter.hummelink at kpn.com (wouter.hummelink at kpn.com) Date: Thu, 10 Dec 2015 07:04:33 +0000 Subject: [Freeipa-users] Certificate Profile - Policy Set Not Found In-Reply-To: <20151210025805.GS23644@dhcp-40-8.bne.redhat.com> References: <2CA71D6C07ADB544847562573DC6BF061857806C@CPEMS-KPN309.KPNCNL.LOCAL> <20151209234835.GR23644@dhcp-40-8.bne.redhat.com>, <20151210025805.GS23644@dhcp-40-8.bne.redhat.com> Message-ID: I'll send the log as soon as I get a chance. After the mail I also tried fetching a cert on another server cent7.1 that never had a cert issued. This resulted in a cert conformant With caIpaServiceCert Verzonden vanaf mijn Samsung-apparaat -------- Oorspronkelijk bericht -------- Van: Fraser Tweedale Datum: 2015-12-10 03:58 (GMT+01:00) Aan: "Hummelink, Wouter" Cc: freeipa-users at redhat.com Onderwerp: Re: [Freeipa-users] Certificate Profile - Policy Set Not Found On Thu, Dec 10, 2015 at 09:48:35AM +1000, Fraser Tweedale wrote: > On Wed, Dec 09, 2015 at 10:46:06AM +0000, wouter.hummelink at kpn.com wrote: > > Hello, > > > > Im trying to import and use a certificate profile in IPAv4.2 on RHEL. > > > > I've exported the default caIPAServiceCert profile and did the following modification: > > < profileId=caIPAserviceCert > > --- > > > profileId=KPNWebhostingAEM > > 87c87 > > < policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, O=IPADOMAIN > > --- > > > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, OU=TESTAEM, O=IPADOMAIN > > > > Profile > > Profile ID: KPNWebhostingAEM > > Profile description: KPN Webhosting AEM > > Store issued certificates: TRUE > > > > CAACL > > ACL name: ING Intermediairs AEM Application Servers > > Enabled: TRUE > > Profiles: KPNWebhostingServiceCertAEM, KPNWebhostingAEM > > Host Groups: xxx_accp_applications, xxx_prod_applications > > > > Trying to request a certificate for a server > > ipa-getcert request -r -I mongo2 -f /etc/pki/tls/certs/host.crt -k /etc/pki/tls/certs/host.key -TKPNWebhostingAEM > > > > Results in: > > ipa-getcert list > > Number of certificates and requests being tracked: 1. > > Request ID 'mongo2': > > status: CA_UNREACHABLE > > ca-error: Server at https://pvlipa1001c.ipadomain/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Policy Set Not Found)). > > stuck: no > > key pair storage: type=FILE,location='/etc/pki/tls/certs/host.key' > > certificate: type=FILE,location='/etc/pki/tls/certs/host.crt' > > CA: IPA > > issuer: > > subject: > > expires: unknown > > pre-save command: > > post-save command: > > track: yes > > auto-renew: yes > > > > Since the same setup was working to request certificates on my lab environment I'm at a loss what is causing the error. > > > > Met vriendelijke groet, > > > Hi Wouter, > > I'm looking into this; stay tuned. > OK, I could not reproduce. Is the issue reproducible for you? Did you execute the commands by hand or as part of a script? Can you provide your PKI debug log (/var/log/pki/pki-tomcat/ca/debug/)? Cheers, Fraser -------------- next part -------------- An HTML attachment was scrubbed... URL: From wouter.hummelink at kpn.com Thu Dec 10 07:32:13 2015 From: wouter.hummelink at kpn.com (wouter.hummelink at kpn.com) Date: Thu, 10 Dec 2015 07:32:13 +0000 Subject: [Freeipa-users] Certificate Profile - Policy Set Not Found In-Reply-To: References: <2CA71D6C07ADB544847562573DC6BF061857806C@CPEMS-KPN309.KPNCNL.LOCAL> <20151209234835.GR23644@dhcp-40-8.bne.redhat.com>, <20151210025805.GS23644@dhcp-40-8.bne.redhat.com> Message-ID: <2CA71D6C07ADB544847562573DC6BF0618579F38@CPEMS-KPN309.KPNCNL.LOCAL> Attached are yesterdays debug log from pki-tomcat I tried these actions several times, both scripted and manually Curiously, I did a resubmit just now and I got issued a correct certificate. Van: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] Namens wouter.hummelink at kpn.com Verzonden: donderdag 10 december 2015 08:05 Aan: ftweedal at redhat.com CC: freeipa-users at redhat.com Onderwerp: Re: [Freeipa-users] Certificate Profile - Policy Set Not Found I'll send the log as soon as I get a chance. After the mail I also tried fetching a cert on another server cent7.1 that never had a cert issued. This resulted in a cert conformant With caIpaServiceCert Verzonden vanaf mijn Samsung-apparaat -------- Oorspronkelijk bericht -------- Van: Fraser Tweedale > Datum: 2015-12-10 03:58 (GMT+01:00) Aan: "Hummelink, Wouter" > Cc: freeipa-users at redhat.com Onderwerp: Re: [Freeipa-users] Certificate Profile - Policy Set Not Found On Thu, Dec 10, 2015 at 09:48:35AM +1000, Fraser Tweedale wrote: > On Wed, Dec 09, 2015 at 10:46:06AM +0000, wouter.hummelink at kpn.com wrote: > > Hello, > > > > Im trying to import and use a certificate profile in IPAv4.2 on RHEL. > > > > I've exported the default caIPAServiceCert profile and did the following modification: > > < profileId=caIPAserviceCert > > --- > > > profileId=KPNWebhostingAEM > > 87c87 > > < policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, O=IPADOMAIN > > --- > > > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, OU=TESTAEM, O=IPADOMAIN > > > > Profile > > Profile ID: KPNWebhostingAEM > > Profile description: KPN Webhosting AEM > > Store issued certificates: TRUE > > > > CAACL > > ACL name: ING Intermediairs AEM Application Servers > > Enabled: TRUE > > Profiles: KPNWebhostingServiceCertAEM, KPNWebhostingAEM > > Host Groups: xxx_accp_applications, xxx_prod_applications > > > > Trying to request a certificate for a server > > ipa-getcert request -r -I mongo2 -f /etc/pki/tls/certs/host.crt -k /etc/pki/tls/certs/host.key -TKPNWebhostingAEM > > > > Results in: > > ipa-getcert list > > Number of certificates and requests being tracked: 1. > > Request ID 'mongo2': > > status: CA_UNREACHABLE > > ca-error: Server at https://pvlipa1001c.ipadomain/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Policy Set Not Found)). > > stuck: no > > key pair storage: type=FILE,location='/etc/pki/tls/certs/host.key' > > certificate: type=FILE,location='/etc/pki/tls/certs/host.crt' > > CA: IPA > > issuer: > > subject: > > expires: unknown > > pre-save command: > > post-save command: > > track: yes > > auto-renew: yes > > > > Since the same setup was working to request certificates on my lab environment I'm at a loss what is causing the error. > > > > Met vriendelijke groet, > > > Hi Wouter, > > I'm looking into this; stay tuned. > OK, I could not reproduce. Is the issue reproducible for you? Did you execute the commands by hand or as part of a script? Can you provide your PKI debug log (/var/log/pki/pki-tomcat/ca/debug/)? Cheers, Fraser -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-debug.log.gz Type: application/x-gzip Size: 141988 bytes Desc: pki-debug.log.gz URL: From ftweedal at redhat.com Thu Dec 10 09:14:25 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 10 Dec 2015 19:14:25 +1000 Subject: [Freeipa-users] Certificate Profile - Policy Set Not Found In-Reply-To: References: <2CA71D6C07ADB544847562573DC6BF061857806C@CPEMS-KPN309.KPNCNL.LOCAL> <20151209234835.GR23644@dhcp-40-8.bne.redhat.com> <20151210025805.GS23644@dhcp-40-8.bne.redhat.com> Message-ID: <20151210091424.GV23644@dhcp-40-8.bne.redhat.com> On Thu, Dec 10, 2015 at 07:04:33AM +0000, wouter.hummelink at kpn.com wrote: > I'll send the log as soon as I get a chance. After the mail I also tried fetching a cert on another server cent7.1 that never had a cert issued. This resulted in a cert conformant > With caIpaServiceCert > That is expected behaviour - only RHEL 7.2 version of Certmonger propagates the requested profile (`-T' option) to the IPA CA. > > Verzonden vanaf mijn Samsung-apparaat > > > -------- Oorspronkelijk bericht -------- > Van: Fraser Tweedale > Datum: 2015-12-10 03:58 (GMT+01:00) > Aan: "Hummelink, Wouter" > Cc: freeipa-users at redhat.com > Onderwerp: Re: [Freeipa-users] Certificate Profile - Policy Set Not Found > > On Thu, Dec 10, 2015 at 09:48:35AM +1000, Fraser Tweedale wrote: > > On Wed, Dec 09, 2015 at 10:46:06AM +0000, wouter.hummelink at kpn.com wrote: > > > Hello, > > > > > > Im trying to import and use a certificate profile in IPAv4.2 on RHEL. > > > > > > I've exported the default caIPAServiceCert profile and did the following modification: > > > < profileId=caIPAserviceCert > > > --- > > > > profileId=KPNWebhostingAEM > > > 87c87 > > > < policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, O=IPADOMAIN > > > --- > > > > policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, OU=TESTAEM, O=IPADOMAIN > > > > > > Profile > > > Profile ID: KPNWebhostingAEM > > > Profile description: KPN Webhosting AEM > > > Store issued certificates: TRUE > > > > > > CAACL > > > ACL name: ING Intermediairs AEM Application Servers > > > Enabled: TRUE > > > Profiles: KPNWebhostingServiceCertAEM, KPNWebhostingAEM > > > Host Groups: xxx_accp_applications, xxx_prod_applications > > > > > > Trying to request a certificate for a server > > > ipa-getcert request -r -I mongo2 -f /etc/pki/tls/certs/host.crt -k /etc/pki/tls/certs/host.key -TKPNWebhostingAEM > > > > > > Results in: > > > ipa-getcert list > > > Number of certificates and requests being tracked: 1. > > > Request ID 'mongo2': > > > status: CA_UNREACHABLE > > > ca-error: Server at https://pvlipa1001c.ipadomain/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Policy Set Not Found)). > > > stuck: no > > > key pair storage: type=FILE,location='/etc/pki/tls/certs/host.key' > > > certificate: type=FILE,location='/etc/pki/tls/certs/host.crt' > > > CA: IPA > > > issuer: > > > subject: > > > expires: unknown > > > pre-save command: > > > post-save command: > > > track: yes > > > auto-renew: yes > > > > > > Since the same setup was working to request certificates on my lab environment I'm at a loss what is causing the error. > > > > > > Met vriendelijke groet, > > > > > Hi Wouter, > > > > I'm looking into this; stay tuned. > > > OK, I could not reproduce. Is the issue reproducible for you? Did > you execute the commands by hand or as part of a script? Can you > provide your PKI debug log (/var/log/pki/pki-tomcat/ca/debug/)? > > Cheers, > Fraser From mkosek at redhat.com Thu Dec 10 10:25:57 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Dec 2015 11:25:57 +0100 Subject: [Freeipa-users] Trusted Domain Users - entry_cache_timeout In-Reply-To: <5668175F.9080903@dds.nl> References: <5668175F.9080903@dds.nl> Message-ID: <56695335.9060601@redhat.com> On 12/09/2015 12:58 PM, Winfried de Heiden wrote: > Hi all, > > Using entry_cache_timeout to set different cache timeout for sssd works well. > However, it doesn't seem to work for Trusted Domain Users (using AD trust) > > I made some changes, cleaned the cache but expiry will stay on a (too long) 10 > (ten!) hours! > > How can I change the sssd cache timeout for Trusted AD users ? (using IPA 4.1) > > Kind regards! I assume the option has to be specified in the respective AD domain section. Can you share your anonymized sssd.conf so that we can verify your settings? From mkosek at redhat.com Thu Dec 10 10:32:44 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Dec 2015 11:32:44 +0100 Subject: [Freeipa-users] FreeRadius and FreeIPA In-Reply-To: <56684014.9060001@chem.byu.edu> References: <56684014.9060001@chem.byu.edu> Message-ID: <566954CC.6010006@redhat.com> On 12/09/2015 03:52 PM, Randy Morgan wrote: > Hello, > > We are setting up our wireless to authenticate against FreeRadius and FreeIPA. > I am looking for any instructions on how to integrate radius with IPA. We can > get them talking via kerberos, but when we have a wireless client attempt to > authenticate against them, the password gets stripped out and only the username > gets passed on, resulting in a failed logon attempt. > > As we have studied the problem we have identified the communication protocols > used by wireless to pass on the user credentials to radius. Wireless uses EAP > as it's primary protocol. We are running Xirrus wireless APs and from what we > can learn, they act only as a pass through conduit for the client. Ideally we > would like them to speak PEAP TTLS, this would allow kerberos to process from > the client to the IPA server, we are still researching this. > > Are there any instructions on how to integrate FreeRadius 3.0.10 with FreeIPA > 3.3.5? Any help would be appreciated. > > Randy Hi, What articles did you test so far? I did not try it myself, but google gives out some idea: http://readlist.com/lists/lists.freeradius.org/freeradius-users/13/69142.html http://consultancy.edvoncken.net/index.php/HOWTO_Configure_Radius_with_an_IPA_Server https://plus.google.com/104747154449640814740/posts/SxU8to5J2r6 Martin From mkosek at redhat.com Thu Dec 10 10:34:06 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Dec 2015 11:34:06 +0100 Subject: [Freeipa-users] yum update today broke ipa In-Reply-To: <56686E2C.1080208@redhat.com> References: <56685373.5050701@redhat.com> <56685560.10308@redhat.com> <56686E2C.1080208@redhat.com> Message-ID: <5669551E.5060306@redhat.com> This is the Bugzilla with more details BTW: https://bugzilla.redhat.com/show_bug.cgi?id=1290142#c3 On 12/09/2015 07:08 PM, Martin Basti wrote: > You can safely upgrade all machines, this is just version check error. > > On 09.12.2015 17:30, Prasun Gera wrote: >> Thanks! That worked. The command passed, and I don't see any other odd >> behaviour yet. I'll wait for a new fixed errata before upgrading the other >> node. That should be OK right ? i.e. Running replicas on slightly different >> versions. >> >> On Wed, Dec 9, 2015 at 8:22 AM, Martin Basti > > wrote: >> >> Run upgrade manually, this is just error in checking function, >> obviously 4.2.0-15.el7_2.3 is never than 4.2.0-15.el7 >> >> >> On 09.12.2015 17:21, Prasun Gera wrote: >>> Before I try this on the actual node, would it be better to roll >>> back the last yum transaction ? I want to do whatever is safer. >>> >>> On Wed, Dec 9, 2015 at 8:14 AM, Martin Basti >> > wrote: >>> >>> >>> >>> On 09.12.2015 16:32, Prasun Gera wrote: >>>> Ran yum update today. Pulled in >>>> https://rhn.redhat.com/errata/RHBA-2015-2562.html. >>>> >>>> Seeing this error: >>>> >>>> 2015-12-09T15:21:02Z DEBUG The ipa-server-upgrade command >>>> failed, exception: ScriptError: ("Unable to execute IPA >>>> upgrade: data are in newer version than IPA (data version >>>> '4.2.0-15.el7', IPA version '4.2.0-15.el7_2.3')", 1) >>>> 2015-12-09T15:21:02Z ERROR ("Unable to execute IPA upgrade: >>>> data are in newer version than IPA (data version >>>> '4.2.0-15.el7', IPA version '4.2.0-15.el7_2.3')", 1) >>>> "/var/log/ipaupgrade.log" 54696L, 5389464C >>>> >>>> ipactl won't start now. Luckily, I ran the update only on >>>> one replica. The other node is still running. >>>> >>>> >>> Hello, this is not good, something terrible wrong happened >>> with parsing versions. >>> >>> You can run upgrade with ipa-server-upgrade >>> --skip-version-check or --force >>> >>> >> >> > > > > From jhrozek at redhat.com Thu Dec 10 10:43:48 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 10 Dec 2015 11:43:48 +0100 Subject: [Freeipa-users] Trusted Domain Users - entry_cache_timeout In-Reply-To: <56695335.9060601@redhat.com> References: <5668175F.9080903@dds.nl> <56695335.9060601@redhat.com> Message-ID: <20151210104347.GH3995@hendrix.arn.redhat.com> On Thu, Dec 10, 2015 at 11:25:57AM +0100, Martin Kosek wrote: > On 12/09/2015 12:58 PM, Winfried de Heiden wrote: > > Hi all, > > > > Using entry_cache_timeout to set different cache timeout for sssd works well. > > However, it doesn't seem to work for Trusted Domain Users (using AD trust) > > > > I made some changes, cleaned the cache but expiry will stay on a (too long) 10 > > (ten!) hours! > > > > How can I change the sssd cache timeout for Trusted AD users ? (using IPA 4.1) > > > > Kind regards! > > I assume the option has to be specified in the respective AD domain section. > Can you share your anonymized sssd.conf so that we can verify your settings? Looks like I'm having issues replying to the freeipa-users list or maybe the mails are stuck in moderation. Let me paste the mail I sent yesterday: ~~~~~~~~~~~~~~~ Since it's the IPA master that fetches the identity data from the AD server, you also need to change the cache timeouts on the server. In addition, the cache time lifetime is stored in the cache entry itself, so you might want to invalidate the cache with sss_cache on both the server and the client. ~~~~~~~~~~~~~~~ From pspacek at redhat.com Thu Dec 10 11:51:19 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 10 Dec 2015 12:51:19 +0100 Subject: [Freeipa-users] FreeIPA DNSSEC NSEC3PARAM record In-Reply-To: <3267566.oWNlBILFrx@techz> References: <3267566.oWNlBILFrx@techz> Message-ID: <56696737.8090007@redhat.com> On 9.12.2015 14:40, G?nther J. Niederwimmer wrote: > Hello, > > I like to create a NSEC3PARAM Record but my tests are not working :-(. > > Is there a documentation for this Problem I can't found a DOCU > > My test is > > I make a "Salt" with this > > head -c 512 /dev/random | sha1sum | cut -b 1-16 > xxxxxxxxxxxxx... > > afterward i make with > ldns-nsec3-hash -t 10 -s xxxxxxxxxxxxxxxxxx xxxxx.com > xxxxx..... > > the result i like to insert in the WebUI but this is wrong ? > > What is the correct syntax to create a NSEC3PARAM record? > > Thanks for a answer, > Hello, FreeIPA just passes the value to BIND, so standard syntax per http://tools.ietf.org/html/rfc5155#section-4.3 should work. I hope this helps. -- Petr^2 Spacek From wdh at dds.nl Thu Dec 10 13:09:26 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Thu, 10 Dec 2015 14:09:26 +0100 Subject: [Freeipa-users] Trusted Domain Users - entry_cache_timeout In-Reply-To: <56695335.9060601@redhat.com> References: <5668175F.9080903@dds.nl> <56695335.9060601@redhat.com> Message-ID: <56697986.5040901@dds.nl> An HTML attachment was scrubbed... URL: From gjn at gjn.priv.at Thu Dec 10 15:05:00 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Thu, 10 Dec 2015 16:05:00 +0100 Subject: [Freeipa-users] FreeIPA DNSSEC NSEC3PARAM record In-Reply-To: <56696737.8090007@redhat.com> References: <3267566.oWNlBILFrx@techz> <56696737.8090007@redhat.com> Message-ID: <1819853.Zemz8iNKaH@techz> Am Thursday 10 December 2015, 12:51:19 schrieb Petr Spacek: > On 9.12.2015 14:40, G?nther J. Niederwimmer wrote: > > Hello, > > > > I like to create a NSEC3PARAM Record but my tests are not working :-(. > > > > Is there a documentation for this Problem I can't found a DOCU > > > > My test is > > > > I make a "Salt" with this > > > > head -c 512 /dev/random | sha1sum | cut -b 1-16 > > xxxxxxxxxxxxx... > > > > afterward i make with > > ldns-nsec3-hash -t 10 -s xxxxxxxxxxxxxxxxxx xxxxx.com > > xxxxx..... > > > > the result i like to insert in the WebUI but this is wrong ? > > > > What is the correct syntax to create a NSEC3PARAM record? > > > > Thanks for a answer, > > Hello, > > FreeIPA just passes the value to BIND, so standard syntax per > http://tools.ietf.org/html/rfc5155#section-4.3 > should work. > > I hope this helps. ;-) I am not a Mathematic Professor to understand this ;-) OK, I have to search again in World Wide Web to find a answer. -- mit freundlichen Gr??en / best regards, G?nther J. Niederwimmer From jhrozek at redhat.com Thu Dec 10 16:21:30 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 10 Dec 2015 17:21:30 +0100 Subject: [Freeipa-users] Trusted Domain Users - entry_cache_timeout In-Reply-To: <20151210104347.GH3995@hendrix.arn.redhat.com> References: <5668175F.9080903@dds.nl> <56695335.9060601@redhat.com> <20151210104347.GH3995@hendrix.arn.redhat.com> Message-ID: <20151210162130.GF5795@hendrix.arn.redhat.com> On Thu, Dec 10, 2015 at 11:43:48AM +0100, Jakub Hrozek wrote: > On Thu, Dec 10, 2015 at 11:25:57AM +0100, Martin Kosek wrote: > > On 12/09/2015 12:58 PM, Winfried de Heiden wrote: > > > Hi all, > > > > > > Using entry_cache_timeout to set different cache timeout for sssd works well. > > > However, it doesn't seem to work for Trusted Domain Users (using AD trust) > > > > > > I made some changes, cleaned the cache but expiry will stay on a (too long) 10 > > > (ten!) hours! > > > > > > How can I change the sssd cache timeout for Trusted AD users ? (using IPA 4.1) > > > > > > Kind regards! > > > > I assume the option has to be specified in the respective AD domain section. > > Can you share your anonymized sssd.conf so that we can verify your settings? > > Looks like I'm having issues replying to the freeipa-users list or maybe > the mails are stuck in moderation. > > Let me paste the mail I sent yesterday: > > ~~~~~~~~~~~~~~~ > Since it's the IPA master that fetches the identity data from the AD > server, you also need to change the cache timeouts on the server. In > addition, the cache time lifetime is stored in the cache entry itself, > so you might want to invalidate the cache with sss_cache on both the > server and the client. > ~~~~~~~~~~~~~~~ I'm sorry, I should test stuff before replying next time :-( Unfortunately you're right: 1736 static errno_t ipa_s2n_save_objects(struct sss_domain_info *dom, 1737 struct req_input *req_input, 1738 struct resp_attrs *attrs, 1739 struct resp_attrs *simple_attrs, 1740 const char *view_name, 1741 struct sysdb_attrs *override_attrs, 1742 bool update_initgr_timeout) 1743 { 1744 int ret; 1745 time_t now; 1746 uint64_t timeout = 10*60*60; /* FIXME: find a better timeout ! */ Please work with support (the support engineers tell me you already opened a support case) to open a bug. One idea might be to temporarily extend the list of values we allow to be overriden by subdomains so that also entry_cache_timeout works for subdomain objects. But details should be decided later.. From janellenicole80 at gmail.com Thu Dec 10 17:34:53 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 10 Dec 2015 09:34:53 -0800 Subject: [Freeipa-users] otpd heavy load? Message-ID: <5669B7BD.8020404@gmail.com> Hi, Hope everyone is enjoying the holiday season. Been away for sometime, and wanted to jump in with a new question. I am seeing otpd have high resource usage (from just monitoring via top, sar and uptime) however, I can not seem to find any logging from it, nor how I might be able to enable some in order to find out why it is using so much CPU? Any thoughts/suggestions? Thank you ~J From npmccallum at redhat.com Thu Dec 10 17:55:05 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 10 Dec 2015 12:55:05 -0500 Subject: [Freeipa-users] otpd heavy load? In-Reply-To: <5669B7BD.8020404@gmail.com> References: <5669B7BD.8020404@gmail.com> Message-ID: <1449770105.23069.6.camel@redhat.com> On Thu, 2015-12-10 at 09:34 -0800, Janelle wrote: > Hi, > > Hope everyone is enjoying the holiday season. Been away for sometime, > and wanted to jump in with a new question.??I am seeing otpd have > high > resource usage (from just monitoring via top, sar and uptime) > however, I > can not seem to find any logging from it, nor how I might be able to > enable some in order to find out why it is using so much CPU? Any > thoughts/suggestions? Log messages should be available through journalctl. Which libverto backend are you running? If you are on Fedora, please provide the output of the 'rpm -qa libverto*' command. From janellenicole80 at gmail.com Thu Dec 10 18:13:01 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 10 Dec 2015 10:13:01 -0800 Subject: [Freeipa-users] otpd heavy load? In-Reply-To: <1449770105.23069.6.camel@redhat.com> References: <5669B7BD.8020404@gmail.com> <1449770105.23069.6.camel@redhat.com> Message-ID: <5669C0AD.3070603@gmail.com> RHEL 7.1 On 12/10/15 9:55 AM, Nathaniel McCallum wrote: > On Thu, 2015-12-10 at 09:34 -0800, Janelle wrote: >> Hi, >> >> Hope everyone is enjoying the holiday season. Been away for sometime, >> and wanted to jump in with a new question. I am seeing otpd have >> high >> resource usage (from just monitoring via top, sar and uptime) >> however, I >> can not seem to find any logging from it, nor how I might be able to >> enable some in order to find out why it is using so much CPU? Any >> thoughts/suggestions? > Log messages should be available through journalctl. > > Which libverto backend are you running? If you are on Fedora, please > provide the output of the 'rpm -qa libverto*' command. From stacy.redmond at blueshieldca.com Thu Dec 10 18:24:49 2015 From: stacy.redmond at blueshieldca.com (Redmond, Stacy) Date: Thu, 10 Dec 2015 18:24:49 +0000 Subject: [Freeipa-users] Service Accounts via IPA Message-ID: <5434D6A65FEF2B428D5CC8D77FA7DA713B6D7325@wexc201p.bsc.bscal.com> Generally I will lock a service account on linux so that the account cannot login, but users can sudo su - to that user. As I don't have access to the password field in free ipa, what are my options to set this up as a default for service accounts, or how can I modify individual accounts that need access to a system, but should not be able to login to the system. Any help is appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Thu Dec 10 18:49:03 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 10 Dec 2015 13:49:03 -0500 Subject: [Freeipa-users] otpd heavy load? In-Reply-To: <5669C0AD.3070603@gmail.com> References: <5669B7BD.8020404@gmail.com> <1449770105.23069.6.camel@redhat.com> <5669C0AD.3070603@gmail.com> Message-ID: <1449773343.23069.7.camel@redhat.com> Please provide the output of the 'rpm -qa libverto*' command. On Thu, 2015-12-10 at 10:13 -0800, Janelle wrote: > RHEL 7.1 > > On 12/10/15 9:55 AM, Nathaniel McCallum wrote: > > On Thu, 2015-12-10 at 09:34 -0800, Janelle wrote: > > > Hi, > > > > > > Hope everyone is enjoying the holiday season. Been away for > > > sometime, > > > and wanted to jump in with a new question.??I am seeing otpd have > > > high > > > resource usage (from just monitoring via top, sar and uptime) > > > however, I > > > can not seem to find any logging from it, nor how I might be able > > > to > > > enable some in order to find out why it is using so much CPU? Any > > > thoughts/suggestions? > > Log messages should be available through journalctl. > > > > Which libverto backend are you running? If you are on Fedora, > > please > > provide the output of the 'rpm -qa libverto*' command. > From janellenicole80 at gmail.com Thu Dec 10 23:42:11 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 10 Dec 2015 15:42:11 -0800 Subject: [Freeipa-users] otpd heavy load? In-Reply-To: <1449773343.23069.7.camel@redhat.com> References: <5669B7BD.8020404@gmail.com> <1449770105.23069.6.camel@redhat.com> <5669C0AD.3070603@gmail.com> <1449773343.23069.7.camel@redhat.com> Message-ID: <566A0DD3.3010802@gmail.com> libverto-tevent-0.2.5-4.el7.x86_64 libverto-0.2.5-4.el7.x86_64 Patching problem perhaps? On 12/10/15 10:49 AM, Nathaniel McCallum wrote: > Please provide the output of the 'rpm -qa libverto*' command. > > On Thu, 2015-12-10 at 10:13 -0800, Janelle wrote: >> RHEL 7.1 >> >> On 12/10/15 9:55 AM, Nathaniel McCallum wrote: >>> On Thu, 2015-12-10 at 09:34 -0800, Janelle wrote: >>>> Hi, >>>> >>>> Hope everyone is enjoying the holiday season. Been away for >>>> sometime, >>>> and wanted to jump in with a new question. I am seeing otpd have >>>> high >>>> resource usage (from just monitoring via top, sar and uptime) >>>> however, I >>>> can not seem to find any logging from it, nor how I might be able >>>> to >>>> enable some in order to find out why it is using so much CPU? Any >>>> thoughts/suggestions? >>> Log messages should be available through journalctl. >>> >>> Which libverto backend are you running? If you are on Fedora, >>> please >>> provide the output of the 'rpm -qa libverto*' command. From jwest at iki.fi Fri Dec 11 07:31:47 2015 From: jwest at iki.fi (Jani West) Date: Fri, 11 Dec 2015 09:31:47 +0200 Subject: [Freeipa-users] Yum update broke CA/CS - pki-tomcatd not starting Message-ID: <566A7BE3.9000500@iki.fi> Hello, Pki-tomcatd seems to have difficulties when connecting to CA. LDAP server is starting ok when starting it directly with "systemctl start dirsrv.target". When starting "systemctl start ipa" everything else will startup exept the pki-tomcatd. Obviously same thing happens when starting with ipactl directly: [root at ipa1 ca]# ipactl start Existing service file detected! Assuming stale, cleaning and proceeding Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting named Service Starting ipa_memcached Service Starting httpd Service Starting pki-tomcatd Service Failed to start pki-tomcatd Service Shutting down Aborting ipactl /var/log/pki/pki-tomcat/localhost.2015-12-11.log SEVERE: Servlet.service() for servlet [caGetStatus] in context with path [/ca] threw exception java.io.IOException: CS server is not ready to serve. /var/log/dirsrv/slapd-PLANWEE-LOCAL/errors [11/Dec/2015:01:02:19 +0200] - slapd started. Listening on All Interfaces port 389 for LDAP requests [11/Dec/2015:01:02:19 +0200] - Listening on All Interfaces port 636 for LDAPS requests [11/Dec/2015:01:02:19 +0200] - Listening on /var/run/slapd-PLANWEE-LOCAL.socket for LDAPI requests [11/Dec/2015:01:02:19 +0200] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [11/Dec/2015:01:02:19 +0200] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) /var/log/pki/pki-tomcat/ca/debug Internal Database Error encountered: Could not connect to LDAP server host ipa1.backend.planwee.local port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) Environment: CentOS 7 IPA 4.1 The problem looks the same as this: https://access.redhat.com/solutions/2022123 Unfortunately I cannot view resolution. is this related to expired CA certificates? -- -- Jani West -- jwest at iki.fi From canepa.n at mmfg.it Fri Dec 11 07:55:11 2015 From: canepa.n at mmfg.it (Nicola Canepa) Date: Fri, 11 Dec 2015 08:55:11 +0100 Subject: [Freeipa-users] Service Accounts via IPA In-Reply-To: <5434D6A65FEF2B428D5CC8D77FA7DA713B6D7325@wexc201p.bsc.bscal.com> References: <5434D6A65FEF2B428D5CC8D77FA7DA713B6D7325@wexc201p.bsc.bscal.com> Message-ID: <566A815F.4070103@mmfg.it> Maybe you can use /usr/sbin/nologin as the shell? Nicola Il 10/12/15 19:24, Redmond, Stacy ha scritto: > > Generally I will lock a service account on linux so that the account > cannot login, but users can sudo su ? to that user. As I don?t have > access to the password field in free ipa, what are my options to set > this up as a default for service accounts, or how can I modify > individual accounts that need access to a system, but should not be > able to login to the system. Any help is appreciated. > > > -- Nicola Canepa Tel: +39-0522-399-3474 canepa.n at mmfg.it --- Il contenuto della presente comunicazione ? riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avr? valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, n? rinuncia o riconoscimento di diritti, debiti e/o crediti, n? sar? impegnativa, qualora non sia sottoscritto successivo accordo da chi pu? validamente obbligarci. Non deriver? alcuna responsabilit? precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti. The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Dec 11 08:23:20 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 11 Dec 2015 09:23:20 +0100 Subject: [Freeipa-users] Yum update broke CA/CS - pki-tomcatd not starting In-Reply-To: <566A7BE3.9000500@iki.fi> References: <566A7BE3.9000500@iki.fi> Message-ID: <566A87F8.9030303@redhat.com> On 12/11/2015 08:31 AM, Jani West wrote: > Hello, > > Pki-tomcatd seems to have difficulties when connecting to CA. LDAP > server is starting ok when starting it directly with "systemctl start > dirsrv.target". > > When starting "systemctl start ipa" everything else will startup exept the > pki-tomcatd. > > Obviously same thing happens when starting with ipactl directly: > [root at ipa1 ca]# ipactl start > Existing service file detected! > Assuming stale, cleaning and proceeding > Starting Directory Service > Starting krb5kdc Service > Starting kadmin Service > Starting named Service > Starting ipa_memcached Service > Starting httpd Service > Starting pki-tomcatd Service > Failed to start pki-tomcatd Service > Shutting down > Aborting ipactl > > > /var/log/pki/pki-tomcat/localhost.2015-12-11.log > SEVERE: Servlet.service() for servlet [caGetStatus] in context with path [/ca] > threw exception java.io.IOException: CS server is not ready to serve. > > > /var/log/dirsrv/slapd-PLANWEE-LOCAL/errors > [11/Dec/2015:01:02:19 +0200] - slapd started. Listening on All Interfaces port > 389 for LDAP requests > [11/Dec/2015:01:02:19 +0200] - Listening on All Interfaces port 636 for > LDAPS requests > [11/Dec/2015:01:02:19 +0200] - Listening on /var/run/slapd-PLANWEE-LOCAL.socket > for LDAPI requests > [11/Dec/2015:01:02:19 +0200] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not > connected) > [11/Dec/2015:01:02:19 +0200] slapi_ldap_bind - Error: could not perform > interactive bind for id [] authentication mechanism [GSSAPI]: error -1 > (Can't contact LDAP server) > > /var/log/pki/pki-tomcat/ca/debug > Internal Database Error encountered: Could not connect to LDAP server > host ipa1.backend.planwee.local port 636 Error netscape.ldap.LDAPException: IO > Error creating JSS SSL Socket (-1) > > Environment: > CentOS 7 > IPA 4.1 > > The problem looks the same as this: > https://access.redhat.com/solutions/2022123 > > Unfortunately I cannot view resolution. > > is this related to expired CA certificates? If you have expired certificates (you can check with "# getcert list | grep expires"), it could cause issues like that also. The article you are referring to is rather around wrong CA certificate trust attributes in /var/lib/pki/pki-tomcat/alias/ or /etc/dirsrv/slapd-EXAMPLE-COM/ NSS databases. You can check that with # certutil -L -d /var/lib/pki/pki-tomcat/alias/ # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM/ BTW, if you want to see the whole article or other articles from the large KB, I would suggest getting a subscription :-) From jwest at iki.fi Fri Dec 11 09:07:25 2015 From: jwest at iki.fi (Jani West) Date: Fri, 11 Dec 2015 11:07:25 +0200 Subject: [Freeipa-users] Yum update broke CA/CS - pki-tomcatd not starting In-Reply-To: <566A87F8.9030303@redhat.com> References: <566A7BE3.9000500@iki.fi> <566A87F8.9030303@redhat.com> Message-ID: <566A924D.6020906@iki.fi> Hello, Seems like I indeed have expired certs. The problem is, how I can renew these. I tried to do: --------------- root at ipa1 ca]# systemctl restart dirsrv.target [root at ipa1 ca]# ipa-cacert-manage renew Renewing CA certificate, please wait Error resubmitting certmonger request '20150814121620', please check the request manually --------------- I still have old certs: Request ID '20150814121606': status: CA_WORKING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='654666959930' certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=PLANWEE.LOCAL subject: CN=CA Audit,O=PLANWEE.LOCAL expires: 2015-09-29 20:22:26 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20150814121614': status: CA_WORKING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin='654666959930' certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=PLANWEE.LOCAL subject: CN=OCSP Subsystem,O=PLANWEE.LOCAL expires: 2015-09-29 20:22:25 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign eku: id-kp-OCSPSigning pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20150814121618': status: CA_WORKING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='654666959930' certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=PLANWEE.LOCAL subject: CN=CA Subsystem,O=PLANWEE.LOCAL expires: 2015-09-29 20:22:25 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20150814121621': status: CA_WORKING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=PLANWEE.LOCAL subject: CN=IPA RA,O=PLANWEE.LOCAL expires: 2015-09-29 20:23:10 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes On 12/11/2015 10:23 AM, Martin Kosek wrote: > On 12/11/2015 08:31 AM, Jani West wrote: >> Hello, >> >> Pki-tomcatd seems to have difficulties when connecting to CA. LDAP >> server is starting ok when starting it directly with "systemctl start >> dirsrv.target". >> >> When starting "systemctl start ipa" everything else will startup exept >> the >> pki-tomcatd. >> >> Obviously same thing happens when starting with ipactl directly: >> [root at ipa1 ca]# ipactl start >> Existing service file detected! >> Assuming stale, cleaning and proceeding >> Starting Directory Service >> Starting krb5kdc Service >> Starting kadmin Service >> Starting named Service >> Starting ipa_memcached Service >> Starting httpd Service >> Starting pki-tomcatd Service >> Failed to start pki-tomcatd Service >> Shutting down >> Aborting ipactl >> >> >> /var/log/pki/pki-tomcat/localhost.2015-12-11.log >> SEVERE: Servlet.service() for servlet [caGetStatus] in context with >> path [/ca] >> threw exception java.io.IOException: CS server is not ready to serve. >> >> >> /var/log/dirsrv/slapd-PLANWEE-LOCAL/errors >> [11/Dec/2015:01:02:19 +0200] - slapd started. Listening on All >> Interfaces port >> 389 for LDAP requests >> [11/Dec/2015:01:02:19 +0200] - Listening on All Interfaces port 636 for >> LDAPS requests >> [11/Dec/2015:01:02:19 +0200] - Listening on >> /var/run/slapd-PLANWEE-LOCAL.socket >> for LDAPI requests >> [11/Dec/2015:01:02:19 +0200] slapd_ldap_sasl_interactive_bind - Error: >> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error >> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint >> is not >> connected) >> [11/Dec/2015:01:02:19 +0200] slapi_ldap_bind - Error: could not perform >> interactive bind for id [] authentication mechanism [GSSAPI]: error -1 >> (Can't contact LDAP server) >> >> /var/log/pki/pki-tomcat/ca/debug >> Internal Database Error encountered: Could not connect to LDAP server >> host ipa1.backend.planwee.local port 636 Error >> netscape.ldap.LDAPException: IO >> Error creating JSS SSL Socket (-1) >> >> Environment: >> CentOS 7 >> IPA 4.1 >> >> The problem looks the same as this: >> https://access.redhat.com/solutions/2022123 >> >> Unfortunately I cannot view resolution. >> >> is this related to expired CA certificates? > > If you have expired certificates (you can check with "# getcert list | > grep expires"), it could cause issues like that also. > > The article you are referring to is rather around wrong CA certificate > trust attributes in /var/lib/pki/pki-tomcat/alias/ or > /etc/dirsrv/slapd-EXAMPLE-COM/ NSS databases. > > You can check that with > # certutil -L -d /var/lib/pki/pki-tomcat/alias/ > # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM/ > > BTW, if you want to see the whole article or other articles from the > large KB, I would suggest getting a subscription :-) -- -- Jani West -- jwest at iki.fi -- +358 40 5010914 -- -- Liinalahdentie 4 -- 01800 KLAUKKALA -- FINLAND -- "Haluaisin, ett? Suomi olisi paljon monikulttuurisempi. T?nne tulee muualta paljon ihmisi?, mutta heit? ei tuoda tarpeeksi esille. Jotenkin me pid?mme heid?t verhojen takana. On t?rke??, ett? Suomesta saataisiin avoin ja suvaitsevainen. Sulkeutunut ajattelutapa on Suomen ongelma. Ehk? me pelk??mme mielenosoituksia, joita esimerkiksi Ruotsin l?hi?iss? on ollut ja sit?, ett? jotain kauheaa tapahtuu. Ei ymm?rret?, ett? maahanmuuttajat voivat tuoda Suomeen my?s paljon hyv??. Toivoisin hallitukselta sit?, ett? koko kansaa kuullaan, my?s eri kulttuureista tulevia. Hallituksen pit?isi rahoittaa ja tukea enemm?n Suomen kansainv?list?mist?. My?s eduskunta voisi kuunnella maahanmuuttajia enemm?n." HS 8.6.2013: Essi, 16 v. Etu-T??l?n lukio. From cal-s at blue-bolt.com Fri Dec 11 13:25:05 2015 From: cal-s at blue-bolt.com (Cal Sawyer) Date: Fri, 11 Dec 2015 13:25:05 +0000 Subject: [Freeipa-users] IPA, autofs, kerberos Message-ID: <566ACEB1.5090009@blue-bolt.com> Hi After getting autofs working using automountmaps in IPA, i've discovered that upon rebooting a client i have no automounts. If i ssh into the client and obtain a ticket as admin, after restarting autofs (as root), I can once again see access automounted directories. Until then, user logins which depend on network home mount consistently fail Question is, how can this be made automatic on reboot? thanks - cal sawyer From cal-s at blue-bolt.com Fri Dec 11 14:31:13 2015 From: cal-s at blue-bolt.com (Cal Sawyer) Date: Fri, 11 Dec 2015 14:31:13 +0000 Subject: [Freeipa-users] IPA, autofs, kerberos In-Reply-To: <566ACEB1.5090009@blue-bolt.com> References: <566ACEB1.5090009@blue-bolt.com> Message-ID: <566ADE31.9050006@blue-bolt.com> Hi Let me update that last post. After setting authrequired=no in /etc/autofs_ldap_auth.conf, automount comes right up on reboot However, given CentOS6 clients using ipa-client-3.0.0-47.el6 and IPA server 4.1.0, what is the highest /secure/ level i can achieve without manually intervening? autofs_ldap_auth.conf is currently - cal sawyer On 11/12/15 13:25, Cal Sawyer wrote: > Hi > > After getting autofs working using automountmaps in IPA, i've > discovered that upon rebooting a client i have no automounts. If i > ssh into the client and obtain a ticket as admin, after restarting > autofs (as root), I can once again see access automounted > directories. Until then, user logins which depend on network home > mount consistently fail > > Question is, how can this be made automatic on reboot? > > thanks > > - cal sawyer -------------- next part -------------- An HTML attachment was scrubbed... URL: From APtashnik at cccis.com Fri Dec 11 16:18:08 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Fri, 11 Dec 2015 16:18:08 +0000 Subject: [Freeipa-users] Clean up DNS, Host, Cert and other records from IPA / IDM Message-ID: <4924A345-FCFE-4973-B49E-47034BE69358@cccis.com> Hello Team, We have many servers in our environment that are on a different stage of their lifecycle. All of them are added to IPA domain. There are cases when servers gets moved, sometimes crash, sometimes are being rebuild or decommissioned. In those cases we need to completely remove server identity from IPA including DNS, Host, Certificate and other associated records. What is the most proper way to completely remove client records in case if server needs to be rebuilt with the same host name down the road? (hardware failure happened, server crashed and needs to be rebuild ? is a perfect example). Regards, Andrey Ptashnik -------------- next part -------------- An HTML attachment was scrubbed... URL: From stacy.redmond at blueshieldca.com Fri Dec 11 16:55:11 2015 From: stacy.redmond at blueshieldca.com (Redmond, Stacy) Date: Fri, 11 Dec 2015 16:55:11 +0000 Subject: [Freeipa-users] Service Accounts via IPA In-Reply-To: <566A815F.4070103@mmfg.it> References: <5434D6A65FEF2B428D5CC8D77FA7DA713B6D7325@wexc201p.bsc.bscal.com> <566A815F.4070103@mmfg.it> Message-ID: <5434D6A65FEF2B428D5CC8D77FA7DA713B6D91DF@wexc201p.bsc.bscal.com> No, that does not even allow su ? unless you add the ?s /bin/bash or some valid shell. I did try a few of these, generally I just put a ! I front of the password locally, but since these exist in ldap now instead, not sure that is an option. From: Nicola Canepa [mailto:canepa.n at mmfg.it] Sent: Thursday, December 10, 2015 11:55 PM To: Redmond, Stacy; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Service Accounts via IPA ** BSCA security warning: Do not click links or trust the content unless you expected this email and trust the sender ? This email originated outside of Blue Shield. ** Maybe you can use /usr/sbin/nologin as the shell? Nicola Il 10/12/15 19:24, Redmond, Stacy ha scritto: Generally I will lock a service account on linux so that the account cannot login, but users can sudo su ? to that user. As I don?t have access to the password field in free ipa, what are my options to set this up as a default for service accounts, or how can I modify individual accounts that need access to a system, but should not be able to login to the system. Any help is appreciated. -- Nicola Canepa Tel: +39-0522-399-3474 canepa.n at mmfg.it --- Il contenuto della presente comunicazione ? riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avr? valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, n? rinuncia o riconoscimento di diritti, debiti e/o crediti, n? sar? impegnativa, qualora non sia sottoscritto successivo accordo da chi pu? validamente obbligarci. Non deriver? alcuna responsabilit? precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti. The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Fri Dec 11 17:31:22 2015 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 11 Dec 2015 10:31:22 -0700 Subject: [Freeipa-users] RHEL 7.2 update - ns-slapd replication keep alive entry In-Reply-To: References: Message-ID: <566B086A.1090607@cora.nwra.com> On 12/02/2015 01:42 PM, Andy Thompson wrote: > Since updating to RHEL 7.2 I've got issues with ns-slapd hanging the system up after a period of time. The directory becomes unresponsive to searches or any connections. After a restart I see > > [02/Dec/2015:15:27:41 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests > [02/Dec/2015:15:27:41 -0500] - Listening on All Interfaces port 636 for LDAPS requests > [02/Dec/2015:15:27:41 -0500] - Listening on /var/run/slapd-MHBENP-LIN.socket for LDAPI requests > [02/Dec/2015:15:27:44 -0500] NSMMReplicationPlugin - agmt="cn=meTomdhixnpipa02.mhbenp.lin" (mdhixnpipa02:389): Replication bind with GSSAPI auth resumed > [02/Dec/2015:15:27:47 -0500] NSMMReplicationPlugin - replication keep alive entry already exists > > In the logs and occasionally the keepalive entry message is seen a few times and then eventually the ns-slapd taps the system. 100% util, system load crawls up between 30 and 40 and eventually I have to restart the service to get it to respond again. Memory usage is normal, db and entry cache is sufficient.. possibly a little on the high side but resource is sitting there asking to be used :) > > Running 389-ds-base-1.3.4.0-19.el7.x86_64 after the update yesterday. I've not (yet) noticed any hangs in ns-slapd, although our system is not yet really in production. However I am seeing many of these "replication keep alive entry" messages as well with the new version. Can anyone speak to what is causing these? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From marc.boorshtein at tremolosecurity.com Fri Dec 11 17:49:01 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Fri, 11 Dec 2015 12:49:01 -0500 Subject: [Freeipa-users] Service Accounts via IPA In-Reply-To: <5434D6A65FEF2B428D5CC8D77FA7DA713B6D91DF@wexc201p.bsc.bscal.com> References: <5434D6A65FEF2B428D5CC8D77FA7DA713B6D7325@wexc201p.bsc.bscal.com> <566A815F.4070103@mmfg.it> <5434D6A65FEF2B428D5CC8D77FA7DA713B6D91DF@wexc201p.bsc.bscal.com> Message-ID: I do the same thing on most deployments. I usually just assign a large random password to the service account. Marc Boorshtein CTO, Tremolo Security, Inc. On Dec 11, 2015 12:15 PM, "Redmond, Stacy" wrote: > No, that does not even allow su ? unless you add the ?s /bin/bash or some > valid shell. I did try a few of these, generally I just put a ! I front of > the password locally, but since these exist in ldap now instead, not sure > that is an option. > > > > *From:* Nicola Canepa [mailto:canepa.n at mmfg.it] > *Sent:* Thursday, December 10, 2015 11:55 PM > *To:* Redmond, Stacy; freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Service Accounts via IPA > > > > ** BSCA security warning: Do not click links or trust the content unless > you expected this email and trust the sender ? This email originated > outside of Blue Shield. ** > > Maybe you can use /usr/sbin/nologin as the shell? > > Nicola > > Il 10/12/15 19:24, Redmond, Stacy ha scritto: > > Generally I will lock a service account on linux so that the account > cannot login, but users can sudo su ? to that user. As I don?t have access > to the password field in free ipa, what are my options to set this up as a > default for service accounts, or how can I modify individual accounts that > need access to a system, but should not be able to login to the system. > Any help is appreciated. > > > > > > -- > > > > Nicola Canepa > > Tel: +39-0522-399-3474 > > canepa.n at mmfg.it > > --- > > Il contenuto della presente comunicazione ? riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avr? valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, n? rinuncia o riconoscimento di diritti, debiti e/o crediti, n? sar? impegnativa, qualora non sia sottoscritto successivo accordo da chi pu? validamente obbligarci. Non deriver? alcuna responsabilit? precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti. > > > > The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties. > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stacy.redmond at blueshieldca.com Fri Dec 11 18:01:44 2015 From: stacy.redmond at blueshieldca.com (Redmond, Stacy) Date: Fri, 11 Dec 2015 18:01:44 +0000 Subject: [Freeipa-users] Service Accounts via IPA In-Reply-To: References: <5434D6A65FEF2B428D5CC8D77FA7DA713B6D7325@wexc201p.bsc.bscal.com> <566A815F.4070103@mmfg.it> <5434D6A65FEF2B428D5CC8D77FA7DA713B6D91DF@wexc201p.bsc.bscal.com> Message-ID: <5434D6A65FEF2B428D5CC8D77FA7DA713B6D92A9@wexc201p.bsc.bscal.com> That is probably what I will end up doing, thanks for all the input so far. From: Marc Boorshtein [mailto:marc.boorshtein at tremolosecurity.com] Sent: Friday, December 11, 2015 9:49 AM To: Redmond, Stacy Cc: freeipa-users; Nicola Canepa Subject: Re: [Freeipa-users] Service Accounts via IPA ** BSCA security warning: Do not click links or trust the content unless you expected this email and trust the sender ? This email originated outside of Blue Shield. ** I do the same thing on most deployments. I usually just assign a large random password to the service account. Marc Boorshtein CTO, Tremolo Security, Inc. On Dec 11, 2015 12:15 PM, "Redmond, Stacy" > wrote: No, that does not even allow su ? unless you add the ?s /bin/bash or some valid shell. I did try a few of these, generally I just put a ! I front of the password locally, but since these exist in ldap now instead, not sure that is an option. From: Nicola Canepa [mailto:canepa.n at mmfg.it] Sent: Thursday, December 10, 2015 11:55 PM To: Redmond, Stacy; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Service Accounts via IPA ** BSCA security warning: Do not click links or trust the content unless you expected this email and trust the sender ? This email originated outside of Blue Shield. ** Maybe you can use /usr/sbin/nologin as the shell? Nicola Il 10/12/15 19:24, Redmond, Stacy ha scritto: Generally I will lock a service account on linux so that the account cannot login, but users can sudo su ? to that user. As I don?t have access to the password field in free ipa, what are my options to set this up as a default for service accounts, or how can I modify individual accounts that need access to a system, but should not be able to login to the system. Any help is appreciated. -- Nicola Canepa Tel: +39-0522-399-3474 canepa.n at mmfg.it --- Il contenuto della presente comunicazione ? riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avr? valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, n? rinuncia o riconoscimento di diritti, debiti e/o crediti, n? sar? impegnativa, qualora non sia sottoscritto successivo accordo da chi pu? validamente obbligarci. Non deriver? alcuna responsabilit? precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti. The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties. -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwest at iki.fi Fri Dec 11 19:54:47 2015 From: jwest at iki.fi (Jani West) Date: Fri, 11 Dec 2015 21:54:47 +0200 Subject: [Freeipa-users] Yum update broke CA/CS - pki-tomcatd not starting In-Reply-To: <566A87F8.9030303@redhat.com> References: <566A7BE3.9000500@iki.fi> <566A87F8.9030303@redhat.com> Message-ID: <566B2A07.9030200@iki.fi> Hello, Seems like I indeed have expired certs. The problem is, how I can renew these. I tried to do: --------------- root at ipa1 ca]# systemctl restart dirsrv.target [root at ipa1 ca]# ipa-cacert-manage renew Renewing CA certificate, please wait Error resubmitting certmonger request '20150814121620', please check the request manually --------------- I still have old certs: Request ID '20150814121606': status: CA_WORKING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='654666959930' certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=PLANWEE.LOCAL subject: CN=CA Audit,O=PLANWEE.LOCAL expires: 2015-09-29 20:22:26 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20150814121614': status: CA_WORKING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin='654666959930' certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=PLANWEE.LOCAL subject: CN=OCSP Subsystem,O=PLANWEE.LOCAL expires: 2015-09-29 20:22:25 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign eku: id-kp-OCSPSigning pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20150814121618': status: CA_WORKING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='654666959930' certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=PLANWEE.LOCAL subject: CN=CA Subsystem,O=PLANWEE.LOCAL expires: 2015-09-29 20:22:25 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20150814121621': status: CA_WORKING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=PLANWEE.LOCAL subject: CN=IPA RA,O=PLANWEE.LOCAL expires: 2015-09-29 20:23:10 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes On 12/11/2015 10:23 AM, Martin Kosek wrote: > On 12/11/2015 08:31 AM, Jani West wrote: >> Hello, >> >> Pki-tomcatd seems to have difficulties when connecting to CA. LDAP >> server is starting ok when starting it directly with "systemctl start >> dirsrv.target". >> >> When starting "systemctl start ipa" everything else will startup exept >> the >> pki-tomcatd. >> >> Obviously same thing happens when starting with ipactl directly: >> [root at ipa1 ca]# ipactl start >> Existing service file detected! >> Assuming stale, cleaning and proceeding >> Starting Directory Service >> Starting krb5kdc Service >> Starting kadmin Service >> Starting named Service >> Starting ipa_memcached Service >> Starting httpd Service >> Starting pki-tomcatd Service >> Failed to start pki-tomcatd Service >> Shutting down >> Aborting ipactl >> >> >> /var/log/pki/pki-tomcat/localhost.2015-12-11.log >> SEVERE: Servlet.service() for servlet [caGetStatus] in context with >> path [/ca] >> threw exception java.io.IOException: CS server is not ready to serve. >> >> >> /var/log/dirsrv/slapd-PLANWEE-LOCAL/errors >> [11/Dec/2015:01:02:19 +0200] - slapd started. Listening on All >> Interfaces port >> 389 for LDAP requests >> [11/Dec/2015:01:02:19 +0200] - Listening on All Interfaces port 636 for >> LDAPS requests >> [11/Dec/2015:01:02:19 +0200] - Listening on >> /var/run/slapd-PLANWEE-LOCAL.socket >> for LDAPI requests >> [11/Dec/2015:01:02:19 +0200] slapd_ldap_sasl_interactive_bind - Error: >> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error >> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint >> is not >> connected) >> [11/Dec/2015:01:02:19 +0200] slapi_ldap_bind - Error: could not perform >> interactive bind for id [] authentication mechanism [GSSAPI]: error -1 >> (Can't contact LDAP server) >> >> /var/log/pki/pki-tomcat/ca/debug >> Internal Database Error encountered: Could not connect to LDAP server >> host ipa1.backend.planwee.local port 636 Error >> netscape.ldap.LDAPException: IO >> Error creating JSS SSL Socket (-1) >> >> Environment: >> CentOS 7 >> IPA 4.1 >> >> The problem looks the same as this: >> https://access.redhat.com/solutions/2022123 >> >> Unfortunately I cannot view resolution. >> >> is this related to expired CA certificates? > > If you have expired certificates (you can check with "# getcert list | > grep expires"), it could cause issues like that also. > > The article you are referring to is rather around wrong CA certificate > trust attributes in /var/lib/pki/pki-tomcat/alias/ or > /etc/dirsrv/slapd-EXAMPLE-COM/ NSS databases. > > You can check that with > # certutil -L -d /var/lib/pki/pki-tomcat/alias/ > # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM/ > > BTW, if you want to see the whole article or other articles from the > large KB, I would suggest getting a subscription :-) -- -- Jani West -- jwest at iki.fi -- From m3freak at thesandhufamily.ca Fri Dec 11 20:29:19 2015 From: m3freak at thesandhufamily.ca (Ranbir) Date: Fri, 11 Dec 2015 15:29:19 -0500 Subject: [Freeipa-users] Any recent guides for Postfix and IPA integration? Message-ID: <1449865759.18285.9.camel@thesandhufamily.ca> Hi All, I want to integrate my Postfix server with IPA. I've found a couple of documents on how this can be done, but they don't accomplish the feat the same way (they're also not discussing the exact same end goal). I'm left wondering how exactly to integrate IPA and Postfix. For reference: https://www.dalemacartney.com/2013/03/14/deploying -postfix-with-ldap-freeipa-virtual-aliases-and-kerberos-authentication/ http://www.freeipa.org/page/%28DRAFT%29_HA_mail_services_with_FreeIPA,_ postfix,_dovecot,_amavisd-new,_clamd_and_PLAIN/GSSAPI_SSO Is there anything more recent out there or are the above two docs still good enough/applicable to IPA and postfix servers running on CentOS 7? Thanks in advance. -- Ranbir -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From natxo.asenjo at gmail.com Fri Dec 11 21:13:40 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 11 Dec 2015 22:13:40 +0100 Subject: [Freeipa-users] Any recent guides for Postfix and IPA integration? In-Reply-To: <1449865759.18285.9.camel@thesandhufamily.ca> References: <1449865759.18285.9.camel@thesandhufamily.ca> Message-ID: hi Ranbir, On Fri, Dec 11, 2015 at 9:29 PM, Ranbir wrote: > Hi All, > > I want to integrate my Postfix server with IPA. I've found a couple of > documents on how this can be done, but they don't accomplish the feat > the same way (they're also not discussing the exact same end goal). I'm > left wondering how exactly to integrate IPA and Postfix. > > what exactly do you want to achieve? 'Integrate' could mean a couple of things, so please specify. -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrorourke at earthlink.net Fri Dec 11 21:24:42 2015 From: mrorourke at earthlink.net (Michael ORourke) Date: Fri, 11 Dec 2015 16:24:42 -0500 (EST) Subject: [Freeipa-users] Service Accounts via IPA Message-ID: <16674551.1449869083384.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> An HTML attachment was scrubbed... URL: From m3freak at thesandhufamily.ca Fri Dec 11 22:32:40 2015 From: m3freak at thesandhufamily.ca (Ranbir) Date: Fri, 11 Dec 2015 17:32:40 -0500 Subject: [Freeipa-users] Any recent guides for Postfix and IPA integration? In-Reply-To: References: <1449865759.18285.9.camel@thesandhufamily.ca> Message-ID: <1449873160.18285.23.camel@thesandhufamily.ca> On Fri, 2015-12-11 at 22:13 +0100, Natxo Asenjo wrote: > what exactly do you want to achieve? 'Integrate' could mean a couple > of things, so please specify. Ya, that was lame. Let me elaborate. I have a postfix server and a dovecot server: both are running in separate KVMs. They're on different subnets and they have a firewall in between. I've opened up ports to allow them to talk to each other because the postfix server is using dovecot for smtp auth and lmtp for mail delivery. The dovecot users are in a password file. At the moment, my mail setup is working perfectly. I have a master IPA server on the same network as the dovecot box. There's a replica IPA server on the postfix server's network. Both servers are joined to the IPA domain although they are in different DNS domains (which doesn't really matter here, I guess). I would like to move postfix and dovecot to use IPA for sasl auth and for managing the virtual mailboxes. I have a good idea of how this is all supposed to work together. What I need are the actual steps to get it done. -- Ranbir -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From APtashnik at cccis.com Fri Dec 11 22:55:37 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Fri, 11 Dec 2015 22:55:37 +0000 Subject: [Freeipa-users] Clean up DNS Host Cert and other records from IPA Message-ID: <703AD3A5-F146-46A1-AA11-3FA3D4D851DD@cccis.com> Hello Team, We have many servers in our environment that are on a different stage of their lifecycle. All of them are added to IPA domain. There are cases when servers gets moved, sometimes crash, sometimes are being rebuild or decommissioned. In those cases we need to completely remove server identity from IPA including DNS, Host, Certificate and other associated records. What is the most proper way to completely remove client records in case if server needs to be rebuilt with the same host name down the road? (hardware failure happened, server crashed and needs to be rebuild ? is a perfect example). Regards, Andrey Ptashnik -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at stefany.eu Fri Dec 11 23:26:12 2015 From: martin at stefany.eu (Martin =?UTF-8?Q?=C5=A0tefany?=) Date: Sat, 12 Dec 2015 00:26:12 +0100 Subject: [Freeipa-users] Any recent guides for Postfix and IPA integration? In-Reply-To: References: <1449865759.18285.9.camel@thesandhufamily.ca> Message-ID: <1449876372.5344.29.camel@stefany.eu> Hello Ranbir, I'm working on this, even today I was putting more things together. (That DRAFT is really uncommented version of what I currently have). And I've opened also?https://fedorahosted.org/freeipa/ticket/5521?to get a bit more out of it. To sum it up what I've put together: - Postfix for SMTP MTA - Dovecot for IMAP (no POP3) - Amavisd-new with ClamAV and SpamAssassin for Antispam / Antivirus / additional header checks, etc. - SPF, DKIM, DMARC support for both sending and receiving mail - setup is HA thanks to DNS records, and 2 separate systems running almost identical configuration and Dovecot replicates mailboxes using dsync - PLAIN / LOGIN / GSSAPI authentication for SSO login thanks to FreeIPA (integration with Evolution on Fedora/RHEL/CentOS desktop joined to FreeIPA domain works also great) - users, of course, stored in FreeIPA, usage granted only to ones with correct e-mail field, group membership (and enablement of the ID) - but some pieces are still missing: ? - I'm still reviewing e.g. correct postfix restrictions and documenting the full setup ? - there's missing support for GUI configuration domain aliases, user aliases, sender/receiver Bcc support, quota setup, etc. even if something is managable via ipa-admintools and LDAP attributes I would like to finish it asap, within a week or two, cause I run this e-mail system at home (as somebody already mentioned, why not?) and I don't like it unfinished. ;) But to give you a good place to start: have a look to iRedMail project,? http://www.iredmail.org/,?ZhangHuangbin's product is great and it helped me a lot to prepare what I described above. There's no support for 'old- style' HA, but you can still run it 'HA' on VM with all the benefits, and there's not direct support for FreeIPA integration, but guideline for ActiveDirectory integration exists, so you can start there:?http://w ww.iredmail.org/docs/active.directory.html. As Natxo mentioned, it all depends what kind of integration you want and what do you expect from mail setup. ;) Martin On Pi, 2015-12-11 at 22:13 +0100, Natxo Asenjo wrote: > hi Ranbir, > > > On Fri, Dec 11, 2015 at 9:29 PM, Ranbir > wrote: > > Hi All, > > > > I want to integrate my Postfix server with IPA. I've found a couple > > of > > documents on how this can be done, but they don't accomplish the > > feat > > the same way (they're also not discussing the exact same end goal). > > I'm > > left wondering how exactly to integrate IPA and Postfix. > > > what exactly do you want to achieve? 'Integrate' could mean a couple > of things, so please specify. > > -- > Groeten, > natxo > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From stefano.cortese at ego-gw.it Sat Dec 12 12:34:53 2015 From: stefano.cortese at ego-gw.it (Stefano Cortese) Date: Sat, 12 Dec 2015 13:34:53 +0100 Subject: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7 In-Reply-To: <20151208164028.GH16629@p.redhat.com> References: <5665BC1E.3@ego-gw.it> <20151207172522.GF16629@p.redhat.com> <5666DC34.1020600@ego-gw.it> <20151208164028.GH16629@p.redhat.com> Message-ID: <566C146D.1050202@ego-gw.it> An HTML attachment was scrubbed... URL: From sbose at redhat.com Sat Dec 12 15:01:08 2015 From: sbose at redhat.com (Sumit Bose) Date: Sat, 12 Dec 2015 16:01:08 +0100 Subject: [Freeipa-users] .k5login and auth_to_local_names principal -> account mapping and localauth plugin not working on 6.7 In-Reply-To: <566C146D.1050202@ego-gw.it> References: <5665BC1E.3@ego-gw.it> <20151207172522.GF16629@p.redhat.com> <5666DC34.1020600@ego-gw.it> <20151208164028.GH16629@p.redhat.com> <566C146D.1050202@ego-gw.it> Message-ID: <20151212150108.GA19972@p.redhat.com> On Sat, Dec 12, 2015 at 01:34:53PM +0100, Stefano Cortese wrote: > > 

> This is expected because if either the principal or the user name is
> known to SSSD the localauth plugin will take control because by default
> the added modules are registered first (see [plugins] section of man
> krb5.conf for details).
> 
> To check auth_to_local_names first you can try
> 
>    enable_only=names,k5login,sssd
> 
>
> > It does not work for me.
> Changed the snippet and made immutable, after sssd restart the > behaviour is the same.
> It does not work also putting k5login or names alone.
> Note that the sssd version in SL6.7<->RHEL6.7  is  1.12.4-47
> Should those keywords work in this version ?
ah, this is not related to the SSSD version, but to the version of MIT Kerberos. SL/CentOS/RHEL 6.7 should have version 1.10.3 which already has the new plugin interface but the localauth plugin was only released in MIT Kerberos version 1.12. bye, Sumit From arthur at deus.pro Sun Dec 13 07:42:08 2015 From: arthur at deus.pro (Arthur Fayzullin) Date: Sun, 13 Dec 2015 12:42:08 +0500 Subject: [Freeipa-users] FreeRadius and FreeIPA In-Reply-To: <56684014.9060001@chem.byu.edu> References: <56684014.9060001@chem.byu.edu> Message-ID: <566D2150.7080801@deus.pro> I think these are the good points to start: https://www.eduroam.us/node/90 http://wiki.freeradius.org/modules/Rlm_krb5 I You'll be succeeded how-to will be awesome ;-) 09.12.2015 19:52, Randy Morgan ?????: > Hello, > > We are setting up our wireless to authenticate against FreeRadius and > FreeIPA. I am looking for any instructions on how to integrate radius > with IPA. We can get them talking via kerberos, but when we have a > wireless client attempt to authenticate against them, the password > gets stripped out and only the username gets passed on, resulting in a > failed logon attempt. > > As we have studied the problem we have identified the communication > protocols used by wireless to pass on the user credentials to radius. > Wireless uses EAP as it's primary protocol. We are running Xirrus > wireless APs and from what we can learn, they act only as a pass > through conduit for the client. Ideally we would like them to speak > PEAP TTLS, this would allow kerberos to process from the client to the > IPA server, we are still researching this. > > Are there any instructions on how to integrate FreeRadius 3.0.10 with > FreeIPA 3.3.5? Any help would be appreciated. > > Randy > From natxo.asenjo at gmail.com Sun Dec 13 20:56:17 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Sun, 13 Dec 2015 21:56:17 +0100 Subject: [Freeipa-users] Any recent guides for Postfix and IPA integration? In-Reply-To: <1449873160.18285.23.camel@thesandhufamily.ca> References: <1449865759.18285.9.camel@thesandhufamily.ca> <1449873160.18285.23.camel@thesandhufamily.ca> Message-ID: On Fri, Dec 11, 2015 at 11:32 PM, Ranbir wrote: > On Fri, 2015-12-11 at 22:13 +0100, Natxo Asenjo wrote: > > what exactly do you want to achieve? 'Integrate' could mean a couple > > of things, so please specify. > .... > I would like to move postfix and dovecot to use IPA for sasl auth and > for managing the virtual mailboxes. I have a good idea of how this is > all supposed to work together. What I need are the actual steps to get > it done. > so what have you tried? -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Mon Dec 14 06:45:54 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 14 Dec 2015 16:45:54 +1000 Subject: [Freeipa-users] Certificate Profile - Policy Set Not Found In-Reply-To: <2CA71D6C07ADB544847562573DC6BF061857B18D@CPEMS-KPN309.KPNCNL.LOCAL> References: <2CA71D6C07ADB544847562573DC6BF061857806C@CPEMS-KPN309.KPNCNL.LOCAL> <20151209234835.GR23644@dhcp-40-8.bne.redhat.com> <20151210025805.GS23644@dhcp-40-8.bne.redhat.com> <2CA71D6C07ADB544847562573DC6BF0618579F38@CPEMS-KPN309.KPNCNL.LOCAL> <20151211071348.GZ23644@dhcp-40-8.bne.redhat.com> <2CA71D6C07ADB544847562573DC6BF061857B18D@CPEMS-KPN309.KPNCNL.LOCAL> Message-ID: <20151214064554.GE23644@dhcp-40-8.bne.redhat.com> Thanks for these details Wouter. Logging at your CS.cfg, there is something wrong - the line: subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem should be: subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem What is the history of this IPA server? Was it a fresh ipa-server-install on RHEL 7.2; an upgrade from an earlier version of RHEL; or an ipa-replica-install from an IPA server of an earlier release? Could you check the following logfiles (whichever are present) for errors? /var/log/ipareplica-install.log /var/log/ipaserver-install.log /var/log/ipaupgrade.log Anyhow, I suggest switching to LDAPProfileSubsystem in CS.cfg, restarting PKI and then seeing if the problem still occurs. Cheers, Fraser On Fri, Dec 11, 2015 at 09:04:26AM +0000, wouter.hummelink at kpn.com wrote: > ipa-admintools.x86_64 4.2.0-15.el7 @rhel-x86_64-server-7 > ipa-client.x86_64 4.2.0-15.el7 @rhel-x86_64-server-7 > ipa-python.x86_64 4.2.0-15.el7 @rhel-x86_64-server-7 > ipa-server.x86_64 4.2.0-15.el7 @rhel-x86_64-server-7 > ipa-server-dns.x86_64 4.2.0-15.el7 @rhel-x86_64-server-7 > ipa-server-trust-ad.x86_64 4.2.0-15.el7 @rhel-x86_64-server-7 > > pki-base.noarch 10.2.5-6.el7 @rhel-x86_64-server-7 > pki-ca.noarch 10.2.5-6.el7 @rhel-x86_64-server-7 > pki-kra.noarch 10.2.5-6.el7 @rhel-x86_64-server-7 > pki-server.noarch 10.2.5-6.el7 @rhel-x86_64-server-7 > pki-symkey.x86_64 10.2.5-6.el7 @rhel-x86_64-server-7 > pki-tools.x86_64 10.2.5-6.el7 @rhel-x86_64-server-7 > > CrossCertPair._000=## > CrossCertPair._001=## CrossCertPair Import > CrossCertPair._002=## > CrossCertPair.ldap=internaldb > _000=## > _001=## Certificate Authority (CA) Configuration File > _002=## > accessEvaluator.impl.group.class=com.netscape.cms.evaluators.GroupAccessEvaluator > accessEvaluator.impl.ipaddress.class=com.netscape.cms.evaluators.IPAddressAccessEvaluator > accessEvaluator.impl.user.class=com.netscape.cms.evaluators.UserAccessEvaluator > accessEvaluator.impl.user_origreq.class=com.netscape.cms.evaluators.UserOrigReqAccessEvaluator > admin.interface.uri=ca/admin/console/config/wizard > agent.interface.uri=ca/agent/ca > authType=pwd > auths._000=## > auths._001=## new authentication > auths._002=## > auths.impl.AgentCertAuth.class=com.netscape.cms.authentication.AgentCertAuthentication > auths.impl.CMCAuth.class=com.netscape.cms.authentication.CMCAuth > auths.impl.FlatFileAuth.class=com.netscape.cms.authentication.FlatFileAuth > auths.impl.NISAuth.class=com.netscape.cms.authentication.NISAuth > auths.impl.PortalEnroll.class=com.netscape.cms.authentication.PortalEnroll > auths.impl.SSLclientCertAuth.class=com.netscape.cms.authentication.SSLclientCertAuthentication > auths.impl.TokenAuth.class=com.netscape.cms.authentication.TokenAuthentication > auths.impl.UdnPwdDirAuth.class=com.netscape.cms.authentication.UdnPwdDirAuthentication > auths.impl.UidPwdDirAuth.class=com.netscape.cms.authentication.UidPwdDirAuthentication > auths.impl.UidPwdGroupDirAuth.class=com.netscape.cms.authentication.UidPwdGroupDirAuthentication > auths.impl.UidPwdPinDirAuth.class=com.netscape.cms.authentication.UidPwdPinDirAuthentication > auths.impl._000=## > auths.impl._001=## authentication manager implementations > auths.impl._002=## > auths.instance.AgentCertAuth.agentGroup=Certificate Manager Agents > auths.instance.AgentCertAuth.pluginName=AgentCertAuth > auths.instance.SSLclientCertAuth.pluginName=SSLclientCertAuth > auths.instance.TokenAuth.pluginName=TokenAuth > auths.instance.flatFileAuth.authAttributes=PWD > auths.instance.flatFileAuth.deferOnFailure=true > auths.instance.flatFileAuth.fileName=/var/lib/pki/pki-tomcat/conf/ca/flatfile.txt > auths.instance.flatFileAuth.keyAttributes=UID > auths.instance.flatFileAuth.pluginName=FlatFileAuth > auths.instance.raCertAuth.agentGroup=Registration Manager Agents > auths.instance.raCertAuth.pluginName=AgentCertAuth > auths.revocationChecking.bufferSize=50 > auths.revocationChecking.ca=ca > auths.revocationChecking.enabled=true > auths.revocationChecking.unknownStateInterval=0 > auths.revocationChecking.validityInterval=120 > authz._000=## > authz._001=## new authorizatioin > authz._002=## > authz.evaluateOrder=deny,allow > authz.impl.BasicAclAuthz.class=com.netscape.cms.authorization.BasicAclAuthz > authz.impl.DirAclAuthz.class=com.netscape.cms.authorization.DirAclAuthz > authz.impl._000=## > authz.impl._001=## authorization manager implementations > authz.impl._002=## > authz.instance.BasicAclAuthz.pluginName=BasicAclAuthz > authz.instance.DirAclAuthz.ldap=internaldb > authz.instance.DirAclAuthz.ldap._000=## > authz.instance.DirAclAuthz.ldap._001=## Internal Database > authz.instance.DirAclAuthz.ldap._002=## > authz.instance.DirAclAuthz.ldap.ldapauth.authtype=SslClientAuth > authz.instance.DirAclAuthz.ldap.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipa-ca > authz.instance.DirAclAuthz.ldap.ldapauth.clientCertNickname=subsystemCert cert-pki-ca > authz.instance.DirAclAuthz.ldap.ldapconn.port=636 > authz.instance.DirAclAuthz.ldap.ldapconn.secureConn=true > authz.instance.DirAclAuthz.pluginName=DirAclAuthz > authz.sourceType=ldap > ca.Policy._000=## > ca.Policy._001=## Certificate Policy Framework (deprecated) > ca.Policy._002=## > ca.Policy._003=## Set 'ca.Policy.enable=true' to allow the following: > ca.Policy._004=## > ca.Policy._005=## SERVLET-NAME URL-PATTERN > ca.Policy._006=## ==================================================== > ca.Policy._007=## caadminEnroll ca/admin/ca/adminEnroll.html > ca.Policy._008=## cabulkissuance ca/agent/ca/bulkissuance.html > ca.Policy._009=## cacertbasedenrollment ca/certbasedenrollment.html > ca.Policy._010=## caenrollment ca/enrollment.html > ca.Policy._011=## capolicy ca/capolicy > ca.Policy._012=## > ca.Policy.enable=false > ca.Policy.impl.AttributePresentConstraints.class=com.netscape.cms.policy.constraints.AttributePresentConstraints > ca.Policy.impl.AuthInfoAccessExt.class=com.netscape.cms.policy.extensions.AuthInfoAccessExt > ca.Policy.impl.AuthorityKeyIdentifierExt.class=com.netscape.cms.policy.extensions.AuthorityKeyIdentifierExt > ca.Policy.impl.BasicConstraintsExt.class=com.netscape.cms.policy.extensions.BasicConstraintsExt > ca.Policy.impl.CRLDistributionPointsExt.class=com.netscape.cms.policy.extensions.CRLDistributionPointsExt > ca.Policy.impl.CertificatePoliciesExt.class=com.netscape.cms.policy.extensions.CertificatePoliciesExt > ca.Policy.impl.CertificateRenewalWindowExt.class=com.netscape.cms.policy.extensions.CertificateRenewalWindowExt > ca.Policy.impl.CertificateScopeOfUseExt.class=com.netscape.cms.policy.extensions.CertificateScopeOfUseExt > ca.Policy.impl.DSAKeyConstraints.class=com.netscape.cms.policy.constraints.DSAKeyConstraints > ca.Policy.impl.ExtendedKeyUsageExt.class=com.netscape.cms.policy.extensions.ExtendedKeyUsageExt > ca.Policy.impl.GenericASN1Ext.class=com.netscape.cms.policy.extensions.GenericASN1Ext > ca.Policy.impl.IssuerAltNameExt.class=com.netscape.cms.policy.extensions.IssuerAltNameExt > ca.Policy.impl.IssuerConstraints.class=com.netscape.cms.policy.constraints.IssuerConstraints > ca.Policy.impl.KeyAlgorithmConstraints.class=com.netscape.cms.policy.constraints.KeyAlgorithmConstraints > ca.Policy.impl.KeyUsageExt.class=com.netscape.cms.policy.extensions.KeyUsageExt > ca.Policy.impl.NSCCommentExt.class=com.netscape.cms.policy.extensions.NSCCommentExt > ca.Policy.impl.NSCertTypeExt.class=com.netscape.cms.policy.extensions.NSCertTypeExt > ca.Policy.impl.NameConstraintsExt.class=com.netscape.cms.policy.extensions.NameConstraintsExt > ca.Policy.impl.OCSPNoCheckExt.class=com.netscape.cms.policy.extensions.OCSPNoCheckExt > ca.Policy.impl.PolicyConstraintsExt.class=com.netscape.cms.policy.extensions.PolicyConstraintsExt > ca.Policy.impl.PolicyMappingsExt.class=com.netscape.cms.policy.extensions.PolicyMappingsExt > ca.Policy.impl.PrivateKeyUsagePeriodExt.class=com.netscape.cms.policy.extensions.PrivateKeyUsagePeriodExt > ca.Policy.impl.RSAKeyConstraints.class=com.netscape.cms.policy.constraints.RSAKeyConstraints > ca.Policy.impl.RemoveBasicConstraintsExt.class=com.netscape.cms.policy.extensions.RemoveBasicConstraintsExt > ca.Policy.impl.RenewalConstraints.class=com.netscape.cms.policy.constraints.RenewalConstraints > ca.Policy.impl.RenewalValidityConstraints.class=com.netscape.cms.policy.constraints.RenewalValidityConstraints > ca.Policy.impl.RevocationConstraints.class=com.netscape.cms.policy.constraints.RevocationConstraints > ca.Policy.impl.SigningAlgorithmConstraints.class=com.netscape.cms.policy.constraints.SigningAlgorithmConstraints > ca.Policy.impl.SubCANameConstraints.class=com.netscape.cms.policy.constraints.SubCANameConstraints > ca.Policy.impl.SubjectAltNameExt.class=com.netscape.cms.policy.extensions.SubjectAltNameExt > ca.Policy.impl.SubjectDirectoryAttributesExt.class=com.netscape.cms.policy.extensions.SubjectDirectoryAttributesExt > ca.Policy.impl.SubjectKeyIdentifierExt.class=com.netscape.cms.policy.extensions.SubjectKeyIdentifierExt > ca.Policy.impl.UniqueSubjectNameConstraints.class=com.netscape.cms.policy.constraints.UniqueSubjectNameConstraints > ca.Policy.impl.ValidityConstraints.class=com.netscape.cms.policy.constraints.ValidityConstraints > ca.Policy.impl._000=## > ca.Policy.impl._001=## Policy Implementations > ca.Policy.impl._002=## > ca.Policy.order=KeyAlgRule, RSAKeyRule, DefaultValidityRule, RenewalConstraintsRule, DefaultRenewalValidityRule, RevocationConstraintsRule, NSCertTypeExt, CMCertKeyUsageExt, RMCertKeyUsageExt, ClientCertKeyUsageExt, ServerCertKeyUsageExt, ObjSignCertKeyUsageExt, CRLSignCertKeyUsageExt, SubjectKeyIdentifierExt, CertificatePoliciesExt, NSCCommentExt, OCSPNoCheckExt, OCSPSigningExt, CODESigningExt, GenericASN1Ext, CRLDistributionPointsExt, SubjectAltNameExt, SigningAlgRule, AuthorityKeyIdentifierExt, AuthInfoAccessExt, BasicConstraintsExt, UniqueSubjectNameConstraints, NameConstraintsExt, PolicyConstraintsExt, SubCANameConstraints, PolicyMappingsExt, IssuerRule > ca.Policy.processor=classic > ca.Policy.rule.AuthInfoAccessExt.ad0_location=http://pvlipa1001c.linux.infra.local:8080/ocsp > ca.Policy.rule.AuthInfoAccessExt.ad0_location_type=URL > ca.Policy.rule.AuthInfoAccessExt.ad0_method=ocsp > ca.Policy.rule.AuthInfoAccessExt.enable=false > ca.Policy.rule.AuthInfoAccessExt.implName=AuthInfoAccessExt > ca.Policy.rule.AuthInfoAccessExt.numADs=1 > ca.Policy.rule.AuthInfoAccessExt.predicate=HTTP_PARAMS.certType==client > ca.Policy.rule.AuthorityKeyIdentifierExt.enable=true > ca.Policy.rule.AuthorityKeyIdentifierExt.implName=AuthorityKeyIdentifierExt > ca.Policy.rule.AuthorityKeyIdentifierExt.predicate= > ca.Policy.rule.BasicConstraintsExt.critical=true > ca.Policy.rule.BasicConstraintsExt.enable=true > ca.Policy.rule.BasicConstraintsExt.implName=BasicConstraintsExt > ca.Policy.rule.BasicConstraintsExt.maxPathLen= > ca.Policy.rule.BasicConstraintsExt.predicate=HTTP_PARAMS.certType == ca > ca.Policy.rule.BasicConstraintsExt.removeBasicExt=true > ca.Policy.rule.CMCertKeyUsageExt.crlSign=true > ca.Policy.rule.CMCertKeyUsageExt.dataEncipherment=false > ca.Policy.rule.CMCertKeyUsageExt.decipherOnly=false > ca.Policy.rule.CMCertKeyUsageExt.digitalSignature=true > ca.Policy.rule.CMCertKeyUsageExt.enable=true > ca.Policy.rule.CMCertKeyUsageExt.encipherOnly=false > ca.Policy.rule.CMCertKeyUsageExt.implName=KeyUsageExt > ca.Policy.rule.CMCertKeyUsageExt.keyAgreement=false > ca.Policy.rule.CMCertKeyUsageExt.keyCertsign=true > ca.Policy.rule.CMCertKeyUsageExt.keyEncipherment=false > ca.Policy.rule.CMCertKeyUsageExt.nonRepudiation=true > ca.Policy.rule.CMCertKeyUsageExt.predicate=HTTP_PARAMS.certType==ca > ca.Policy.rule.CODESigningExt.critical=false > ca.Policy.rule.CODESigningExt.enable=true > ca.Policy.rule.CODESigningExt.id0=1.3.6.1.5.5.7.3.3 > ca.Policy.rule.CODESigningExt.implName=ExtendedKeyUsageExt > ca.Policy.rule.CODESigningExt.predicate=HTTP_PARAMS.certType==codeSignClient > ca.Policy.rule.CRLDistributionPointsExt.enable=false > ca.Policy.rule.CRLDistributionPointsExt.implName=CRLDistributionPointsExt > ca.Policy.rule.CRLDistributionPointsExt.issuerName0= > ca.Policy.rule.CRLDistributionPointsExt.issuerName1= > ca.Policy.rule.CRLDistributionPointsExt.issuerName2= > ca.Policy.rule.CRLDistributionPointsExt.issuerType0= > ca.Policy.rule.CRLDistributionPointsExt.issuerType1= > ca.Policy.rule.CRLDistributionPointsExt.issuerType2= > ca.Policy.rule.CRLDistributionPointsExt.numPoints=0 > ca.Policy.rule.CRLDistributionPointsExt.pointName0= > ca.Policy.rule.CRLDistributionPointsExt.pointName1= > ca.Policy.rule.CRLDistributionPointsExt.pointName2= > ca.Policy.rule.CRLDistributionPointsExt.pointType0= > ca.Policy.rule.CRLDistributionPointsExt.pointType1= > ca.Policy.rule.CRLDistributionPointsExt.pointType2= > ca.Policy.rule.CRLDistributionPointsExt.predicate= > ca.Policy.rule.CRLDistributionPointsExt.reasons0= > ca.Policy.rule.CRLDistributionPointsExt.reasons1= > ca.Policy.rule.CRLDistributionPointsExt.reasons2= > ca.Policy.rule.CRLSignCertKeyUsageExt.crlSign=true > ca.Policy.rule.CRLSignCertKeyUsageExt.dataEncipherment=false > ca.Policy.rule.CRLSignCertKeyUsageExt.decipherOnly=false > ca.Policy.rule.CRLSignCertKeyUsageExt.digitalSignature=false > ca.Policy.rule.CRLSignCertKeyUsageExt.enable=true > ca.Policy.rule.CRLSignCertKeyUsageExt.encipherOnly=false > ca.Policy.rule.CRLSignCertKeyUsageExt.implName=KeyUsageExt > ca.Policy.rule.CRLSignCertKeyUsageExt.keyAgreement=false > ca.Policy.rule.CRLSignCertKeyUsageExt.keyCertsign=false > ca.Policy.rule.CRLSignCertKeyUsageExt.keyEncipherment=false > ca.Policy.rule.CRLSignCertKeyUsageExt.nonRepudiation=false > ca.Policy.rule.CRLSignCertKeyUsageExt.predicate=HTTP_PARAMS.certType==caCrlSigning > ca.Policy.rule.CertificatePoliciesExt.certPolicy0.cpsURI= > ca.Policy.rule.CertificatePoliciesExt.certPolicy0.noticeRefNumbers= > ca.Policy.rule.CertificatePoliciesExt.certPolicy0.noticeRefOrganization= > ca.Policy.rule.CertificatePoliciesExt.certPolicy0.policyId= > ca.Policy.rule.CertificatePoliciesExt.certPolicy0.userNoticeExplicitText= > ca.Policy.rule.CertificatePoliciesExt.critical=false > ca.Policy.rule.CertificatePoliciesExt.enable=false > ca.Policy.rule.CertificatePoliciesExt.implName=CertificatePoliciesExt > ca.Policy.rule.CertificatePoliciesExt.numCertPolicies=1 > ca.Policy.rule.CertificatePoliciesExt.predicate= > ca.Policy.rule.ClientCertKeyUsageExt.crlSign=false > ca.Policy.rule.ClientCertKeyUsageExt.dataEncipherment=false > ca.Policy.rule.ClientCertKeyUsageExt.decipherOnly=false > ca.Policy.rule.ClientCertKeyUsageExt.digitalSignature=true > ca.Policy.rule.ClientCertKeyUsageExt.enable=true > ca.Policy.rule.ClientCertKeyUsageExt.encipherOnly=false > ca.Policy.rule.ClientCertKeyUsageExt.implName=KeyUsageExt > ca.Policy.rule.ClientCertKeyUsageExt.keyAgreement=false > ca.Policy.rule.ClientCertKeyUsageExt.keyCertsign=false > ca.Policy.rule.ClientCertKeyUsageExt.keyEncipherment=true > ca.Policy.rule.ClientCertKeyUsageExt.nonRepudiation=true > ca.Policy.rule.ClientCertKeyUsageExt.predicate=HTTP_PARAMS.certType==client > ca.Policy.rule.DSAKeyRule.enable=true > ca.Policy.rule.DSAKeyRule.implName=DSAKeyConstraints > ca.Policy.rule.DSAKeyRule.maxSize=1024 > ca.Policy.rule.DSAKeyRule.minSize=512 > ca.Policy.rule.DSAKeyRule.predicate= > ca.Policy.rule.DefaultRenewalValidityRule.enable=true > ca.Policy.rule.DefaultRenewalValidityRule.implName=RenewalValidityConstraints > ca.Policy.rule.DefaultRenewalValidityRule.maxValidity=365 > ca.Policy.rule.DefaultRenewalValidityRule.minValidity=30 > ca.Policy.rule.DefaultRenewalValidityRule.predicate= > ca.Policy.rule.DefaultRenewalValidityRule.renewalInterval=15 > ca.Policy.rule.DefaultValidityRule.enable=true > ca.Policy.rule.DefaultValidityRule.implName=ValidityConstraints > ca.Policy.rule.DefaultValidityRule.maxValidity=365 > ca.Policy.rule.DefaultValidityRule.minValidity=1 > ca.Policy.rule.DefaultValidityRule.predicate= > ca.Policy.rule.GenericASN1Ext.attribute.0.source= > ca.Policy.rule.GenericASN1Ext.attribute.0.type= > ca.Policy.rule.GenericASN1Ext.attribute.0.value= > ca.Policy.rule.GenericASN1Ext.attribute.1.source= > ca.Policy.rule.GenericASN1Ext.attribute.1.type= > ca.Policy.rule.GenericASN1Ext.attribute.1.value= > ca.Policy.rule.GenericASN1Ext.attribute.2.source= > ca.Policy.rule.GenericASN1Ext.attribute.2.type= > ca.Policy.rule.GenericASN1Ext.attribute.2.value= > ca.Policy.rule.GenericASN1Ext.attribute.3.source= > ca.Policy.rule.GenericASN1Ext.attribute.3.type= > ca.Policy.rule.GenericASN1Ext.attribute.3.value= > ca.Policy.rule.GenericASN1Ext.attribute.4.source= > ca.Policy.rule.GenericASN1Ext.attribute.4.type= > ca.Policy.rule.GenericASN1Ext.attribute.4.value= > ca.Policy.rule.GenericASN1Ext.attribute.5.source= > ca.Policy.rule.GenericASN1Ext.attribute.5.type= > ca.Policy.rule.GenericASN1Ext.attribute.5.value= > ca.Policy.rule.GenericASN1Ext.attribute.6.source= > ca.Policy.rule.GenericASN1Ext.attribute.6.type= > ca.Policy.rule.GenericASN1Ext.attribute.6.value= > ca.Policy.rule.GenericASN1Ext.attribute.7.source= > ca.Policy.rule.GenericASN1Ext.attribute.7.type= > ca.Policy.rule.GenericASN1Ext.attribute.7.value= > ca.Policy.rule.GenericASN1Ext.attribute.8.source= > ca.Policy.rule.GenericASN1Ext.attribute.8.type= > ca.Policy.rule.GenericASN1Ext.attribute.8.value= > ca.Policy.rule.GenericASN1Ext.attribute.9.source= > ca.Policy.rule.GenericASN1Ext.attribute.9.type= > ca.Policy.rule.GenericASN1Ext.attribute.9.value= > ca.Policy.rule.GenericASN1Ext.critical=false > ca.Policy.rule.GenericASN1Ext.enable=false > ca.Policy.rule.GenericASN1Ext.implName=GenericASN1Ext > ca.Policy.rule.GenericASN1Ext.name= > ca.Policy.rule.GenericASN1Ext.oid= > ca.Policy.rule.GenericASN1Ext.pattern= > ca.Policy.rule.GenericASN1Ext.predicate= > ca.Policy.rule.IssuerRule.enable=false > ca.Policy.rule.IssuerRule.implName=IssuerConstraints > ca.Policy.rule.IssuerRule.issuerDN= > ca.Policy.rule.IssuerRule.predicate=HTTP_PARAMS.certType==client AND certauthEnroll==on > ca.Policy.rule.KeyAlgRule.algorithms=RSA,DSA > ca.Policy.rule.KeyAlgRule.enable=true > ca.Policy.rule.KeyAlgRule.implName=KeyAlgorithmConstraints > ca.Policy.rule.KeyAlgRule.predicate= > ca.Policy.rule.NSCCommentExt.commentFile= > ca.Policy.rule.NSCCommentExt.enable=false > ca.Policy.rule.NSCCommentExt.implName=NSCCommentExt > ca.Policy.rule.NSCCommentExt.inputType=Text > ca.Policy.rule.NSCCommentExt.predicate= > ca.Policy.rule.NSCertTypeExt.enable=true > ca.Policy.rule.NSCertTypeExt.implName=NSCertTypeExt > ca.Policy.rule.NSCertTypeExt.predicate=HTTP_PARAMS.certType!=CEP-Request > ca.Policy.rule.NameConstraintsExt.critical=true > ca.Policy.rule.NameConstraintsExt.enable=false > ca.Policy.rule.NameConstraintsExt.excludedSubtrees0.base.generalNameChoice= > ca.Policy.rule.NameConstraintsExt.excludedSubtrees0.base.generalNameValue= > ca.Policy.rule.NameConstraintsExt.excludedSubtrees0.max=-1 > ca.Policy.rule.NameConstraintsExt.excludedSubtrees0.min=0 > ca.Policy.rule.NameConstraintsExt.excludedSubtrees1.base.generalNameChoice= > ca.Policy.rule.NameConstraintsExt.excludedSubtrees1.base.generalNameValue= > ca.Policy.rule.NameConstraintsExt.excludedSubtrees1.max=-1 > ca.Policy.rule.NameConstraintsExt.excludedSubtrees1.min=0 > ca.Policy.rule.NameConstraintsExt.excludedSubtrees2.base.generalNameChoice= > ca.Policy.rule.NameConstraintsExt.excludedSubtrees2.base.generalNameValue= > ca.Policy.rule.NameConstraintsExt.excludedSubtrees2.max=-1 > ca.Policy.rule.NameConstraintsExt.excludedSubtrees2.min=0 > ca.Policy.rule.NameConstraintsExt.implName=NameConstraintsExt > ca.Policy.rule.NameConstraintsExt.numExcludedSubtrees=3 > ca.Policy.rule.NameConstraintsExt.numPermittedSubtrees=3 > ca.Policy.rule.NameConstraintsExt.permittedSubtrees0.base.generalNameChoice= > ca.Policy.rule.NameConstraintsExt.permittedSubtrees0.base.generalNameValue= > ca.Policy.rule.NameConstraintsExt.permittedSubtrees0.max=-1 > ca.Policy.rule.NameConstraintsExt.permittedSubtrees0.min=0 > ca.Policy.rule.NameConstraintsExt.permittedSubtrees1.base.generalNameChoice= > ca.Policy.rule.NameConstraintsExt.permittedSubtrees1.base.generalNameValue= > ca.Policy.rule.NameConstraintsExt.permittedSubtrees1.max=-1 > ca.Policy.rule.NameConstraintsExt.permittedSubtrees1.min=0 > ca.Policy.rule.NameConstraintsExt.permittedSubtrees2.base.generalNameChoice= > ca.Policy.rule.NameConstraintsExt.permittedSubtrees2.base.generalNameValue= > ca.Policy.rule.NameConstraintsExt.permittedSubtrees2.max=-1 > ca.Policy.rule.NameConstraintsExt.permittedSubtrees2.min=0 > ca.Policy.rule.NameConstraintsExt.predicate=HTTP_PARAMS.certType == ca > ca.Policy.rule.OCSPNoCheckExt.critical=false > ca.Policy.rule.OCSPNoCheckExt.enable=true > ca.Policy.rule.OCSPNoCheckExt.implName=OCSPNoCheckExt > ca.Policy.rule.OCSPNoCheckExt.predicate=HTTP_PARAMS.certType==ocspResponder > ca.Policy.rule.OCSPSigningExt.critical=false > ca.Policy.rule.OCSPSigningExt.enable=true > ca.Policy.rule.OCSPSigningExt.id0=1.3.6.1.5.5.7.3.9 > ca.Policy.rule.OCSPSigningExt.implName=ExtendedKeyUsageExt > ca.Policy.rule.OCSPSigningExt.predicate=HTTP_PARAMS.certType==ocspResponder > ca.Policy.rule.ObjSignCertKeyUsageExt.crlSign=false > ca.Policy.rule.ObjSignCertKeyUsageExt.dataEncipherment=false > ca.Policy.rule.ObjSignCertKeyUsageExt.decipherOnly=false > ca.Policy.rule.ObjSignCertKeyUsageExt.digitalSignature=true > ca.Policy.rule.ObjSignCertKeyUsageExt.enable=true > ca.Policy.rule.ObjSignCertKeyUsageExt.encipherOnly=false > ca.Policy.rule.ObjSignCertKeyUsageExt.implName=KeyUsageExt > ca.Policy.rule.ObjSignCertKeyUsageExt.keyAgreement=false > ca.Policy.rule.ObjSignCertKeyUsageExt.keyCertsign=true > ca.Policy.rule.ObjSignCertKeyUsageExt.keyEncipherment=false > ca.Policy.rule.ObjSignCertKeyUsageExt.nonRepudiation=false > ca.Policy.rule.ObjSignCertKeyUsageExt.predicate=HTTP_PARAMS.certType==objSignClient > ca.Policy.rule.PolicyConstraintsExt.critical=false > ca.Policy.rule.PolicyConstraintsExt.enable=false > ca.Policy.rule.PolicyConstraintsExt.implName=PolicyConstraintsExt > ca.Policy.rule.PolicyConstraintsExt.inhibitPolicyMapping=0 > ca.Policy.rule.PolicyConstraintsExt.predicate=HTTP_PARAMS.certType==ca > ca.Policy.rule.PolicyConstraintsExt.reqExplicitPolicy=0 > ca.Policy.rule.PolicyMappingsExt.critical=false > ca.Policy.rule.PolicyMappingsExt.enable=false > ca.Policy.rule.PolicyMappingsExt.implName=PolicyMappingsExt > ca.Policy.rule.PolicyMappingsExt.numPolicyMappings=1 > ca.Policy.rule.PolicyMappingsExt.policyMap0.issuerDomainPolicy= > ca.Policy.rule.PolicyMappingsExt.policyMap0.subjectDomainPolicy= > ca.Policy.rule.PolicyMappingsExt.predicate=HTTP_PARAMS.certType==ca > ca.Policy.rule.RMCertKeyUsageExt.crlSign=false > ca.Policy.rule.RMCertKeyUsageExt.dataEncipherment=false > ca.Policy.rule.RMCertKeyUsageExt.decipherOnly=false > ca.Policy.rule.RMCertKeyUsageExt.digitalSignature=true > ca.Policy.rule.RMCertKeyUsageExt.enable=true > ca.Policy.rule.RMCertKeyUsageExt.encipherOnly=false > ca.Policy.rule.RMCertKeyUsageExt.implName=KeyUsageExt > ca.Policy.rule.RMCertKeyUsageExt.keyAgreement=false > ca.Policy.rule.RMCertKeyUsageExt.keyCertsign=false > ca.Policy.rule.RMCertKeyUsageExt.keyEncipherment=false > ca.Policy.rule.RMCertKeyUsageExt.nonRepudiation=true > ca.Policy.rule.RMCertKeyUsageExt.predicate=HTTP_PARAMS.certType==ra > ca.Policy.rule.RSAKeyRule.enable=false > ca.Policy.rule.RSAKeyRule.exponents=3,7,17,65537 > ca.Policy.rule.RSAKeyRule.implName=RSAKeyConstraints > ca.Policy.rule.RSAKeyRule.maxSize=2048 > ca.Policy.rule.RSAKeyRule.minSize=512 > ca.Policy.rule.RSAKeyRule.predicate= > ca.Policy.rule.RenewalConstraintsRule.enable=true > ca.Policy.rule.RenewalConstraintsRule.implName=RenewalConstraints > ca.Policy.rule.RenewalConstraintsRule.predicate= > ca.Policy.rule.RevocationConstraintsRule.enable=true > ca.Policy.rule.RevocationConstraintsRule.implName=RevocationConstraints > ca.Policy.rule.RevocationConstraintsRule.predicate= > ca.Policy.rule.ServerCertKeyUsageExt.crlSign=false > ca.Policy.rule.ServerCertKeyUsageExt.dataEncipherment=true > ca.Policy.rule.ServerCertKeyUsageExt.decipherOnly=false > ca.Policy.rule.ServerCertKeyUsageExt.digitalSignature=true > ca.Policy.rule.ServerCertKeyUsageExt.enable=true > ca.Policy.rule.ServerCertKeyUsageExt.encipherOnly=false > ca.Policy.rule.ServerCertKeyUsageExt.implName=KeyUsageExt > ca.Policy.rule.ServerCertKeyUsageExt.keyAgreement=false > ca.Policy.rule.ServerCertKeyUsageExt.keyCertsign=false > ca.Policy.rule.ServerCertKeyUsageExt.keyEncipherment=true > ca.Policy.rule.ServerCertKeyUsageExt.nonRepudiation=true > ca.Policy.rule.ServerCertKeyUsageExt.predicate=HTTP_PARAMS.certType==server > ca.Policy.rule.SigningAlgRule.algorithms=MD5withRSA,MD2withRSA,SHA1withRSA,SHA256withRSA,SHA512withRSA,SHA1withEC,SHA256withEC,SHA384withEC,SHA512withEC > ca.Policy.rule.SigningAlgRule.enable=true > ca.Policy.rule.SigningAlgRule.implName=SigningAlgorithmConstraints > ca.Policy.rule.SigningAlgRule.predicate= > ca.Policy.rule.SubCANameConstraints.enable=true > ca.Policy.rule.SubCANameConstraints.implName=SubCANameConstraints > ca.Policy.rule.SubCANameConstraints.predicate=HTTP_PARAMS.certType == ca > ca.Policy.rule.SubjectAltNameExt.enable=true > ca.Policy.rule.SubjectAltNameExt.generalName0.generalNameChoice=rfc822Name > ca.Policy.rule.SubjectAltNameExt.generalName0.requestAttr=AUTH_TOKEN.mail > ca.Policy.rule.SubjectAltNameExt.generalName1.generalNameChoice=rfc822Name > ca.Policy.rule.SubjectAltNameExt.generalName1.requestAttr=AUTH_TOKEN.mailalternateaddress > ca.Policy.rule.SubjectAltNameExt.generalName2.generalNameChoice=rfc822Name > ca.Policy.rule.SubjectAltNameExt.generalName2.requestAttr=HTTP_PARAMS.csrRequestorEmail > ca.Policy.rule.SubjectAltNameExt.implName=SubjectAltNameExt > ca.Policy.rule.SubjectAltNameExt.numGeneralNames=3 > ca.Policy.rule.SubjectAltNameExt.predicate=HTTP_PARAMS.certType!=CEP-Request > ca.Policy.rule.SubjectKeyIdentifierExt.enable=true > ca.Policy.rule.SubjectKeyIdentifierExt.implName=SubjectKeyIdentifierExt > ca.Policy.rule.SubjectKeyIdentifierExt.predicate=HTTP_PARAMS.certType==ca > ca.Policy.rule.UniqueSubjectNameConstraints.enable=false > ca.Policy.rule.UniqueSubjectNameConstraints.implName=UniqueSubjectNameConstraints > ca.Policy.rule.UniqueSubjectNameConstraints.predicate= > ca.audit_signing.cert=MIIDZzCCAk+gAwIBAgIBBTANBgkqhkiG9w0BAQsFADA8MRowGAYDVQQKDBFMSU5VWC5JTkZSQS5MT0NBTDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE1MDQxNDExNTM1NVoXDTE3MDQwMzExNTM1NVowLzEaMBgGA1UECgwRTElOVVguSU5GUkEuTE9DQUwxETAPBgNVBAMMCENBIEF1ZGl0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA85U4m8Gm5HCtaUJUP4v3c7E9Rmr1of+aD5sKJqtmKkrtxVJzYr/py9ZSz0i8nZLXNx2cHIDHMWTw9HXBEUg6yajiYTK2HpHiSX2nd1Wrg5bAmHWd7reN+rBMEyFFqmjxOdnueJJNwV/KVTbJybMt3W/EXLJZkDSr82r5Q21nJzRQr8hQfACwoICDNkyzqDv+Zuz3GrEIUd2t6qW0E4UnRByS531IhTx6TtxLJVrsueHM7glcB8IQgURzCirVewOrlKv22awR0GtLXKfJIGnVQYJnZRsHqoTD5qD99edQXoyoknsAPWUBHujbpmZsPJKXJHt/d6/aqs5wH+SHiXbBzQIDAQABo4GAMH4wHwYDVR0jBBgwFoAUZexymQXClfUG+N7hItMABoUSLYswDgYDVR0PAQH/BAQDAgbAMEsGCCsGAQUFBwEBBD8wPTA7BggrBgEFBQcwAYYvaHR0cDovL3B2bGlwYTEwMDFjLmxpbnV4LmluZnJhLmxvY2FsOjgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAFOfCXvtU8Yf7TbgdqTQ5VSa/3u2PwrZf2z92+FO/0cGfttTsQ8pRRl2/5z6ZJEX/Zy8naaP0hmsJGlq8U5KOvxIE9zstvtw/L7iuk2H9q/GcZvm0HVWkPaRFqr8q8ZNLCoP4I72xVzmqcoyat3g7BJYnGTos5+2e5JviorIBHfvuBgqbVBzKnQ5UMcfw93W4F/5rRXU+jq0gtDK3sVK2UvDE3dgOzxrbtuzDjqpQ84l/atUcIKizaoRQ6mcDyL2z5Fy9hxIrScH8iQIAEIP93D2HrbniNsgDLS3WD9Y2ikyB4TlJc4NUo0vL1MhyDOZY/yxwdjoBiYXpUAxm8I84gU= > ca.audit_signing.certreq=MIICdDCCAVwCAQAwLzEaMBgGA1UECgwRTElOVVguSU5GUkEuTE9DQUwxETAPBgNVBAMMCENBIEF1ZGl0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA85U4m8Gm5HCtaUJUP4v3c7E9Rmr1of+aD5sKJqtmKkrtxVJzYr/py9ZSz0i8nZLXNx2cHIDHMWTw9HXBEUg6yajiYTK2HpHiSX2nd1Wrg5bAmHWd7reN+rBMEyFFqmjxOdnueJJNwV/KVTbJybMt3W/EXLJZkDSr82r5Q21nJzRQr8hQfACwoICDNkyzqDv+Zuz3GrEIUd2t6qW0E4UnRByS531IhTx6TtxLJVrsueHM7glcB8IQgURzCirVewOrlKv22awR0GtLXKfJIGnVQYJnZRsHqoTD5qD99edQXoyoknsAPWUBHujbpmZsPJKXJHt/d6/aqs5wH+SHiXbBzQIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAPCQNS91vUmhDUwuBO8dNGdjIMhzgKsWscvkwED6J6pMWThOAn4iUBHUWalrwEX4I6srOyY4r6EGXqlWsKCK9uoR1Ym3cBTP7lVd04ipr8/LNmkZtgZxjw/I5fA0tIkrbrQf/6CS0AqTtPxZXnjzcUdohrMsKdxSCmPcs9dNubUUoBUpKQjjdTDnB+N9Ey9Au6buSW2n5SE/ljlARPPl7HxNVf/18weU7ZcYIA+xO381XRC35jC4NV5u908zms0fGMBQ02egbp4ytej4dWnIp8R1yyODyMKDYcV9sbay1GJkgpbhVcaoZoQwwygYABOlq9SAYOUkgVjOqWhtb/Cm7Oo= > ca.audit_signing.nickname=auditSigningCert cert-pki-ca > ca.audit_signing.tokenname=Internal Key Storage Token > ca.cert.audit_signing.certusage=ObjectSigner > ca.cert.audit_signing.nickname=auditSigningCert cert-pki-ca > ca.cert.list=signing,ocsp_signing,sslserver,subsystem,audit_signing > ca.cert.ocsp_signing.certusage=StatusResponder > ca.cert.ocsp_signing.nickname=ocspSigningCert cert-pki-ca > ca.cert.signing.certusage=SSLCA > ca.cert.signing.nickname=caSigningCert cert-pki-ca > ca.cert.sslserver.certusage=SSLServer > ca.cert.sslserver.nickname=Server-Cert cert-pki-ca > ca.cert.subsystem.certusage=SSLClient > ca.cert.subsystem.nickname=subsystemCert cert-pki-ca > ca.certdbInc=20 > ca.crl.MasterCRL.allowExtensions=true > ca.crl.MasterCRL.alwaysUpdate=false > ca.crl.MasterCRL.autoUpdateInterval=240 > ca.crl.MasterCRL.caCertsOnly=false > ca.crl.MasterCRL.cacheUpdateInterval=15 > ca.crl.MasterCRL.class=com.netscape.ca.CRLIssuingPoint > ca.crl.MasterCRL.dailyUpdates=1:00 > ca.crl.MasterCRL.description=CA's complete Certificate Revocation List > ca.crl.MasterCRL.enable=true > ca.crl.MasterCRL.enableCRLCache=false > ca.crl.MasterCRL.enableCRLUpdates=false > ca.crl.MasterCRL.enableCacheRecovery=true > ca.crl.MasterCRL.enableCacheTesting=false > ca.crl.MasterCRL.enableDailyUpdates=true > ca.crl.MasterCRL.enableUpdateInterval=true > ca.crl.MasterCRL.extendedNextUpdate=true > ca.crl.MasterCRL.extension.AuthorityInformationAccess.accessLocation0= > ca.crl.MasterCRL.extension.AuthorityInformationAccess.accessLocationType0=URI > ca.crl.MasterCRL.extension.AuthorityInformationAccess.accessMethod0=caIssuers > ca.crl.MasterCRL.extension.AuthorityInformationAccess.class=com.netscape.cms.crl.CMSAuthInfoAccessExtension > ca.crl.MasterCRL.extension.AuthorityInformationAccess.critical=false > ca.crl.MasterCRL.extension.AuthorityInformationAccess.enable=false > ca.crl.MasterCRL.extension.AuthorityInformationAccess.numberOfAccessDescriptions=1 > ca.crl.MasterCRL.extension.AuthorityInformationAccess.type=CRLExtension > ca.crl.MasterCRL.extension.AuthorityKeyIdentifier.class=com.netscape.cms.crl.CMSAuthorityKeyIdentifierExtension > ca.crl.MasterCRL.extension.AuthorityKeyIdentifier.critical=false > ca.crl.MasterCRL.extension.AuthorityKeyIdentifier.enable=false > ca.crl.MasterCRL.extension.AuthorityKeyIdentifier.type=CRLExtension > ca.crl.MasterCRL.extension.CRLNumber.class=com.netscape.cms.crl.CMSCRLNumberExtension > ca.crl.MasterCRL.extension.CRLNumber.critical=false > ca.crl.MasterCRL.extension.CRLNumber.enable=true > ca.crl.MasterCRL.extension.CRLNumber.type=CRLExtension > ca.crl.MasterCRL.extension.CRLReason.class=com.netscape.cms.crl.CMSCRLReasonExtension > ca.crl.MasterCRL.extension.CRLReason.critical=false > ca.crl.MasterCRL.extension.CRLReason.enable=true > ca.crl.MasterCRL.extension.CRLReason.type=CRLEntryExtension > ca.crl.MasterCRL.extension.DeltaCRLIndicator.class=com.netscape.cms.crl.CMSDeltaCRLIndicatorExtension > ca.crl.MasterCRL.extension.DeltaCRLIndicator.critical=true > ca.crl.MasterCRL.extension.DeltaCRLIndicator.enable=false > ca.crl.MasterCRL.extension.DeltaCRLIndicator.type=CRLExtension > ca.crl.MasterCRL.extension.FreshestCRL.class=com.netscape.cms.crl.CMSFreshestCRLExtension > ca.crl.MasterCRL.extension.FreshestCRL.critical=false > ca.crl.MasterCRL.extension.FreshestCRL.enable=false > ca.crl.MasterCRL.extension.FreshestCRL.numPoints=0 > ca.crl.MasterCRL.extension.FreshestCRL.pointName0= > ca.crl.MasterCRL.extension.FreshestCRL.pointType0= > ca.crl.MasterCRL.extension.FreshestCRL.type=CRLExtension > ca.crl.MasterCRL.extension.InvalidityDate.class=com.netscape.cms.crl.CMSInvalidityDateExtension > ca.crl.MasterCRL.extension.InvalidityDate.critical=false > ca.crl.MasterCRL.extension.InvalidityDate.enable=true > ca.crl.MasterCRL.extension.InvalidityDate.type=CRLEntryExtension > ca.crl.MasterCRL.extension.IssuerAlternativeName.class=com.netscape.cms.crl.CMSIssuerAlternativeNameExtension > ca.crl.MasterCRL.extension.IssuerAlternativeName.critical=false > ca.crl.MasterCRL.extension.IssuerAlternativeName.enable=false > ca.crl.MasterCRL.extension.IssuerAlternativeName.name0= > ca.crl.MasterCRL.extension.IssuerAlternativeName.nameType0= > ca.crl.MasterCRL.extension.IssuerAlternativeName.numNames=0 > ca.crl.MasterCRL.extension.IssuerAlternativeName.type=CRLExtension > ca.crl.MasterCRL.extension.IssuingDistributionPoint.class=com.netscape.cms.crl.CMSIssuingDistributionPointExtension > ca.crl.MasterCRL.extension.IssuingDistributionPoint.critical=true > ca.crl.MasterCRL.extension.IssuingDistributionPoint.enable=false > ca.crl.MasterCRL.extension.IssuingDistributionPoint.indirectCRL=false > ca.crl.MasterCRL.extension.IssuingDistributionPoint.onlyContainsCACerts=false > ca.crl.MasterCRL.extension.IssuingDistributionPoint.onlyContainsUserCerts=false > ca.crl.MasterCRL.extension.IssuingDistributionPoint.onlySomeReasons= > ca.crl.MasterCRL.extension.IssuingDistributionPoint.pointName= > ca.crl.MasterCRL.extension.IssuingDistributionPoint.pointType= > ca.crl.MasterCRL.extension.IssuingDistributionPoint.type=CRLExtension > ca.crl.MasterCRL.includeExpiredCerts=false > ca.crl.MasterCRL.minUpdateInterval=0 > ca.crl.MasterCRL.nextUpdateGracePeriod=0 > ca.crl.MasterCRL.publishOnStart=false > ca.crl.MasterCRL.saveMemory=false > ca.crl.MasterCRL.signingAlgorithm=SHA256withRSA > ca.crl.MasterCRL.updateSchema=1 > ca.crl._000=## > ca.crl._001=## CA CRL > ca.crl._002=## > ca.crl.pageSize=100 > ca.crldbInc=20 > ca.enableNonces=false > ca.id=ca > ca.listenToCloneModifications=false > ca.local=true > ca.maxNumberOfNonces=100 > ca.maxSearchReturns=1000 > ca.maxSearchReturns._000=## > ca.maxSearchReturns._001=## limits number of search results > ca.maxSearchReturns._002=## returned by SearchReqs and SrchCerts > ca.maxSearchReturns._003=## > ca.notification.certIssued.emailSubject=Your Certificate Request > ca.notification.certIssued.emailTemplate=/var/lib/pki/pki-tomcat/ca/emails/certIssued_CA.html > ca.notification.certIssued.enabled=false > ca.notification.certIssued.senderEmail= > ca.notification.certRevoked.emailSubject=Your Certificate Revoked > ca.notification.certRevoked.emailTemplate=/var/lib/pki/pki-tomcat/ca/emails/certRevoked_CA.html > ca.notification.certRevoked.enabled=false > ca.notification.certRevoked.senderEmail= > ca.notification.requestInQ.emailSubject=Certificate Request in Queue > ca.notification.requestInQ.emailTemplate=/var/lib/pki/pki-tomcat/ca/emails/reqInQueue_CA.html > ca.notification.requestInQ.enabled=false > ca.notification.requestInQ.recipientEmail= > ca.notification.requestInQ.senderEmail= > ca.ocsp=true > ca.ocspUseCache=false > ca.ocsp_signing.cacertnickname=ocspSigningCert cert-pki-ca > ca.ocsp_signing.cert=MIIDgzCCAmugAwIBAgIBAjANBgkqhkiG9w0BAQsFADA8MRowGAYDVQQKDBFMSU5VWC5JTkZSQS5MT0NBTDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE1MDQxNDExNTM1M1oXDTE3MDQwMzExNTM1M1owNTEaMBgGA1UECgwRTElOVVguSU5GUkEuTE9DQUwxFzAVBgNVBAMMDk9DU1AgU3Vic3lzdGVtMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAze0A7XlQRdDVRIfbxoZWNji0OV7nYi8pw+Lm7cvBED2DLINmOTlNhcItXTJrek6GVQiJGdISU/467oLYkewIWOTnQxeEhI+xkU8Eh2QmJGxpMK3LH3ULsD13CP7r6KpnrenSiwJ9QjrYLgTUSits0swZT+1V6Qoty05uyVLMFPNh5nMjhMI2h9bJbYBnzGmWVZldgNfr5WfWnaMFf6g8+pHeSeozCJiYBtw7jpXBysJi4rbMMB4UtyglreXBEqBdEiio2nJ+1KmyImYGeyJjjgCozNuo7ykLJB3t6EqEroIy+l43DMmE4cxrre85hikgCNO9rWw91cu1XkC4ZF0hlwIDAQABo4GWMIGTMB8GA1UdIwQYMBaAFGXscpkFwpX1Bvje4SLTAAaFEi2LMA4GA1UdDwEB/wQEAwIBxjBLBggrBgEFBQcBAQQ/MD0wOwYIKwYBBQUHMAGGL2h0dHA6Ly9wdmxpcGExMDAxYy5saW51eC5pbmZyYS5sb2NhbDo4MC9jYS9vY3NwMBMGA1UdJQQMMAoGCCsGAQUFBwMJMA0GCSqGSIb3DQEBCwUAA4IBAQCTjcq7iSI8r3NZqhK/f+SRBh6t4RjHwXv0QHPQIpQcpQMu6VCsiaKIQ9t2h4s6o5rDQqg0KYpla7ie+4L+UuwSo7EYMhjD+afPIfLiUp67K41g5tQ3Wl3+ZBVp/w9732/oZDrmIS1/3zKdQ9JaQYB9Lth2A/qt9/CyYwG7bXV6PDf7ch/YqNtN/Dc2asjzmx9E5CTl82kMVX9Lij2XSN9Mzu8qFvse79SPvFIr8iAM34N1PF6wJSl8vWWYubQMm+j1mDlC9kS0r/JTmrHbTQXeKe/VIWhbnJe585szTqcCvtA0izFzHLt+RG7i6DVSdDwymeTRZERV3kyrmcPdU8sc > ca.ocsp_signing.certnickname=ocspSigningCert cert-pki-ca > ca.ocsp_signing.certreq=MIICejCCAWICAQAwNTEaMBgGA1UECgwRTElOVVguSU5GUkEuTE9DQUwxFzAVBgNVBAMMDk9DU1AgU3Vic3lzdGVtMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAze0A7XlQRdDVRIfbxoZWNji0OV7nYi8pw+Lm7cvBED2DLINmOTlNhcItXTJrek6GVQiJGdISU/467oLYkewIWOTnQxeEhI+xkU8Eh2QmJGxpMK3LH3ULsD13CP7r6KpnrenSiwJ9QjrYLgTUSits0swZT+1V6Qoty05uyVLMFPNh5nMjhMI2h9bJbYBnzGmWVZldgNfr5WfWnaMFf6g8+pHeSeozCJiYBtw7jpXBysJi4rbMMB4UtyglreXBEqBdEiio2nJ+1KmyImYGeyJjjgCozNuo7ykLJB3t6EqEroIy+l43DMmE4cxrre85hikgCNO9rWw91cu1XkC4ZF0hlwIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAGsMxgYXMV/V2iItgNQ9CJHmgZAfw2ZZp4NsPoF+Hk0oWwSaVIGpq6q+xIZiCgOtpkjKC8xwIJuYoZbTeiw9XEW+V63J6xWLIQl02rrtIC1Enr3mGsc3u+MbPY3/J4fmwX8ys+Cc44STVYxO8wMGi05PXfKLNuTRvZbuB7UPXuHAWIdaL+KXhSF7UU9MOW/AuSYXQDNke7YgQtk5VEIg5ZAdXeJHNVS7zB2/KgVXEfF2L6rZHyp7nPmRJCAWJpAF/9op6HNHway2+U6EjQhWttBn/mHhcWu8MC6n0pPa+TOA1cg4cxyHxZ5nbOJ/0e8lyMNKr0Q/ThxQVIQmdPdjZWs= > ca.ocsp_signing.defaultSigningAlgorithm=SHA256withRSA > ca.ocsp_signing.newNickname=ocspSigningCert cert-pki-ca > ca.ocsp_signing.nickname=ocspSigningCert cert-pki-ca > ca.ocsp_signing.tokenname=Internal Key Storage Token > ca.profiles.defaultSigningAlgsAllowed=SHA256withRSA,SHA1withRSA,SHA512withRSA,MD5withRSA,MD2withRSA,SHA1withDSA,SHA256withEC,SHA1withEC,SHA384withEC,SHA512withEC > ca.publish.createOwnDNEntry=false > ca.publish.enable=true > ca.publish.ldappublish.enable=false > ca.publish.mapper.impl.LdapCaSimpleMap.class=com.netscape.cms.publish.mappers.LdapCaSimpleMap > ca.publish.mapper.impl.LdapDNCompsMap.class=com.netscape.cms.publish.mappers.LdapCertCompsMap > ca.publish.mapper.impl.LdapDNExactMap.class=com.netscape.cms.publish.mappers.LdapCertExactMap > ca.publish.mapper.impl.LdapEnhancedMap.class=com.netscape.cms.publish.mappers.LdapEnhancedMap > ca.publish.mapper.impl.LdapSimpleMap.class=com.netscape.cms.publish.mappers.LdapSimpleMap > ca.publish.mapper.impl.LdapSubjAttrMap.class=com.netscape.cms.publish.mappers.LdapCertSubjMap > ca.publish.mapper.impl.NoMap.class=com.netscape.cms.publish.mappers.NoMap > ca.publish.mapper.instance.LdapCaCertMap.createCAEntry=true > ca.publish.mapper.instance.LdapCaCertMap.dnPattern=UID=$subj.cn,OU=people,O=$subj.o > ca.publish.mapper.instance.LdapCaCertMap.pluginName=LdapCaSimpleMap > ca.publish.mapper.instance.LdapCrlMap.createCAEntry=true > ca.publish.mapper.instance.LdapCrlMap.dnPattern=UID=$subj.cn,OU=people,O=$subj.o > ca.publish.mapper.instance.LdapCrlMap.pluginName=LdapCaSimpleMap > ca.publish.mapper.instance.LdapUserCertMap.dnPattern=UID=$subj.UID,OU=people,O=$subj.o > ca.publish.mapper.instance.LdapUserCertMap.pluginName=LdapSimpleMap > ca.publish.mapper.instance.NoMap.pluginName=NoMap > ca.publish.publisher.impl.FileBasedPublisher.class=com.netscape.cms.publish.publishers.FileBasedPublisher > ca.publish.publisher.impl.LdapCaCertPublisher.class=com.netscape.cms.publish.publishers.LdapCaCertPublisher > ca.publish.publisher.impl.LdapCertificatePairPublisher.class=com.netscape.cms.publish.publishers.LdapCertificatePairPublisher > ca.publish.publisher.impl.LdapCrlPublisher.class=com.netscape.cms.publish.publishers.LdapCrlPublisher > ca.publish.publisher.impl.LdapDeltaCrlPublisher.class=com.netscape.cms.publish.publishers.LdapCrlPublisher > ca.publish.publisher.impl.LdapUserCertPublisher.class=com.netscape.cms.publish.publishers.LdapUserCertPublisher > ca.publish.publisher.impl.OCSPPublisher.class=com.netscape.cms.publish.publishers.OCSPPublisher > ca.publish.publisher.instance.FileBaseCRLPublisher.Filename.b64=false > ca.publish.publisher.instance.FileBaseCRLPublisher.Filename.der=true > ca.publish.publisher.instance.FileBaseCRLPublisher.crlLinkExt=bin > ca.publish.publisher.instance.FileBaseCRLPublisher.directory=/var/lib/ipa/pki-ca/publish > ca.publish.publisher.instance.FileBaseCRLPublisher.latestCrlLink=true > ca.publish.publisher.instance.FileBaseCRLPublisher.pluginName=FileBasedPublisher > ca.publish.publisher.instance.FileBaseCRLPublisher.timeStamp=LocalTime > ca.publish.publisher.instance.FileBaseCRLPublisher.zipCRLs=false > ca.publish.publisher.instance.FileBaseCRLPublisher.zipLevel=9 > ca.publish.publisher.instance.LdapCaCertPublisher.caCertAttr=caCertificate;binary > ca.publish.publisher.instance.LdapCaCertPublisher.caObjectClass=pkiCA > ca.publish.publisher.instance.LdapCaCertPublisher.pluginName=LdapCaCertPublisher > ca.publish.publisher.instance.LdapCrlPublisher.crlAttr=certificateRevocationList;binary > ca.publish.publisher.instance.LdapCrlPublisher.crlObjectClass=pkiCA > ca.publish.publisher.instance.LdapCrlPublisher.pluginName=LdapCrlPublisher > ca.publish.publisher.instance.LdapCrossCertPairPublisher.caObjectClass=pkiCA > ca.publish.publisher.instance.LdapCrossCertPairPublisher.crossCertPairAttr=crossCertificatePair;binary > ca.publish.publisher.instance.LdapCrossCertPairPublisher.pluginName=LdapCertificatePairPublisher > ca.publish.publisher.instance.LdapDeltaCrlPublisher.crlAttr=deltaRevocationList;binary > ca.publish.publisher.instance.LdapDeltaCrlPublisher.crlObjectClass=pkiCA,deltaCRL > ca.publish.publisher.instance.LdapDeltaCrlPublisher.pluginName=LdapDeltaCrlPublisher > ca.publish.publisher.instance.LdapUserCertPublisher.certAttr=userCertificate;binary > ca.publish.publisher.instance.LdapUserCertPublisher.pluginName=LdapUserCertPublisher > ca.publish.queue.enable=true > ca.publish.queue.maxNumberOfThreads=3 > ca.publish.queue.pageSize=40 > ca.publish.queue.priorityLevel=0 > ca.publish.queue.saveStatus=200 > ca.publish.rule.impl.Rule.class=com.netscape.cmscore.ldap.LdapRule > ca.publish.rule.instance.FileCrlRule.enable=true > ca.publish.rule.instance.FileCrlRule.mapper=NoMap > ca.publish.rule.instance.FileCrlRule.pluginName=Rule > ca.publish.rule.instance.FileCrlRule.predicate= > ca.publish.rule.instance.FileCrlRule.publisher=FileBaseCRLPublisher > ca.publish.rule.instance.FileCrlRule.type=crl > ca.publish.rule.instance.LdapCaCertRule.enable=false > ca.publish.rule.instance.LdapCaCertRule.mapper=LdapCaCertMap > ca.publish.rule.instance.LdapCaCertRule.pluginName=Rule > ca.publish.rule.instance.LdapCaCertRule.predicate= > ca.publish.rule.instance.LdapCaCertRule.publisher=LdapCaCertPublisher > ca.publish.rule.instance.LdapCaCertRule.type=cacert > ca.publish.rule.instance.LdapCrlRule.enable=false > ca.publish.rule.instance.LdapCrlRule.mapper=LdapCrlMap > ca.publish.rule.instance.LdapCrlRule.pluginName=Rule > ca.publish.rule.instance.LdapCrlRule.predicate= > ca.publish.rule.instance.LdapCrlRule.publisher=LdapCrlPublisher > ca.publish.rule.instance.LdapCrlRule.type=crl > ca.publish.rule.instance.LdapUserCertRule.enable=false > ca.publish.rule.instance.LdapUserCertRule.mapper=LdapUserCertMap > ca.publish.rule.instance.LdapUserCertRule.pluginName=Rule > ca.publish.rule.instance.LdapUserCertRule.predicate= > ca.publish.rule.instance.LdapUserCertRule.publisher=LdapUserCertPublisher > ca.publish.rule.instance.LdapUserCertRule.type=certs > ca.publish.rule.instance.LdapXCertRule.enable=false > ca.publish.rule.instance.LdapXCertRule.mapper=LdapCaCertMap > ca.publish.rule.instance.LdapXCertRule.pluginName=Rule > ca.publish.rule.instance.LdapXCertRule.predicate= > ca.publish.rule.instance.LdapXCertRule.publisher=LdapCrossCertPairPublisher > ca.publish.rule.instance.LdapXCertRule.type=xcert > ca.reqdbInc=20 > ca.scep._000=## > ca.scep._001=## Enable the following parameters to enable SCEP requests > ca.scep._002=## to be signed by a separate key pair: > ca.scep._003=## > ca.scep._004=## ca.scep.nickname= > ca.scep._005=## ca.scep.tokenname= > ca.scep._006=## > ca.scep.allowedEncryptionAlgorithms=DES3 > ca.scep.allowedHashAlgorithms=SHA1,SHA256,SHA512 > ca.scep.enable=false > ca.scep.encryptionAlgorithm=DES3 > ca.scep.hashAlgorithm=SHA1 > ca.scep.nonceSizeLimit=16 > ca.signing.cacertnickname=caSigningCert cert-pki-ca > ca.signing.cert=MIIDpTCCAo2gAwIBAgIBATANBgkqhkiG9w0BAQsFADA8MRowGAYDVQQKDBFMSU5VWC5JTkZSQS5MT0NBTDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE1MDQxNDExNTM1MloXDTM1MDQxNDExNTM1MlowPDEaMBgGA1UECgwRTElOVVguSU5GUkEuTE9DQUwxHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL+VeKVdtRqM1Nodjp7hrrLsoT1jSqEo1FEe7FrLXBv/nrnMXJwUR9SbivhIrQFHf11MD2hHzFVzKq4rtoslT5sb8IojAmdxscx2WeHANEl6ydWKyCsWsv6/1n1/YEZBrKXpMfZFkrp286vTk0y2L4SScebtRc8zfpHBS2rA/gHxuOuGtyRLRNxJSGwdicdDgBPJSkJuXpZGrIaNLOcjL22Q7wb/a8HcuV9DxxfEDGbkNUPLx/dTkRBmf5pZnAyu7MYMJ9QZaCvxGLk6HEP++PBiBMxMcFgULrS0UrS7OXvHXtwnA8LPnlwZqa/i54MVfpQ5KIzCoFGDA9YiSwsNBYcCAwEAAaOBsTCBrjAfBgNVHSMEGDAWgBRl7HKZBcKV9Qb43uEi0wAGhRItizAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjAdBgNVHQ4EFgQUZexymQXClfUG+N7hItMABoUSLYswSwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzABhi9odHRwOi8vcHZsaXBhMTAwMWMubGludXguaW5mcmEubG9jYWw6ODAvY2Evb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEALSZSv9EQIWfKWaiIDnfi6E0YQKQ/gqXL14v5wysSVQWfEky2JtmV2pKz8hsFys8bB+3nxvM2MV/a8j8eCAcgIeFx0Vm6VPYEGf73KnJL9NKVTpe7yksBQVYTgOGiCm1t88pBPmVlaucSv9H/Hl+7sDFZgkIQae0Ghhij+lC3TrtXMdPRNXCdWAgjgWdy7qDdDRoBZK514pfSbhLrMsuz5OlUKvBS+pQ7y/tU4opRw48ZMcrUHT5uaDl3VzrjOyW+WCaq3HPUdVJQvcQ/Sf9QJB6jiocG5v3kmV3hSbgztZYIaDdFt4UKnmSfPRaF5dDwDRn3aHGd93GKSsaC91vFkg== > ca.signing.certnickname=caSigningCert cert-pki-ca > ca.signing.certreq=MIICszCCAZsCAQAwPDEaMBgGA1UECgwRTElOVVguSU5GUkEuTE9DQUwxHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL+VeKVdtRqM1Nodjp7hrrLsoT1jSqEo1FEe7FrLXBv/nrnMXJwUR9SbivhIrQFHf11MD2hHzFVzKq4rtoslT5sb8IojAmdxscx2WeHANEl6ydWKyCsWsv6/1n1/YEZBrKXpMfZFkrp286vTk0y2L4SScebtRc8zfpHBS2rA/gHxuOuGtyRLRNxJSGwdicdDgBPJSkJuXpZGrIaNLOcjL22Q7wb/a8HcuV9DxxfEDGbkNUPLx/dTkRBmf5pZnAyu7MYMJ9QZaCvxGLk6HEP++PBiBMxMcFgULrS0UrS7OXvHXtwnA8LPnlwZqa/i54MVfpQ5KIzCoFGDA9YiSwsNBYcCAwEAAaAyMDAGCSqGSIb3DQEJDjEjMCEwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAcYwDQYJKoZIhvcNAQELBQADggEBAD0p97jh3nGT+fYWcUAOA547WJDm+cP5dvCCAUCm8L0/5T/9lu0bxmdbCR0P+pAgMkCQgOkV9wcEXuHmlxp7bFe8C+codYgVBGXFiHGelPsmPYjRpR1tFTpbd7SXkc1C3W2v6ND9+bE104H0C6Bqb9eK+HqyaPw1mplPL2zRSPYK8bq+6fpxWhQ4nTgrS5PZXvWzcd6NlTE90XaUd1E6EyjGlQhxjDkmAP5qbDWyA8lzWl2lFm2bWwO5pD/BRLJXd99ghRc7hyVrCiral800+KR5GE8hDBxoHUT7Qlr8jSRLm90teFd6sSJURI9dd+MG/Cn63iDoAMCcKGRVYwqBs7o= > ca.signing.defaultSigningAlgorithm=SHA256withRSA > ca.signing.newNickname=caSigningCert cert-pki-ca > ca.signing.nickname=caSigningCert cert-pki-ca > ca.signing.tokenname=Internal Key Storage Token > ca.sslserver.cert=MIIDqTCCApGgAwIBAgIED/8ACDANBgkqhkiG9w0BAQsFADA8MRowGAYDVQQKDBFMSU5VWC5JTkZSQS5MT0NBTDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE1MDgxMjA4MjA1MVoXDTE3MDgwMTA4MjA1MVowRDEaMBgGA1UECgwRTElOVVguSU5GUkEuTE9DQUwxJjAkBgNVBAMMHXB2bGlwYTEwMDFjLmxpbnV4LmluZnJhLmxvY2FsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA43686s6CsHibKz+JKpQFkLkgisSNTaFqEUE1t7+0mmCP9BPLAmeA74Hv1xXYXsjaSrZUypRQReYLgOnwkSD0zU0uBxMjlQCcvJcHe6XFyBo0UH3fA+K9aFmnpM2CDL2HTsaN7hhWKxQlwz85iLUXM1/kDR6+FNUTfXEJLtodko6BjuJdv/zKaNZOhdXgA1PjApDgMhiIdT/dqOL7tc5pxP2w411qFjGoIzmo4GHQnKNh6k3jkZgVXmpE0tPO3hqNGrn5rZglQNUB89Kargt8uiI9oRQPAGgq/sz+jh3AHJZiEt7vSOc53hG8sBOfT/jvaHjqL2FEDwvZ+a6ZOcYdxQIDAQABo4GqMIGnMB8GA1UdIwQYMBaAFGXscpkFwpX1Bvje4SLTAAaFEi2LMEsGCCsGAQUFBwEBBD8wPTA7BggrBgEFBQcwAYYvaHR0cDovL3B2bGlwYTEwMDFhLmxpbnV4LmluZnJhLmxvY2FsOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMCcGA1UdJQQgMB4GCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBACm5WGj8sfjeD3UUD9nor+vuItcOF9HLevfV/68ryD0auMBfc8/+V4X0y5PPsiYW6vxE4bA35C1gTrh1eJg9QwpRuLqgVrOoTjJych+5gLS/wYFmTElmjLW3c3VpyB+UJC6Qh7SfFFz6q7felhqhX7OpJIsBycZAYjJ2D0cFzCm0JE0wFSXwKHeHSdij2aMbMCUrlP5tP1Chh18RMCXUPLaouj/8csyTeqZtI3IfCxOACG9yx3R8iLDC4APG64PiDuP8Jo6juh494xKwqIhZQwRhxI05C84cHkfDVB0InvYHkzrhmOpJz1KtJGbPPpTRD961ZOXGqGy06Pusmx+WWyg= > ca.sslserver.certreq=MIICiTCCAXECAQAwRDEaMBgGA1UECgwRTElOVVguSU5GUkEuTE9DQUwxJjAkBgNVBAMMHXB2bGlwYTEwMDFjLmxpbnV4LmluZnJhLmxvY2FsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA43686s6CsHibKz+JKpQFkLkgisSNTaFqEUE1t7+0mmCP9BPLAmeA74Hv1xXYXsjaSrZUypRQReYLgOnwkSD0zU0uBxMjlQCcvJcHe6XFyBo0UH3fA+K9aFmnpM2CDL2HTsaN7hhWKxQlwz85iLUXM1/kDR6+FNUTfXEJLtodko6BjuJdv/zKaNZOhdXgA1PjApDgMhiIdT/dqOL7tc5pxP2w411qFjGoIzmo4GHQnKNh6k3jkZgVXmpE0tPO3hqNGrn5rZglQNUB89Kargt8uiI9oRQPAGgq/sz+jh3AHJZiEt7vSOc53hG8sBOfT/jvaHjqL2FEDwvZ+a6ZOcYdxQIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAOGzg7Nc+rFjLwzbR2k7pVbbEAI3Kt4PGTfPX+X4r9lbwKAovcwdmeJzs5m/g/nRVwMLV+hEJ99d8nyB1lFRIfeJ1jTrRCvOw/gTxOd2PMNwn+jk1m22JIms+LCfYqYmUoLEG9M8l9iVhbLqK+0coSv7nBkJhoexE3MH5MhEUPFC0cI+O6veb7PUHxBKVKNWdrWJUZTnuCN2MzbqCNUKhUFvCw3vvNpofPXv3xmWG8Ep6+j/Wj4ZTqn15HyyC4hNh2kVWK2ysMrx8Gy/iINpFHmCLF53JAFhkl7afVAihUy8yFi0KTCuiW86KdTkFAsPrZo2iFnt3OSlCOCr4NjOpP0= > ca.sslserver.nickname=Server-Cert cert-pki-ca > ca.sslserver.tokenname=Internal Key Storage Token > ca.subsystem.cert=MIIDizCCAnOgAwIBAgIBBDANBgkqhkiG9w0BAQsFADA8MRowGAYDVQQKDBFMSU5VWC5JTkZSQS5MT0NBTDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE1MDQxNDExNTM1NVoXDTE3MDQwMzExNTM1NVowMzEaMBgGA1UECgwRTElOVVguSU5GUkEuTE9DQUwxFTATBgNVBAMMDENBIFN1YnN5c3RlbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwOK1ztTX2M8Inf3Or1KGVwK5qHfh40e9raijd1loSGrtFUi4bkA3Gex1F+EqHpSSOnHBihlAD+cu17k8gvyXbJmiepxcdmpq8XuJXg37L+yUVrZqLkAV8dO8gcDkmJfWhGAVcMS7qFAjS2X4+6bWiKusRCtfnV8FRbw8R4bNGo7wiAsdsvZ6y6FzvGvHqQJQYtx56DslxTdHqxUdiM6aNUi6L3KfNL5VBSf7KgFNWvkVjJPzdeBVcpT5vFDhFYQVS5y0KqfnWKx18LAjxhVXOzy0Ge/El0zYhkA619BloQXrz20VTQrfQ5jK235ds0yGpK3lt5GfD0Pbgi9hD/D2MCAwEAAaOBoDCBnTAfBgNVHSMEGDAWgBRl7HKZBcKV9Qb43uEi0wAGhRItizBLBggrBgEFBQcBAQQ/MD0wOwYIKwYBBQUHMAGGL2h0dHA6Ly9wdmxpcGExMDAxYy5saW51eC5pbmZyYS5sb2NhbDo4MC9jYS9vY3NwMA4GA1UdDwEB/wQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggEBAGy4GR+cJorC7XtT+9UiU7cJ/aF6T8iBSsanLQKZS27NL769yOP61MgXA0ZEjRxZBMBEPvGPw01XsOk+ejjTximrERKVqBYqDO9d/U2DJQtdgEmqgX5yaixwjj8N3eDqma+ekV9L90hlfz1Plas8LndtvqILOC+lsL/nec162xzbUUv21ptLQr/aMB8NyjCRxTsB81oN73FWNmgB4hcr7CmnIq2WFcazeO5Eu0As5XGMfIWtzehRX5dKR1xSbDYo/wcUzYFmXlXFhaDqhInowHoTurskc4iCMN0gwrvsECYpdPdoL5IhsHk+dkxCpqSH4Xv+ga4k2S/Elmqo4OdiZOA= > ca.subsystem.certreq=MIICeDCCAWACAQAwMzEaMBgGA1UECgwRTElOVVguSU5GUkEuTE9DQUwxFTATBgNVBAMMDENBIFN1YnN5c3RlbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwOK1ztTX2M8Inf3Or1KGVwK5qHfh40e9raijd1loSGrtFUi4bkA3Gex1F+EqHpSSOnHBihlAD+cu17k8gvyXbJmiepxcdmpq8XuJXg37L+yUVrZqLkAV8dO8gcDkmJfWhGAVcMS7qFAjS2X4+6bWiKusRCtfnV8FRbw8R4bNGo7wiAsdsvZ6y6FzvGvHqQJQYtx56DslxTdHqxUdiM6aNUi6L3KfNL5VBSf7KgFNWvkVjJPzdeBVcpT5vFDhFYQVS5y0KqfnWKx18LAjxhVXOzy0Ge/El0zYhkA619BloQXrz20VTQrfQ5jK235ds0yGpK3lt5GfD0Pbgi9hD/D2MCAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQCU5X7i4/apRvKJZ8r2j3P39MCDVyMQvPstWTmYF53Lv49uKbyW/At5oqpgO35DCqIkW9Ydsdr+MhzAUj58mXTk05GJBNFTr5/C+yPAgxnZBQxvkAIxqKdSvZbyMMQ71lX3G62YJzY8lRmIBdxsQRhXnk5HfqSE5zthlzhwy/GhXguAQsLTc0y4rJFFxSUBYsAQC7YHZaJB5dU984/Odw2ZwgtXLZbH2BXbKfY22h2xwjLiJaDQMBGYE/NQYB8Pqo58elm5E6Mm8U/gH6LSiykDHOdvsFC9wsKfIy3sfHtd/POkJ58rh2gaZV7Y9+qEF0hsJNKoBKJYdpC1hAl/2fMN > ca.subsystem.nickname=subsystemCert cert-pki-ca > ca.subsystem.tokenname=Internal Key Storage Token > ca.transitMaxRecords=1000000 > ca.transitRecordPageSize=200 > cloning.audit_signing.dn=cn=CA Audit,O=LINUX.INFRA.LOCAL > cloning.audit_signing.keyalgorithm=SHA256withRSA > cloning.audit_signing.keytype=rsa > cloning.audit_signing.nickname=auditSigningCert cert-pki-ca > cloning.audit_signing.privkey.id=7eb573e78696f55ee7238dfcaf4f61075ce62a95 > cloning.audit_signing.pubkey.encoded= > cloning.audit_signing.pubkey.exponent=10001 > cloning.audit_signing.pubkey.modulus=f395389bc1a6e470ad6942543f8bf773b13d466af5a1ff9a0f9b0a26ab662a4aedc5527362bfe9cbd652cf48bc9d92d7371d9c1c80c73164f0f475c111483ac9a8e26132b61e91e2497da77755ab8396c098759deeb78dfab04c132145aa68f139d9ee78924dc15fca5536c9c9b32ddd6fc45cb2599034abf36af9436d67273450afc8507c00b0a08083364cb3a83bfe66ecf71ab10851ddadeaa5b4138527441c92e77d48853c7a4edc4b255aecb9e1ccee095c07c2108144730a2ad57b03ab94abf6d9ac11d06b4b5ca7c92069d5418267651b07aa84c3e6a0fdf5e7505e8ca8927b003d65011ee8dba6666c3c9297247b7f77afdaaace701fe4878976c1cd > cloning.list=signing,ocsp_signing,sslserver,subsystem,audit_signing > cloning.module.token=Internal Key Storage Token > cloning.ocsp_signing.dn=cn=OCSP Subsystem,O=LINUX.INFRA.LOCAL > cloning.ocsp_signing.keyalgorithm=SHA256withRSA > cloning.ocsp_signing.keytype=rsa > cloning.ocsp_signing.nickname=ocspSigningCert cert-pki-ca > cloning.ocsp_signing.privkey.id=-18f290f3a3da4d8310f60b063df7732722a55d00 > cloning.ocsp_signing.pubkey.encoded= > cloning.ocsp_signing.pubkey.exponent=10001 > cloning.ocsp_signing.pubkey.modulus=cded00ed795045d0d54487dbc686563638b4395ee7622f29c3e2e6edcbc1103d832c836639394d85c22d5d326b7a4e8655088919d21253fe3aee82d891ec0858e4e7431784848fb1914f04876426246c6930adcb1f750bb03d7708feebe8aa67ade9d28b027d423ad82e04d44a2b6cd2cc194fed55e90a2dcb4e6ec952cc14f361e6732384c23687d6c96d8067cc699655995d80d7ebe567d69da3057fa83cfa91de49ea3308989806dc3b8e95c1cac262e2b6cc301e14b72825ade5c112a05d1228a8da727ed4a9b22266067b22638e00a8ccdba8ef290b241dede84a84ae8232fa5e370cc984e1cc6badef3986292008d3bdad6c3dd5cbb55e40b8645d2197 > cloning.signing.dn=cn=Certificate Authority,O=LINUX.INFRA.LOCAL > cloning.signing.keyalgorithm=SHA256withRSA > cloning.signing.keytype=rsa > cloning.signing.nickname=caSigningCert cert-pki-ca > cloning.signing.privkey.id=76205073d25285bf3c60068f0ad56cb8fae5343a > cloning.signing.pubkey.encoded= > cloning.signing.pubkey.exponent=10001 > cloning.signing.pubkey.modulus=bf9578a55db51a8cd4da1d8e9ee1aeb2eca13d634aa128d4511eec5acb5c1bff9eb9cc5c9c1447d49b8af848ad01477f5d4c0f6847cc55732aae2bb68b254f9b1bf08a23026771b1cc7659e1c034497ac9d58ac82b16b2febfd67d7f604641aca5e931f64592ba76f3abd3934cb62f849271e6ed45cf337e91c14b6ac0fe01f1b8eb86b7244b44dc49486c1d89c7438013c94a426e5e9646ac868d2ce7232f6d90ef06ff6bc1dcb95f43c717c40c66e43543cbc7f7539110667f9a599c0caeecc60c27d419682bf118b93a1c43fef8f06204cc4c7058142eb4b452b4bb397bc75edc2703c2cf9e5c19a9afe2e783157e9439288cc2a0518303d6224b0b0d0587 > cloning.subsystem.dn=cn=CA Subsystem,O=LINUX.INFRA.LOCAL > cloning.subsystem.keyalgorithm=SHA256withRSA > cloning.subsystem.keytype=rsa > cloning.subsystem.nickname=subsystemCert cert-pki-ca > cloning.subsystem.privkey.id=2abd0a72de1599cc3c68f0191ba6dabb49b1ed3 > cloning.subsystem.pubkey.encoded= > cloning.subsystem.pubkey.exponent=10001 > cloning.subsystem.pubkey.modulus=cc0e2b5ced4d7d8cf089dfdceaf52865702b9a877e1e347bdada8a3775968486aed1548b86e403719ec7517e12a1e94923a71c18a19400fe72ed7b93c82fc976c99a27a9c5c766a6af17b895e0dfb2fec9456b66a2e4015f1d3bc81c0e49897d684601570c4bba850234b65f8fba6d688abac442b5f9d5f0545bc3c4786cd1a8ef0880b1db2f67acba173bc6bc7a9025062dc79e83b25c53747ab151d88ce9a3548ba2f729f34be550527fb2a014d5af9158c93f375e0557294f9bc50e11584154b9cb42aa7e758ac75f0b023c615573b3cb419efc4974cd886403ad7d065a105ebcf6d154d0adf4398cadb7e5db34c86a4ade5b7919f0f43db822f610ff0f63 > cmc.cert.confirmRequired=false > cmc.lraPopWitness.verify.allow=true > cmc.revokeCert.sharedSecret.class=com.netscape.cms.authentication.SharedSecret > cmc.revokeCert.verify=true > cmc.sharedSecret.class=com.netscape.cms.authentication.SharedSecret > cms.password.ignore.publishing.failure=true > cms.passwordlist=internaldb,replicationdb > cms.product.version=10.2.5 > cms.version=10.1 > cmsgateway._000=## > cmsgateway._001=## In the event that all Admin Certificates have been lost > cmsgateway._002=## for a given instance, perform the following steps to > cmsgateway._003=## re-enroll for a new Admin Certificate: > cmsgateway._004=## > cmsgateway._005=## (1) Become 'root' > cmsgateway._006=## (2) Type: 'service pki-tomcat stop' > cmsgateway._007=## (3) Edit '/etc/pki/pki-tomcat/ca/CS.cfg' > cmsgateway._008=## and set the following name-value pairs (if necessary): > cmsgateway._009=## > cmsgateway._010=## ca.Policy.enable=true > cmsgateway._011=## cmsgateway.enableAdminEnroll=true > cmsgateway._012=## > cmsgateway._013=## (4) Type: 'service pki-tomcat start' > cmsgateway._014=## (5) Launch a browser and re-enroll for > cmsgateway._015=## a new Admin Certificate by typing: > cmsgateway._016=## > cmsgateway._017=## https://pvlipa1001c.linux.infra.local:8443/ca/admin/ca/adminEnroll.html > cmsgateway._018=## > cmsgateway._019=## (6) Verify that the browser contains the new > cmsgateway._020=## Admin Certificate by successfully navigating to: > cmsgateway._021=## > cmsgateway._022=## https://pvlipa1001c.linux.infra.local:8443/ca/agent/ca/ > cmsgateway._023=## > cmsgateway._024=## (7) Optionally, disable the Certificate Policies Framework > cmsgateway._025=## by following steps (1) - (4), but ONLY resetting > cmsgateway._026=## 'ca.Policy.enable=false', as > cmsgateway._027=## 'cmsgateway.enableAdminEnroll=false' should have > cmsgateway._028=## already been reset. > cmsgateway._029=## > cmsgateway.enableAdminEnroll=false > configurationRoot=/ca/conf/ > cs.state=1 > cs.state._000=## > cs.state._001=## cs.state=0 (pre-operational) > cs.state._002=## cs.state=1 (running) > cs.state._003=## > cs.type=CA > dbs.beginReplicaNumber=1096 > dbs.beginRequestNumber=19990001 > dbs.beginSerialNumber=1fff0001 > dbs.enableRandomSerialNumbers=false > dbs.enableSerialManagement=true > dbs.endReplicaNumber=1099 > dbs.endRequestNumber=20000000 > dbs.endSerialNumber=20000000 > dbs.ldap=internaldb > dbs.newSchemaEntryAdded=true > dbs.nextBeginRequestNumber=40000001 > dbs.nextBeginSerialNumber=40000001 > dbs.nextEndRequestNumber=50000000 > dbs.nextEndSerialNumber=50000000 > dbs.randomSerialNumberCounter=-1 > dbs.replicaCloneTransferNumber=5 > dbs.replicaDN=ou=replica > dbs.replicaIncrement=100 > dbs.replicaLowWaterMark=20 > dbs.replicaRangeDN=ou=replica, ou=ranges > dbs.requestCloneTransferNumber=10000 > dbs.requestDN=ou=ca, ou=requests > dbs.requestIncrement=10000000 > dbs.requestLowWaterMark=2000000 > dbs.requestRangeDN=ou=requests, ou=ranges > dbs.serialCloneTransferNumber=10000 > dbs.serialDN=ou=certificateRepository, ou=ca > dbs.serialIncrement=10000000 > dbs.serialLowWaterMark=2000000 > dbs.serialRangeDN=ou=certificateRepository, ou=ranges > debug.append=true > debug.enabled=true > debug.filename=/var/lib/pki/pki-tomcat/logs/ca/debug > debug.hashkeytypes= > debug.level=0 > debug.showcaller=false > ee.interface.uri=ca/ee/ca > http.port=8080 > https.port=8443 > installDate=Wed Aug 12 10:19:32 2015 > instanceId=pki-tomcat > instanceRoot=/var/lib/pki/pki-tomcat > internaldb._000=## > internaldb._001=## Internal Database > internaldb._002=## > internaldb.basedn=o=ipaca > internaldb.database=ipaca > internaldb.ldapauth.authtype=SslClientAuth > internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipa-ca > internaldb.ldapauth.bindPWPrompt=internaldb > internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca > internaldb.ldapconn.cloneReplicationPort=389 > internaldb.ldapconn.host=pvlipa1001c.linux.infra.local > internaldb.ldapconn.masterReplicationPort=389 > internaldb.ldapconn.port=636 > internaldb.ldapconn.replicationSecurity=TLS > internaldb.ldapconn.secureConn=true > internaldb.maxConns=15 > internaldb.minConns=3 > internaldb.multipleSuffix.enable=false > internaldb.replication.consumer=cloneAgreement1-pvlipa1001c.linux.infra.local-pki-tomcat > internaldb.replication.master=masterAgreement1-pvlipa1001c.linux.infra.local-pki-tomcat > jobsScheduler._000=## > jobsScheduler._001=## jobScheduler > jobsScheduler._002=## > jobsScheduler.enabled=false > jobsScheduler.impl.PublishCertsJob.class=com.netscape.cms.jobs.PublishCertsJob > jobsScheduler.impl.RenewalNotificationJob.class=com.netscape.cms.jobs.RenewalNotificationJob > jobsScheduler.impl.RequestInQueueJob.class=com.netscape.cms.jobs.RequestInQueueJob > jobsScheduler.impl.UnpublishExpiredJob.class=com.netscape.cms.jobs.UnpublishExpiredJob > jobsScheduler.interval=1 > jobsScheduler.job.certRenewalNotifier.cron=0 3 * * 1-5 > jobsScheduler.job.certRenewalNotifier.emailSubject=Certificate Renewal Notification > jobsScheduler.job.certRenewalNotifier.emailTemplate=/var/lib/pki/pki-tomcat/ca/emails/rnJob1.txt > jobsScheduler.job.certRenewalNotifier.enabled=false > jobsScheduler.job.certRenewalNotifier.notifyEndOffset=30 > jobsScheduler.job.certRenewalNotifier.notifyTriggerOffset=30 > jobsScheduler.job.certRenewalNotifier.pluginName=RenewalNotificationJob > jobsScheduler.job.certRenewalNotifier.senderEmail= > jobsScheduler.job.certRenewalNotifier.summary.emailSubject=Certificate Renewal Notification Summary > jobsScheduler.job.certRenewalNotifier.summary.emailTemplate=/var/lib/pki/pki-tomcat/ca/emails/rnJob1Summary.txt > jobsScheduler.job.certRenewalNotifier.summary.enabled=true > jobsScheduler.job.certRenewalNotifier.summary.itemTemplate=/var/lib/pki/pki-tomcat/ca/emails/rnJob1Item.txt > jobsScheduler.job.certRenewalNotifier.summary.recipientEmail= > jobsScheduler.job.certRenewalNotifier.summary.senderEmail= > jobsScheduler.job.publishCerts.cron=0 0 * * 2 > jobsScheduler.job.publishCerts.enabled=false > jobsScheduler.job.publishCerts.pluginName=PublishCertsJob > jobsScheduler.job.publishCerts.summary.emailSubject=Certs Publishing Summary > jobsScheduler.job.publishCerts.summary.emailTemplate=/var/lib/pki/pki-tomcat/ca/emails/publishCerts.html > jobsScheduler.job.publishCerts.summary.enabled=true > jobsScheduler.job.publishCerts.summary.itemTemplate=/var/lib/pki/pki-tomcat/ca/emails/publishCertsItem.html > jobsScheduler.job.publishCerts.summary.recipientEmail= > jobsScheduler.job.publishCerts.summary.senderEmail= > jobsScheduler.job.requestInQueueNotifier.cron=0 0 * * 0 > jobsScheduler.job.requestInQueueNotifier.enabled=false > jobsScheduler.job.requestInQueueNotifier.pluginName=RequestInQueueJob > jobsScheduler.job.requestInQueueNotifier.subsystemId=ca > jobsScheduler.job.requestInQueueNotifier.summary.emailSubject=Requests in Queue Summary Report > jobsScheduler.job.requestInQueueNotifier.summary.emailTemplate=/var/lib/pki/pki-tomcat/ca/emails/riq1Summary.html > jobsScheduler.job.requestInQueueNotifier.summary.enabled=true > jobsScheduler.job.requestInQueueNotifier.summary.recipientEmail= > jobsScheduler.job.requestInQueueNotifier.summary.senderEmail= > jobsScheduler.job.unpublishExpiredCerts.cron=0 0 * * 6 > jobsScheduler.job.unpublishExpiredCerts.enabled=false > jobsScheduler.job.unpublishExpiredCerts.pluginName=UnpublishExpiredJob > jobsScheduler.job.unpublishExpiredCerts.summary.emailSubject=Expired Certs Unpublished Summary > jobsScheduler.job.unpublishExpiredCerts.summary.emailTemplate=/var/lib/pki/pki-tomcat/ca/emails/euJob1.html > jobsScheduler.job.unpublishExpiredCerts.summary.enabled=true > jobsScheduler.job.unpublishExpiredCerts.summary.itemTemplate=/var/lib/pki/pki-tomcat/ca/emails/euJob1Item.html > jobsScheduler.job.unpublishExpiredCerts.summary.recipientEmail= > jobsScheduler.job.unpublishExpiredCerts.summary.senderEmail= > jss._000=## > jss._001=## JSS > jss._002=## > jss.configDir=/var/lib/pki/pki-tomcat/alias/ > jss.enable=true > jss.ocspcheck.enable=false > jss.secmodName=secmod.db > jss.ssl.cipherfortezza=true > jss.ssl.cipherpref= > jss.ssl.cipherversion=cipherdomestic > jss.ssl.sslserver.ectype=ECDHE > keys.ecc.curve.default=nistp256 > keys.ecc.curve.display.list=nistp256 (secp256r1),nistp384 (secp384r1),nistp521 (secp521r1),nistk163 (sect163k1),sect163r1,nistb163 (sect163r2),sect193r1,sect193r2,nistk233 (sect233k1),nistb233 (sect233r1),sect239k1,nistk283 (sect283k1),nistb283 (sect283r1),nistk409 (sect409k1),nistb409 (sect409r1),nistk571 (sect571k1),nistb571 (sect571r1),secp160k1,secp160r1,secp160r2,secp192k1,nistp192 (secp192r1, prime192v1),secp224k1,nistp224 (secp224r1),secp256k1,prime192v2,prime192v3,prime239v1,prime239v2,prime239v3,c2pnb163v1,c2pnb163v2,c2pnb163v3,c2pnb176v1,c2tnb191v1,c2tnb191v2,c2tnb191v3,c2pnb208w1,c2tnb239v1,c2tnb239v2,c2tnb239v3,c2pnb272w1,c2pnb304w1,c2tnb359w1,c2pnb368w1,c2tnb431r1,secp112r1,secp112r2,secp128r1,secp128r2,sect113r1,sect113r2,sect131r1,sect131r2 > keys.ecc.curve.list=nistp256,nistp384,nistp521,sect163k1,nistk163,sect163r1,sect163r2,nistb163,sect193r1,sect193r2,sect233k1,nistk233,sect233r1,nistb233,sect239k1,sect283k1,nistk283,sect283r1,nistb283,sect409k1,nistk409,sect409r1,nistb409,sect571k1,nistk571,sect571r1,nistb571,secp160k1,secp160r1,secp160r2,secp192k1,secp192r1,nistp192,secp224k1,secp224r1,nistp224,secp256k1,secp256r1,secp384r1,secp521r1,prime192v1,prime192v2,prime192v3,prime239v1,prime239v2,prime239v3,c2pnb163v1,c2pnb163v2,c2pnb163v3,c2pnb176v1,c2tnb191v1,c2tnb191v2,c2tnb191v3,c2pnb208w1,c2tnb239v1,c2tnb239v2,c2tnb239v3,c2pnb272w1,c2pnb304w1,c2tnb359w1,c2pnb368w1,c2tnb431r1,secp112r1,secp112r2,secp128r1,secp128r2,sect113r1,sect113r2,sect131r1,sect131r2 > keys.rsa.keysize.default=2048 > log._000=## > log._001=## Logging > log._002=## > log.impl.file.class=com.netscape.cms.logging.RollingLogFile > log.instance.SignedAudit._000=## > log.instance.SignedAudit._001=## Signed Audit Logging > log.instance.SignedAudit._002=## > log.instance.SignedAudit._003=## > log.instance.SignedAudit._004=## Available Audit events: > log.instance.SignedAudit._005=## AUDIT_LOG_STARTUP,AUDIT_LOG_SHUTDOWN,ROLE_ASSUME,CONFIG_CERT_POLICY,CONFIG_CERT_PROFILE,CONFIG_CRL_PROFILE,CONFIG_OCSP_PROFILE,CONFIG_AUTH,CONFIG_ROLE,CONFIG_ACL,CONFIG_SIGNED_AUDIT,CONFIG_ENCRYPTION,CONFIG_TRUSTED_PUBLIC_KEY,CONFIG_DRM,SELFTESTS_EXECUTION,AUDIT_LOG_DELETE,LOG_PATH_CHANGE,LOG_EXPIRATION_CHANGE,PRIVATE_KEY_ARCHIVE_REQUEST,PRIVATE_KEY_ARCHIVE_REQUEST_PROCESSED,PRIVATE_KEY_EXPORT_REQUEST_PROCESSED_SUCCESS,PRIVATE_KEY_EXPORT_REQUEST_PROCESSED_FAILURE,KEY_RECOVERY_REQUEST,KEY_RECOVERY_REQUEST_ASYNC,KEY_RECOVERY_AGENT_LOGIN,KEY_RECOVERY_REQUEST_PROCESSED,KEY_RECOVERY_REQUEST_PROCESSED_ASYNC,KEY_GEN_ASYMMETRIC,NON_PROFILE_CERT_REQUEST,PROFILE_CERT_REQUEST,CERT_REQUEST_PROCESSED,CERT_STATUS_CHANGE_REQUEST,CERT_STATUS_CHANGE_REQUEST_PROCESSED,AUTHZ_SUCCESS,AUTHZ_FAIL,INTER_BOUNDARY,AUTH_FAIL,AUTH_SUCCESS,CERT_PROFILE_APPROVAL,PROOF_OF_POSSESSION,CRL_RETRIEVAL,CRL_VALIDATION,CMC_SIGNED_REQUEST_SIG_VERIFY,SERVER_SIDE_KEYGEN_REQUEST_PROCESSED_FAILURE,SERVER_SIDE_KEYGEN_REQUEST_PROCESSED_SUCCESS,SERVER_SIDE_KEYGEN_REQUEST,COMPUTE_SESSION_KEY_REQUEST,COMPUTE_SESSION_KEY_REQUEST_PROCESSED_SUCCESS, COMPUTE_SESSION_KEY_REQUEST_PROCESSED_FAILURE,DIVERSIFY_KEY_REQUEST,DIVERSIFY_KEY_REQUEST_PROCESSED_SUCCESS, DIVERSIFY_KEY_REQUEST_PROCESSED_FAILURE,ENCRYPT_DATA_REQUEST,ENCRYPT_DATA_REQUEST_PROCESSED_SUCCESS,ENCRYPT_DATA_REQUEST_PROCESSED_FAILURE,OCSP_ADD_CA_REQUEST,OCSP_ADD_CA_REQUEST_PROCESSED,OCSP_REMOVE_CA_REQUEST,OCSP_REMOVE_CA_REQUEST_PROCESSED_SUCCESS,OCSP_REMOVE_CA_REQUEST_PROCESSED_FAILURE,COMPUTE_RANDOM_DATA_REQUEST,COMPUTE_RANDOM_DATA_REQUEST_PROCESSED_SUCCESS,COMPUTE_RANDOM_DATA_REQUEST_PROCESSED_FAILURE,CIMC_CERT_VERIFICATION,SECURITY_DOMAIN_UPDATE,CONFIG_SERIAL_NUMBER > log.instance.SignedAudit._006=## > log.instance.SignedAudit.bufferSize=512 > log.instance.SignedAudit.enable=true > log.instance.SignedAudit.events=AUDIT_LOG_STARTUP,AUDIT_LOG_SHUTDOWN,ROLE_ASSUME,CONFIG_CERT_POLICY,CONFIG_CERT_PROFILE,CONFIG_CRL_PROFILE,CONFIG_OCSP_PROFILE,CONFIG_AUTH,CONFIG_ROLE,CONFIG_ACL,CONFIG_SIGNED_AUDIT,CONFIG_ENCRYPTION,CONFIG_TRUSTED_PUBLIC_KEY,CONFIG_DRM,SELFTESTS_EXECUTION,AUDIT_LOG_DELETE,LOG_PATH_CHANGE,PRIVATE_KEY_ARCHIVE_REQUEST,PRIVATE_KEY_ARCHIVE_REQUEST_PROCESSED,PRIVATE_KEY_EXPORT_REQUEST_PROCESSED_SUCCESS,PRIVATE_KEY_EXPORT_REQUEST_PROCESSED_FAILURE,KEY_RECOVERY_REQUEST,KEY_RECOVERY_REQUEST_ASYNC,KEY_RECOVERY_AGENT_LOGIN,KEY_RECOVERY_REQUEST_PROCESSED,KEY_RECOVERY_REQUEST_PROCESSED_ASYNC,KEY_GEN_ASYMMETRIC,NON_PROFILE_CERT_REQUEST,PROFILE_CERT_REQUEST,CERT_REQUEST_PROCESSED,CERT_STATUS_CHANGE_REQUEST,CERT_STATUS_CHANGE_REQUEST_PROCESSED,AUTHZ_SUCCESS,AUTHZ_FAIL,INTER_BOUNDARY,AUTH_FAIL,AUTH_SUCCESS,CERT_PROFILE_APPROVAL,PROOF_OF_POSSESSION,CRL_RETRIEVAL,CRL_VALIDATION,CMC_SIGNED_REQUEST_SIG_VERIFY,SERVER_SIDE_KEYGEN_REQUEST_PROCESSED_FAILURE,SERVER_SIDE_KEYGEN_REQUEST_PROCESSED_SUCCESS,SERVER_SIDE_KEYGEN_REQUEST,COMPUTE_SESSION_KEY_REQUEST,COMPUTE_SESSION_KEY_REQUEST_PROCESSED_SUCCESS, COMPUTE_SESSION_KEY_REQUEST_PROCESSED_FAILURE,DIVERSIFY_KEY_REQUEST,DIVERSIFY_KEY_REQUEST_PROCESSED_SUCCESS, DIVERSIFY_KEY_REQUEST_PROCESSED_FAILURE,ENCRYPT_DATA_REQUEST,ENCRYPT_DATA_REQUEST_PROCESSED_SUCCESS,ENCRYPT_DATA_REQUEST_PROCESSED_FAILURE,OCSP_ADD_CA_REQUEST,OCSP_ADD_CA_REQUEST_PROCESSED,OCSP_REMOVE_CA_REQUEST,OCSP_REMOVE_CA_REQUEST_PROCESSED_SUCCESS,OCSP_REMOVE_CA_REQUEST_PROCESSED_FAILURE,COMPUTE_RANDOM_DATA_REQUEST,COMPUTE_RANDOM_DATA_REQUEST_PROCESSED_SUCCESS,COMPUTE_RANDOM_DATA_REQUEST_PROCESSED_FAILURE,CIMC_CERT_VERIFICATION,SECURITY_DOMAIN_UPDATE,CONFIG_SERIAL_NUMBER > log.instance.SignedAudit.expirationTime=0 > log.instance.SignedAudit.fileName=/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit > log.instance.SignedAudit.flushInterval=5 > log.instance.SignedAudit.level=1 > log.instance.SignedAudit.logSigning=false > log.instance.SignedAudit.maxFileSize=2000 > log.instance.SignedAudit.pluginName=file > log.instance.SignedAudit.rolloverInterval=2592000 > log.instance.SignedAudit.signedAudit=_002=## > log.instance.SignedAudit.signedAuditCertNickname=auditSigningCert cert-pki-ca > log.instance.SignedAudit.type=signedAudit > log.instance.System._000=## > log.instance.System._001=## System Logging > log.instance.System._002=## > log.instance.System.bufferSize=512 > log.instance.System.enable=true > log.instance.System.expirationTime=0 > log.instance.System.fileName=/var/lib/pki/pki-tomcat/logs/ca/system > log.instance.System.flushInterval=5 > log.instance.System.level=3 > log.instance.System.maxFileSize=2000 > log.instance.System.pluginName=file > log.instance.System.rolloverInterval=2592000 > log.instance.System.type=system > log.instance.Transactions._000=## > log.instance.Transactions._001=## Transaction Logging > log.instance.Transactions._002=## > log.instance.Transactions.bufferSize=512 > log.instance.Transactions.enable=true > log.instance.Transactions.expirationTime=0 > log.instance.Transactions.fileName=/var/lib/pki/pki-tomcat/logs/ca/transactions > log.instance.Transactions.flushInterval=5 > log.instance.Transactions.level=1 > log.instance.Transactions.maxFileSize=2000 > log.instance.Transactions.pluginName=file > log.instance.Transactions.rolloverInterval=2592000 > log.instance.Transactions.type=transaction > logAudit.fileName=/var/lib/pki/pki-tomcat/logs/ca/access > logError.fileName=/var/lib/pki/pki-tomcat/logs/ca/error > machineName=pvlipa1001c.linux.infra.local > multiroles._000=## > multiroles._001=## multiroles > multiroles._002=## > multiroles.enable=true > multiroles.false.groupEnforceList=Administrators,Auditors,Trusted Managers,Certificate Manager Agents,Registration Manager Agents,Data Recovery Manager Agents,Online Certificate Status Manager Agents,Token Key Service Manager Agents,Enterprise CA Administrators,Enterprise KRA Administrators,Enterprise OCSP Administrators,Enterprise RA Administrators,Enterprise TKS Administrators,Enterprise TPS Administrators,Security Domain Administrators,Subsystem Group,ClonedSubsystems > oidmap.auth_info_access.class=netscape.security.extensions.AuthInfoAccessExtension > oidmap.auth_info_access.oid=1.3.6.1.5.5.7.1.1 > oidmap.challenge_password.class=com.netscape.cms.servlet.cert.scep.ChallengePassword > oidmap.challenge_password.oid=1.2.840.113549.1.9.7 > oidmap.extended_key_usage.class=netscape.security.extensions.ExtendedKeyUsageExtension > oidmap.extended_key_usage.oid=2.5.29.37 > oidmap.extensions_requested_pkcs9.class=com.netscape.cms.servlet.cert.scep.ExtensionsRequested > oidmap.extensions_requested_pkcs9.oid=1.2.840.113549.1.9.14 > oidmap.extensions_requested_vsgn.class=com.netscape.cms.servlet.cert.scep.ExtensionsRequested > oidmap.extensions_requested_vsgn.oid=2.16.840.1.113733.1.9.8 > oidmap.netscape_comment.class=netscape.security.x509.NSCCommentExtension > oidmap.netscape_comment.oid=2.16.840.1.113730.1.13 > oidmap.ocsp_no_check.class=netscape.security.extensions.OCSPNoCheckExtension > oidmap.ocsp_no_check.oid=1.3.6.1.5.5.7.48.1.5 > oidmap.pse.class=netscape.security.extensions.PresenceServerExtension > oidmap.pse.oid=2.16.840.1.113730.1.18 > oidmap.subject_info_access.class=netscape.security.extensions.SubjectInfoAccessExtension > oidmap.subject_info_access.oid=1.3.6.1.5.5.7.1.11 > os.userid=nobody > passwordClass=com.netscape.cmsutil.password.PlainPasswordFile > passwordFile=/var/lib/pki/pki-tomcat/conf/password.conf > pidDir=/var/run/pki/tomcat > pkicreate.admin_secure_port=8443 > pkicreate.agent_secure_port=8443 > pkicreate.arg11.group=pkiuser > pkicreate.ee_secure_client_auth_port=8443 > pkicreate.ee_secure_port=8443 > pkicreate.pki_instance_name=pki-tomcat > pkicreate.pki_instance_root=/var/lib/pki > pkicreate.secure_port=8443 > pkicreate.subsystem_type=ca > pkicreate.systemd.servicename=pki-tomcatd at pki-tomcat.service > pkicreate.tomcat_server_port=8005 > pkicreate.unsecure_port=8080 > pkicreate.user=pkiuser > pkiremove.cert.subsystem.nickname=subsystemCert cert-pki-tomcat > processor.caDoRevoke-agent.authMgr=certUserDBAuthMgr > processor.caDoRevoke-agent.authorityId=ca > processor.caDoRevoke-agent.authzMgr=BasicAclAuthz > processor.caDoRevoke-agent.authzResourceName=certServer.ca.certificates > processor.caDoRevoke-agent.getClientCert=true > processor.caDoRevoke.authorityId=ca > processor.caDoRevoke.authzMgr=BasicAclAuthz > processor.caDoRevoke.authzResourceName=certServer.ee.certificates > processor.caDoRevoke.getClientCert=false > processor.caDoUnrevoke.authMgr=certUserDBAuthMgr > processor.caDoUnrevoke.authorityId=ca > processor.caDoUnrevoke.authzMgr=BasicAclAuthz > processor.caDoUnrevoke.authzResourceName=certServer.ca.certificate > processor.caDoUnrevoke.getClientCert=true > processor.caProfileProcess.authMgr=certUserDBAuthMgr > processor.caProfileProcess.authorityId=ca > processor.caProfileProcess.authzMgr=BasicAclAuthz > processor.caProfileProcess.authzResourceName=certServer.ca.request.profile > processor.caProfileProcess.getClientCert=true > processor.caProfileSubmit.authorityId=ca > processor.caProfileSubmit.authzMgr=BasicAclAuthz > processor.caProfileSubmit.authzResourceName=certServer.ee.profile > processor.caProfileSubmit.getClientCert=false > profile.AdminCert.class_id=caEnrollImpl > profile.AdminCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/AdminCert.cfg > profile.DomainController.class_id=caEnrollImpl > profile.DomainController.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/DomainController.cfg > profile.KPNWebhostingAEM.class_id=caEnrollImpl > profile.KPNWebhostingAEM.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/KPNWebhostingAEM.cfg > profile.KPNWebhostingServiceCertAEM.class_id=caEnrollImpl > profile.KPNWebhostingServiceCertAEM.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/KPNWebhostingServiceCertAEM.cfg > profile.caAdminCert.class_id=caEnrollImpl > profile.caAdminCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caAdminCert.cfg > profile.caAgentFileSigning.class_id=caEnrollImpl > profile.caAgentFileSigning.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caAgentFileSigning.cfg > profile.caAgentServerCert.class_id=caEnrollImpl > profile.caAgentServerCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caAgentServerCert.cfg > profile.caCACert.class_id=caEnrollImpl > profile.caCACert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caCACert.cfg > profile.caCMCUserCert.class_id=caEnrollImpl > profile.caCMCUserCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caCMCUserCert.cfg > profile.caCrossSignedCACert.class_id=caEnrollImpl > profile.caCrossSignedCACert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caCrossSignedCACert.cfg > profile.caDirPinUserCert.class_id=caEnrollImpl > profile.caDirPinUserCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caDirPinUserCert.cfg > profile.caDirUserCert.class_id=caEnrollImpl > profile.caDirUserCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caDirUserCert.cfg > profile.caDirUserRenewal.class_id=caEnrollImpl > profile.caDirUserRenewal.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caDirUserRenewal.cfg > profile.caDualCert.class_id=caEnrollImpl > profile.caDualCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caDualCert.cfg > profile.caDualRAuserCert.class_id=caEnrollImpl > profile.caDualRAuserCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caDualRAuserCert.cfg > profile.caECDirUserCert.class_id=caEnrollImpl > profile.caECDirUserCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caECDirUserCert.cfg > profile.caECDualCert.class_id=caEnrollImpl > profile.caECDualCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caECDualCert.cfg > profile.caECUserCert.class_id=caEnrollImpl > profile.caECUserCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caECUserCert.cfg > profile.caEncECUserCert.class_id=caEnrollImpl > profile.caEncECUserCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caEncECUserCert.cfg > profile.caEncUserCert.class_id=caEnrollImpl > profile.caEncUserCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caEncUserCert.cfg > profile.caFullCMCUserCert.class_id=caEnrollImpl > profile.caFullCMCUserCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caFullCMCUserCert.cfg > profile.caIPAserviceCert.class_id=caEnrollImpl > profile.caIPAserviceCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg > profile.caInstallCACert.class_id=caEnrollImpl > profile.caInstallCACert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caInstallCACert.cfg > profile.caInternalAuthAuditSigningCert.class_id=caEnrollImpl > profile.caInternalAuthAuditSigningCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caInternalAuthAuditSigningCert.cfg > profile.caInternalAuthDRMstorageCert.class_id=caEnrollImpl > profile.caInternalAuthDRMstorageCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caInternalAuthDRMstorageCert.cfg > profile.caInternalAuthOCSPCert.class_id=caEnrollImpl > profile.caInternalAuthOCSPCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caInternalAuthOCSPCert.cfg > profile.caInternalAuthServerCert.class_id=caEnrollImpl > profile.caInternalAuthServerCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caInternalAuthServerCert.cfg > profile.caInternalAuthSubsystemCert.class_id=caEnrollImpl > profile.caInternalAuthSubsystemCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caInternalAuthSubsystemCert.cfg > profile.caInternalAuthTransportCert.class_id=caEnrollImpl > profile.caInternalAuthTransportCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caInternalAuthTransportCert.cfg > profile.caJarSigningCert.class_id=caEnrollImpl > profile.caJarSigningCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caJarSigningCert.cfg > profile.caManualRenewal.class_id=caEnrollImpl > profile.caManualRenewal.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caManualRenewal.cfg > profile.caOCSPCert.class_id=caEnrollImpl > profile.caOCSPCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caOCSPCert.cfg > profile.caOtherCert.class_id=caEnrollImpl > profile.caOtherCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caOtherCert.cfg > profile.caRACert.class_id=caEnrollImpl > profile.caRACert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caRACert.cfg > profile.caRARouterCert.class_id=caEnrollImpl > profile.caRARouterCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caRARouterCert.cfg > profile.caRAagentCert.class_id=caEnrollImpl > profile.caRAagentCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caRAagentCert.cfg > profile.caRAserverCert.class_id=caEnrollImpl > profile.caRAserverCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caRAserverCert.cfg > profile.caRouterCert.class_id=caEnrollImpl > profile.caRouterCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caRouterCert.cfg > profile.caSSLClientSelfRenewal.class_id=caEnrollImpl > profile.caSSLClientSelfRenewal.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caSSLClientSelfRenewal.cfg > profile.caServerCert.class_id=caEnrollImpl > profile.caServerCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caServerCert.cfg > profile.caSignedLogCert.class_id=caEnrollImpl > profile.caSignedLogCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caSignedLogCert.cfg > profile.caSimpleCMCUserCert.class_id=caEnrollImpl > profile.caSimpleCMCUserCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caSimpleCMCUserCert.cfg > profile.caStorageCert.class_id=caEnrollImpl > profile.caStorageCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caStorageCert.cfg > profile.caSubsystemCert.class_id=caEnrollImpl > profile.caSubsystemCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caSubsystemCert.cfg > profile.caTPSCert.class_id=caEnrollImpl > profile.caTPSCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caTPSCert.cfg > profile.caTempTokenDeviceKeyEnrollment.class_id=caUserCertEnrollImpl > profile.caTempTokenDeviceKeyEnrollment.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caTempTokenDeviceKeyEnrollment.cfg > profile.caTempTokenUserEncryptionKeyEnrollment.class_id=caUserCertEnrollImpl > profile.caTempTokenUserEncryptionKeyEnrollment.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caTempTokenUserEncryptionKeyEnrollment.cfg > profile.caTempTokenUserSigningKeyEnrollment.class_id=caUserCertEnrollImpl > profile.caTempTokenUserSigningKeyEnrollment.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caTempTokenUserSigningKeyEnrollment.cfg > profile.caTokenDeviceKeyEnrollment.class_id=caUserCertEnrollImpl > profile.caTokenDeviceKeyEnrollment.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caTokenDeviceKeyEnrollment.cfg > profile.caTokenMSLoginEnrollment.class_id=caUserCertEnrollImpl > profile.caTokenMSLoginEnrollment.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caTokenMSLoginEnrollment.cfg > profile.caTokenUserEncryptionKeyEnrollment.class_id=caUserCertEnrollImpl > profile.caTokenUserEncryptionKeyEnrollment.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caTokenUserEncryptionKeyEnrollment.cfg > profile.caTokenUserEncryptionKeyRenewal.class_id=caUserCertEnrollImpl > profile.caTokenUserEncryptionKeyRenewal.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caTokenUserEncryptionKeyRenewal.cfg > profile.caTokenUserSigningKeyEnrollment.class_id=caUserCertEnrollImpl > profile.caTokenUserSigningKeyEnrollment.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caTokenUserSigningKeyEnrollment.cfg > profile.caTokenUserSigningKeyRenewal.class_id=caUserCertEnrollImpl > profile.caTokenUserSigningKeyRenewal.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caTokenUserSigningKeyRenewal.cfg > profile.caTransportCert.class_id=caEnrollImpl > profile.caTransportCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caTransportCert.cfg > profile.caUUIDdeviceCert.class_id=caEnrollImpl > profile.caUUIDdeviceCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caUUIDdeviceCert.cfg > profile.caUserCert.class_id=caEnrollImpl > profile.caUserCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caUserCert.cfg > profile.caUserSMIMEcapCert.class_id=caEnrollImpl > profile.caUserSMIMEcapCert.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caUserSMIMEcapCert.cfg > profile.list=caUserCert,caECUserCert,caUserSMIMEcapCert,caDualCert,caECDualCert,AdminCert,caSignedLogCert,caTPSCert,caRARouterCert,caRouterCert,caServerCert,caSubsystemCert,caOtherCert,caCACert,caCrossSignedCACert,caInstallCACert,caRACert,caOCSPCert,caStorageCert,caTransportCert,caDirPinUserCert,caDirUserCert,caECDirUserCert,caAgentServerCert,caAgentFileSigning,caCMCUserCert,caFullCMCUserCert,caSimpleCMCUserCert,caTokenDeviceKeyEnrollment,caTokenUserEncryptionKeyEnrollment,caTokenUserSigningKeyEnrollment,caTempTokenDeviceKeyEnrollment,caTempTokenUserEncryptionKeyEnrollment,caTempTokenUserSigningKeyEnrollment,caAdminCert,caInternalAuthServerCert,caInternalAuthTransportCert,caInternalAuthDRMstorageCert,caInternalAuthSubsystemCert,caInternalAuthOCSPCert,caInternalAuthAuditSigningCert,DomainController,caDualRAuserCert,caRAagentCert,caRAserverCert,caUUIDdeviceCert,caSSLClientSelfRenewal,caDirUserRenewal,caManualRenewal,caTokenMSLoginEnrollment,caTokenUserSigningKeyRenewal,caTokenUserEncryptionKeyRenewal,caJarSigningCert,caIPAserviceCert,caEncUserCert,caEncECUserCert,KPNWebhostingServiceCertAEM,KPNWebhostingAEM > proxy.securePort=443 > proxy.unsecurePort=80 > registry.file=/var/lib/pki/pki-tomcat/conf/ca/registry.cfg > request.assignee.enable=true > securitydomain.checkIP=false > securitydomain.checkinterval=300000 > securitydomain.flushinterval=86400000 > securitydomain.host=pvlipa1001c.linux.infra.local > securitydomain.httpport=80 > securitydomain.httpsadminport=443 > securitydomain.httpsagentport=443 > securitydomain.httpseeport=443 > securitydomain.name=IPA > securitydomain.select=new > securitydomain.source=ldap > securitydomain.store=ldap > selftests._000=## > selftests._001=## Self Tests > selftests._002=## > selftests._003=## The Self-Test plugin SystemCertsVerification uses the > selftests._004=## following parameters (where certusage is optional): > selftests._005=## ca.cert.list = > selftests._006=## ca.cert..nickname > selftests._007=## ca.cert..certusage > selftests._008=## > selftests.container.instance.CAPresence=com.netscape.cms.selftests.ca.CAPresence > selftests.container.instance.CAValidity=com.netscape.cms.selftests.ca.CAValidity > selftests.container.instance.SystemCertsVerification=com.netscape.cms.selftests.common.SystemCertsVerification > selftests.container.logger.bufferSize=512 > selftests.container.logger.class=com.netscape.cms.logging.RollingLogFile > selftests.container.logger.enable=true > selftests.container.logger.expirationTime=0 > selftests.container.logger.fileName=/var/lib/pki/pki-tomcat/logs/ca/selftests.log > selftests.container.logger.flushInterval=5 > selftests.container.logger.level=1 > selftests.container.logger.maxFileSize=2000 > selftests.container.logger.register=false > selftests.container.logger.rolloverInterval=2592000 > selftests.container.logger.type=transaction > selftests.container.order.onDemand=CAPresence:critical, SystemCertsVerification:critical, CAValidity:critical > selftests.container.order.startup=CAPresence:critical, SystemCertsVerification:critical > selftests.plugin.CAPresence.CaSubId=ca > selftests.plugin.CAValidity.CaSubId=ca > selftests.plugin.SystemCertsVerification.SubId=ca > service.clientauth_securePort=8443 > service.instanceDir=/var/lib/pki > service.instanceID=pki-tomcat > service.machineName=pvlipa1001c.linux.infra.local > service.non_clientauth_securePort=8443 > service.securePort=8443 > service.securityDomainPort=443 > service.unsecurePort=8080 > smtp.host=localhost > smtp.port=25 > subsystem.0.class=com.netscape.ca.CertificateAuthority > subsystem.0.id=ca > subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem > subsystem.1.id=profile > subsystem.2.class=com.netscape.cmscore.selftests.SelfTestSubsystem > subsystem.2.id=selftests > subsystem.3.class=com.netscape.cmscore.cert.CrossCertPairSubsystem > subsystem.3.id=CrossCertPair > subsystem.4.class=com.netscape.cmscore.util.StatsSubsystem > subsystem.4.id=stats > subsystem.count=0 > subsystem.select=Clone > usrgrp._000=## > usrgrp._001=## User/Group > usrgrp._002=## > usrgrp.ldap=internaldb > > -----Oorspronkelijk bericht----- > Van: Fraser Tweedale [mailto:ftweedal at redhat.com] > Verzonden: vrijdag 11 december 2015 08:14 > Aan: Hummelink, Wouter > Onderwerp: Re: [Freeipa-users] Certificate Profile - Policy Set Not Found > > Can you please check the version of your pki packages on the host on which the CA is running and also provide your /etc/pki/pki-tomcat/ca/CS.cfg ? > > To confirm, the IPA server and PKI host are RHEL 7.2? > > Cheers, > Fraser > > On Thu, Dec 10, 2015 at 07:32:13AM +0000, wouter.hummelink at kpn.com wrote: > > Attached are yesterdays debug log from pki-tomcat > > > > I tried these actions several times, both scripted and manually > > Curiously, I did a resubmit just now and I got issued a correct certificate. > > > > > > > > > > Van: freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] Namens > > wouter.hummelink at kpn.com > > Verzonden: donderdag 10 december 2015 08:05 > > Aan: ftweedal at redhat.com > > CC: freeipa-users at redhat.com > > Onderwerp: Re: [Freeipa-users] Certificate Profile - Policy Set Not > > Found > > > > I'll send the log as soon as I get a chance. After the mail I also > > tried fetching a cert on another server cent7.1 that never had a cert > > issued. This resulted in a cert conformant With caIpaServiceCert > > > > > > Verzonden vanaf mijn Samsung-apparaat > > > > > > -------- Oorspronkelijk bericht -------- > > Van: Fraser Tweedale > > > Datum: 2015-12-10 03:58 (GMT+01:00) > > Aan: "Hummelink, Wouter" > > > > > Cc: freeipa-users at redhat.com > > Onderwerp: Re: [Freeipa-users] Certificate Profile - Policy Set Not > > Found On Thu, Dec 10, 2015 at 09:48:35AM +1000, Fraser Tweedale wrote: > > > On Wed, Dec 09, 2015 at 10:46:06AM +0000, wouter.hummelink at kpn.com wrote: > > > > Hello, > > > > > > > > Im trying to import and use a certificate profile in IPAv4.2 on RHEL. > > > > > > > > I've exported the default caIPAServiceCert profile and did the following modification: > > > > < profileId=caIPAserviceCert > > > > --- > > > > > profileId=KPNWebhostingAEM > > > > 87c87 > > > > < > > > > policyset.serverCertSet.1.default.params.name=CN=$request.req_subj > > > > ect_name.cn$, O=IPADOMAIN > > > > --- > > > > > policyset.serverCertSet.1.default.params.name=CN=$request.req_su > > > > > bject_name.cn$, OU=TESTAEM, O=IPADOMAIN > > > > > > > > Profile > > > > Profile ID: KPNWebhostingAEM > > > > Profile description: KPN Webhosting AEM > > > > Store issued certificates: TRUE > > > > > > > > CAACL > > > > ACL name: ING Intermediairs AEM Application Servers > > > > Enabled: TRUE > > > > Profiles: KPNWebhostingServiceCertAEM, KPNWebhostingAEM > > > > Host Groups: xxx_accp_applications, xxx_prod_applications > > > > > > > > Trying to request a certificate for a server ipa-getcert request > > > > -r -I mongo2 -f /etc/pki/tls/certs/host.crt -k > > > > /etc/pki/tls/certs/host.key -TKPNWebhostingAEM > > > > > > > > Results in: > > > > ipa-getcert list > > > > Number of certificates and requests being tracked: 1. > > > > Request ID 'mongo2': > > > > status: CA_UNREACHABLE > > > > ca-error: Server at https://pvlipa1001c.ipadomain/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Policy Set Not Found)). > > > > stuck: no > > > > key pair storage: type=FILE,location='/etc/pki/tls/certs/host.key' > > > > certificate: type=FILE,location='/etc/pki/tls/certs/host.crt' > > > > CA: IPA > > > > issuer: > > > > subject: > > > > expires: unknown > > > > pre-save command: > > > > post-save command: > > > > track: yes > > > > auto-renew: yes > > > > > > > > Since the same setup was working to request certificates on my lab environment I'm at a loss what is causing the error. > > > > > > > > Met vriendelijke groet, > > > > > > > Hi Wouter, > > > > > > I'm looking into this; stay tuned. > > > > > OK, I could not reproduce. Is the issue reproducible for you? Did > > you execute the commands by hand or as part of a script? Can you > > provide your PKI debug log (/var/log/pki/pki-tomcat/ca/debug/)? > > > > Cheers, > > Fraser > > From pspacek at redhat.com Mon Dec 14 08:51:12 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 14 Dec 2015 09:51:12 +0100 Subject: [Freeipa-users] FreeIPA DNSSEC NSEC3PARAM record In-Reply-To: <1819853.Zemz8iNKaH@techz> References: <3267566.oWNlBILFrx@techz> <56696737.8090007@redhat.com> <1819853.Zemz8iNKaH@techz> Message-ID: <566E8300.4070900@redhat.com> On 10.12.2015 16:05, G?nther J. Niederwimmer wrote: > Am Thursday 10 December 2015, 12:51:19 schrieb Petr Spacek: >> On 9.12.2015 14:40, G?nther J. Niederwimmer wrote: >>> Hello, >>> >>> I like to create a NSEC3PARAM Record but my tests are not working :-(. >>> >>> Is there a documentation for this Problem I can't found a DOCU >>> >>> My test is >>> >>> I make a "Salt" with this >>> >>> head -c 512 /dev/random | sha1sum | cut -b 1-16 >>> xxxxxxxxxxxxx... >>> >>> afterward i make with >>> ldns-nsec3-hash -t 10 -s xxxxxxxxxxxxxxxxxx xxxxx.com >>> xxxxx..... >>> >>> the result i like to insert in the WebUI but this is wrong ? >>> >>> What is the correct syntax to create a NSEC3PARAM record? >>> >>> Thanks for a answer, >> >> Hello, >> >> FreeIPA just passes the value to BIND, so standard syntax per >> http://tools.ietf.org/html/rfc5155#section-4.3 >> should work. >> >> I hope this helps. > ;-) > > I am not a Mathematic Professor to understand this ;-) > > OK, I have to search again in World Wide Web to find a answer. NSEC3PARAM is a security parameter so you need to do more reading about it before you can do informed decision and pick right parameters for your use-case. If you do not want to spend more time on this just let NSEC in place and be done with it. Improperly configured NSEC3 ("improper" for your purposes) will give only false sense of security. You can read relevant chapters in DNSSEC guide here: http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html I hope this helps. -- Petr^2 Spacek From abokovoy at redhat.com Mon Dec 14 10:03:06 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 14 Dec 2015 12:03:06 +0200 Subject: [Freeipa-users] Any recent guides for Postfix and IPA integration? In-Reply-To: <1449873160.18285.23.camel@thesandhufamily.ca> References: <1449865759.18285.9.camel@thesandhufamily.ca> <1449873160.18285.23.camel@thesandhufamily.ca> Message-ID: <20151214100306.GO4620@redhat.com> On Fri, 11 Dec 2015, Ranbir wrote: >On Fri, 2015-12-11 at 22:13 +0100, Natxo Asenjo wrote: >> what exactly do you want to achieve? 'Integrate' could mean a couple >> of things, so please specify. > >Ya, that was lame. Let me elaborate. > >I have a postfix server and a dovecot server: both are running in >separate KVMs. They're on different subnets and they have a firewall in >between. I've opened up ports to allow them to talk to each other >because the postfix server is using dovecot for smtp auth and lmtp for >mail delivery. The dovecot users are in a password file. At the moment, >my mail setup is working perfectly. > >I have a master IPA server on the same network as the dovecot box. >There's a replica IPA server on the postfix server's network. Both >servers are joined to the IPA domain although they are in different DNS >domains (which doesn't really matter here, I guess). > >I would like to move postfix and dovecot to use IPA for sasl auth and >for managing the virtual mailboxes. I have a good idea of how this is >all supposed to work together. What I need are the actual steps to get >it done. Have you checked HOWTOs on freeipa.org? http://www.freeipa.org/page/Dovecot_IMAPS_Integration_with_FreeIPA_using_Single_Sign_On http://www.freeipa.org/page/Dovecot_Integration http://www.freeipa.org/page/%28DRAFT%29_HA_mail_services_with_FreeIPA,_postfix,_dovecot,_amavisd-new,_clamd_and_PLAIN/GSSAPI_SSO and http://www.dalemacartney.com/2013/03/14/deploying-postfix-with-ldap-freeipa-virtual-aliases-and-kerberos-authentication/ https://stomp.colorado.edu/blog/blog/2013/07/09/on-freeipa-postfix-and-a-relaying-smtp-client/ Remember to look at http://www.freeipa.org/page/HowTos, we have a lot of articles on integration already. It would be shame not to reuse knowledge base at hand. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Dec 14 10:12:04 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 14 Dec 2015 12:12:04 +0200 Subject: [Freeipa-users] FreeRadius and FreeIPA In-Reply-To: <56684014.9060001@chem.byu.edu> References: <56684014.9060001@chem.byu.edu> Message-ID: <20151214101204.GP4620@redhat.com> On Wed, 09 Dec 2015, Randy Morgan wrote: >Hello, > >We are setting up our wireless to authenticate against FreeRadius and >FreeIPA. I am looking for any instructions on how to integrate radius >with IPA. We can get them talking via kerberos, but when we have a >wireless client attempt to authenticate against them, the password >gets stripped out and only the username gets passed on, resulting in a >failed logon attempt. > >As we have studied the problem we have identified the communication >protocols used by wireless to pass on the user credentials to radius. >Wireless uses EAP as it's primary protocol. We are running Xirrus >wireless APs and from what we can learn, they act only as a pass >through conduit for the client. Ideally we would like them to speak >PEAP TTLS, this would allow kerberos to process from the client to the >IPA server, we are still researching this. > >Are there any instructions on how to integrate FreeRadius 3.0.10 with >FreeIPA 3.3.5? Any help would be appreciated. We see this question asked periodically. What we ask always prior to answering it is what it would be used for? What authentication mechanisms RADIUS is supposed to provide to its clients? FreeRADIUS authenticating against IPA is easy. However, depending on what authentication mechanisms are required it will be either not possible to achieve or will definitely degrade security of the setup. A general approach is to use following setup to use PAP authentication: 1. Installing the 'freeradius-ldap' rpm from yum 2. chmod 775 /etc/raddb/certs (so radiusd can write cert files) 3. Change your 'authorize' and 'authenticate' sections of /etc/raddb/radiusd.conf to: authorize { ldap } authenticate { Auth-Type LDAP { ldap } } During PAP a plaintext password is passed to the RADIUS server (encrypted with a weak MD5 shared secret). When the RADIUS server receives the users plaintext password in the conventional configuration it simply compares the received password with the stored password. The issue with IPA is there is no stored plaintext password to compare to, therefore you cannot use conventional PAP with IPA. But FreeRADIUS permits you to do other things with PAP besides just comparing the received password against the stored password for the user. You can instruct FreeRADIUS to use what they call an "authentication oracle", or at the risk of loose terminology to "proxy" the authentication to another authentication server (not to be confused with radius proxy where the radius transaction is proxied to another radius server). There are two authentication oracles FreeRADIUS can use * LDAP * Kerberos In this scenario the plantext password received by the RADIUS server is used to authenticate against the oracle. For LDAP it does a simple bind. For Kerberos it does a kinit. If the authentication succeeds the RADIUS server ACK's the PAP. The thing to note here is this is still occurring with PAP but no password comparison is being performed. There is a third "oracle" FreeRADIUS can utilize, namely Active Directory, but in this case the protocol is not PAP, the ntlm_auth helper from Samba is used instead with the RADIUS server communicating with ntlm_auth which communicates with AD. The suggestion of using strong passwords is always a good idea. The password transmission between the client and the radius server only enjoys weak protection so a strong password is especially important. Communication between the RADIUS server and it's oracles can be quite strong and is generally not a concern if things are configured properly. Now, there is an issue if you would want to authenticate Windows clients using MS CHAPv2 because that implies that FreeRADIUS would want to fetch a weak NTLM hash to do negotiation on its own side. To achieve that, one would need to give up the hashes to FreeRADIUS instance. We consider them weak as they can be used to brute force decryption of the passwords (trivially these days!) so a certain care should be done to limit who can access them. We strongly not recommending use of this but sometimes you are forced to provide authentication for WiFi networks to Windows clients that only support 0. Run ipa-adtrust-install to configure IPA to generate NTLM hashes. Make sure you'll run the task to generate SIDs, ipa-adtrust-install will ask about it. 1. You need to create a system account for FreeRADIUS to acces the LDAP server. Let's say, it is uid=freeradius,cn=sysaccounts,cn=etc,dc=example,dc=com 2. Make the DN above a member of cn=adtrust agents,cn=sysaccounts,dc=example,dc=com Use the DN as in FreeRADIUS configuration. 3. For each user that needs to get NTLM hashes, a password change is required to regenerate all hashes. We currently have no means to generate them otherwise. If you use ldap auth I'd suggest the connection either be SSL or on the loopback to prevent snooping. Missing from instructions above is the configuration of the ldap server FreeRADIUS will connect to. This is done in /etc/raddb/mods-available/ldap and you'll need to make a symlink to it in /etc/raddb/mods-enabled to activate it. The ldap config file has lots of comments that explains all the options, like most things in FreeRADIUS the doc is in the config files. It's not possible to use any RADIUS authentication mechanism that requires the RADIUS server to lookup a cleartext password, refer to this chart: http://deployingradius.com/documents/protocols/compatibility.html If you do step 0 from above and enable NTLM hashes you can utilize column 2 from above because the server can lookup up the NTLM hash. The attribute will be named ipaNTHash, so you would need to remap password attribute for that in the ldap configuration. It is currently not possible to configure rlm_ldap module to do LDAP authentication by SASL GSSAPI instead of using a system account in IPA because while FreeRADIUS tries to search for SASL-enabled LDAP API, it doesn't use it at all and always uses LDAP simple bind. This is something we need to fix --- I'm unable right now to find out the reason why previously supported SASL GSSAPI authentication is removed from FreeRADIUS. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Dec 14 10:21:56 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 14 Dec 2015 12:21:56 +0200 Subject: [Freeipa-users] Clean up DNS, Host, Cert and other records from IPA / IDM In-Reply-To: <4924A345-FCFE-4973-B49E-47034BE69358@cccis.com> References: <4924A345-FCFE-4973-B49E-47034BE69358@cccis.com> Message-ID: <20151214102156.GQ4620@redhat.com> On Fri, 11 Dec 2015, Andrey Ptashnik wrote: >Hello Team, > >We have many servers in our environment that are on a different stage >of their lifecycle. All of them are added to IPA domain. There are >cases when servers gets moved, sometimes crash, sometimes are being >rebuild or decommissioned. In those cases we need to completely remove >server identity from IPA including DNS, Host, Certificate and other >associated records. >What is the most proper way to completely remove client records in case >if server needs to be rebuilt with the same host name down the road? >(hardware failure happened, server crashed and needs to be rebuild ? is >a perfect example). 'ipa-client-install --uninstall' results in calling 'ipa-join --unenroll -h hostname' which in turn calls 'ipa host-disable hostname'. The latter on the IPA server side does following: - disables the host entry - disables any service associated with the host - revokes certificates associated with the host - removes keytab associated with the host Disabling services involves revoking of certificates and removal of keytabs associated with these services. Of course, 'keytab removal' means only that the keys are removed from LDAP entries, not that keytab files are removed. Note that none of DNS entries are removed. If you don't have hosts anymore, you can issue 'ipa host-disable hostname' from any other host under credentials of a user that has enough privileges to remove the host and associated services. 'admins' group membership should be strong enough to achieve this goal. -- / Alexander Bokovoy From mkosek at redhat.com Mon Dec 14 11:09:54 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 14 Dec 2015 12:09:54 +0100 Subject: [Freeipa-users] Yum update broke CA/CS - pki-tomcatd not starting In-Reply-To: <566B2A07.9030200@iki.fi> References: <566A7BE3.9000500@iki.fi> <566A87F8.9030303@redhat.com> <566B2A07.9030200@iki.fi> Message-ID: <566EA382.2090508@redhat.com> ipa-cacert-manage only renews CA certificate. It does not fix expired CA subsystem certificates (#getcert list), IIRC. I think the process was: - move system time to about 1-2 weeks before the oldest expired certificate expiry time - restart certmonnger - now certmonger itself should start renewing the certificates. Other alternative is to resubmit them with "getcert resubmit" command and see the results - when done, time can be moved back Honza (CCed), if I missed anything, please let me know. Martin On 12/11/2015 08:54 PM, Jani West wrote: > Hello, > > Seems like I indeed have expired certs. The problem is, how I can renew these. > > I tried to do: > --------------- > root at ipa1 ca]# systemctl restart dirsrv.target > [root at ipa1 ca]# ipa-cacert-manage renew > Renewing CA certificate, please wait > Error resubmitting certmonger request '20150814121620', please check the > request manually > --------------- > > I still have old certs: > > > > Request ID '20150814121606': > status: CA_WORKING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB',pin='654666959930' > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=PLANWEE.LOCAL > subject: CN=CA Audit,O=PLANWEE.LOCAL > expires: 2015-09-29 20:22:26 UTC > key usage: digitalSignature,nonRepudiation > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20150814121614': > status: CA_WORKING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB',pin='654666959930' > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=PLANWEE.LOCAL > subject: CN=OCSP Subsystem,O=PLANWEE.LOCAL > expires: 2015-09-29 20:22:25 UTC > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign > eku: id-kp-OCSPSigning > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "ocspSigningCert > cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20150814121618': > status: CA_WORKING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB',pin='654666959930' > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=PLANWEE.LOCAL > subject: CN=CA Subsystem,O=PLANWEE.LOCAL > expires: 2015-09-29 20:22:25 UTC > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert > cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20150814121621': > status: CA_WORKING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=PLANWEE.LOCAL > subject: CN=IPA RA,O=PLANWEE.LOCAL > expires: 2015-09-29 20:23:10 UTC > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert > track: yes > auto-renew: yes > > On 12/11/2015 10:23 AM, Martin Kosek wrote: >> On 12/11/2015 08:31 AM, Jani West wrote: >>> Hello, >>> >>> Pki-tomcatd seems to have difficulties when connecting to CA. LDAP >>> server is starting ok when starting it directly with "systemctl start >>> dirsrv.target". >>> >>> When starting "systemctl start ipa" everything else will startup exept >>> the >>> pki-tomcatd. >>> >>> Obviously same thing happens when starting with ipactl directly: >>> [root at ipa1 ca]# ipactl start >>> Existing service file detected! >>> Assuming stale, cleaning and proceeding >>> Starting Directory Service >>> Starting krb5kdc Service >>> Starting kadmin Service >>> Starting named Service >>> Starting ipa_memcached Service >>> Starting httpd Service >>> Starting pki-tomcatd Service >>> Failed to start pki-tomcatd Service >>> Shutting down >>> Aborting ipactl >>> >>> >>> /var/log/pki/pki-tomcat/localhost.2015-12-11.log >>> SEVERE: Servlet.service() for servlet [caGetStatus] in context with >>> path [/ca] >>> threw exception java.io.IOException: CS server is not ready to serve. >>> >>> >>> /var/log/dirsrv/slapd-PLANWEE-LOCAL/errors >>> [11/Dec/2015:01:02:19 +0200] - slapd started. Listening on All >>> Interfaces port >>> 389 for LDAP requests >>> [11/Dec/2015:01:02:19 +0200] - Listening on All Interfaces port 636 for >>> LDAPS requests >>> [11/Dec/2015:01:02:19 +0200] - Listening on >>> /var/run/slapd-PLANWEE-LOCAL.socket >>> for LDAPI requests >>> [11/Dec/2015:01:02:19 +0200] slapd_ldap_sasl_interactive_bind - Error: >>> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error >>> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint >>> is not >>> connected) >>> [11/Dec/2015:01:02:19 +0200] slapi_ldap_bind - Error: could not perform >>> interactive bind for id [] authentication mechanism [GSSAPI]: error -1 >>> (Can't contact LDAP server) >>> >>> /var/log/pki/pki-tomcat/ca/debug >>> Internal Database Error encountered: Could not connect to LDAP server >>> host ipa1.backend.planwee.local port 636 Error >>> netscape.ldap.LDAPException: IO >>> Error creating JSS SSL Socket (-1) >>> >>> Environment: >>> CentOS 7 >>> IPA 4.1 >>> >>> The problem looks the same as this: >>> https://access.redhat.com/solutions/2022123 >>> >>> Unfortunately I cannot view resolution. >>> >>> is this related to expired CA certificates? >> >> If you have expired certificates (you can check with "# getcert list | >> grep expires"), it could cause issues like that also. >> >> The article you are referring to is rather around wrong CA certificate >> trust attributes in /var/lib/pki/pki-tomcat/alias/ or >> /etc/dirsrv/slapd-EXAMPLE-COM/ NSS databases. >> >> You can check that with >> # certutil -L -d /var/lib/pki/pki-tomcat/alias/ >> # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM/ >> >> BTW, if you want to see the whole article or other articles from the >> large KB, I would suggest getting a subscription :-) > > From jcholast at redhat.com Mon Dec 14 11:13:59 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 14 Dec 2015 12:13:59 +0100 Subject: [Freeipa-users] Yum update broke CA/CS - pki-tomcatd not starting In-Reply-To: <566EA382.2090508@redhat.com> References: <566A7BE3.9000500@iki.fi> <566A87F8.9030303@redhat.com> <566B2A07.9030200@iki.fi> <566EA382.2090508@redhat.com> Message-ID: <566EA477.9000503@redhat.com> Hi, On 14.12.2015 12:09, Martin Kosek wrote: > ipa-cacert-manage only renews CA certificate. It does not fix expired CA > subsystem certificates (#getcert list), IIRC. Correct. > > I think the process was: > - move system time to about 1-2 weeks before the oldest expired certificate > expiry time > - restart certmonnger > - now certmonger itself should start renewing the certificates. Other > alternative is to resubmit them with "getcert resubmit" command and see the results > - when done, time can be moved back > > Honza (CCed), if I missed anything, please let me know. This should work. > > Martin > > On 12/11/2015 08:54 PM, Jani West wrote: >> Hello, >> >> Seems like I indeed have expired certs. The problem is, how I can renew these. >> >> I tried to do: >> --------------- >> root at ipa1 ca]# systemctl restart dirsrv.target >> [root at ipa1 ca]# ipa-cacert-manage renew >> Renewing CA certificate, please wait >> Error resubmitting certmonger request '20150814121620', please check the >> request manually >> --------------- >> >> I still have old certs: >> >> >> >> Request ID '20150814121606': >> status: CA_WORKING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert >> cert-pki-ca',token='NSS Certificate DB',pin='654666959930' >> certificate: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-ca-renew-agent >> issuer: CN=Certificate Authority,O=PLANWEE.LOCAL >> subject: CN=CA Audit,O=PLANWEE.LOCAL >> expires: 2015-09-29 20:22:26 UTC >> key usage: digitalSignature,nonRepudiation >> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >> "auditSigningCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20150814121614': >> status: CA_WORKING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert >> cert-pki-ca',token='NSS Certificate DB',pin='654666959930' >> certificate: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-ca-renew-agent >> issuer: CN=Certificate Authority,O=PLANWEE.LOCAL >> subject: CN=OCSP Subsystem,O=PLANWEE.LOCAL >> expires: 2015-09-29 20:22:25 UTC >> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign >> eku: id-kp-OCSPSigning >> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "ocspSigningCert >> cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20150814121618': >> status: CA_WORKING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert >> cert-pki-ca',token='NSS Certificate DB',pin='654666959930' >> certificate: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-ca-renew-agent >> issuer: CN=Certificate Authority,O=PLANWEE.LOCAL >> subject: CN=CA Subsystem,O=PLANWEE.LOCAL >> expires: 2015-09-29 20:22:25 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert >> cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20150814121621': >> status: CA_WORKING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB' >> CA: dogtag-ipa-ca-renew-agent >> issuer: CN=Certificate Authority,O=PLANWEE.LOCAL >> subject: CN=IPA RA,O=PLANWEE.LOCAL >> expires: 2015-09-29 20:23:10 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >> track: yes >> auto-renew: yes >> >> On 12/11/2015 10:23 AM, Martin Kosek wrote: >>> On 12/11/2015 08:31 AM, Jani West wrote: >>>> Hello, >>>> >>>> Pki-tomcatd seems to have difficulties when connecting to CA. LDAP >>>> server is starting ok when starting it directly with "systemctl start >>>> dirsrv.target". >>>> >>>> When starting "systemctl start ipa" everything else will startup exept >>>> the >>>> pki-tomcatd. >>>> >>>> Obviously same thing happens when starting with ipactl directly: >>>> [root at ipa1 ca]# ipactl start >>>> Existing service file detected! >>>> Assuming stale, cleaning and proceeding >>>> Starting Directory Service >>>> Starting krb5kdc Service >>>> Starting kadmin Service >>>> Starting named Service >>>> Starting ipa_memcached Service >>>> Starting httpd Service >>>> Starting pki-tomcatd Service >>>> Failed to start pki-tomcatd Service >>>> Shutting down >>>> Aborting ipactl >>>> >>>> >>>> /var/log/pki/pki-tomcat/localhost.2015-12-11.log >>>> SEVERE: Servlet.service() for servlet [caGetStatus] in context with >>>> path [/ca] >>>> threw exception java.io.IOException: CS server is not ready to serve. >>>> >>>> >>>> /var/log/dirsrv/slapd-PLANWEE-LOCAL/errors >>>> [11/Dec/2015:01:02:19 +0200] - slapd started. Listening on All >>>> Interfaces port >>>> 389 for LDAP requests >>>> [11/Dec/2015:01:02:19 +0200] - Listening on All Interfaces port 636 for >>>> LDAPS requests >>>> [11/Dec/2015:01:02:19 +0200] - Listening on >>>> /var/run/slapd-PLANWEE-LOCAL.socket >>>> for LDAPI requests >>>> [11/Dec/2015:01:02:19 +0200] slapd_ldap_sasl_interactive_bind - Error: >>>> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error >>>> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint >>>> is not >>>> connected) >>>> [11/Dec/2015:01:02:19 +0200] slapi_ldap_bind - Error: could not perform >>>> interactive bind for id [] authentication mechanism [GSSAPI]: error -1 >>>> (Can't contact LDAP server) >>>> >>>> /var/log/pki/pki-tomcat/ca/debug >>>> Internal Database Error encountered: Could not connect to LDAP server >>>> host ipa1.backend.planwee.local port 636 Error >>>> netscape.ldap.LDAPException: IO >>>> Error creating JSS SSL Socket (-1) >>>> >>>> Environment: >>>> CentOS 7 >>>> IPA 4.1 >>>> >>>> The problem looks the same as this: >>>> https://access.redhat.com/solutions/2022123 >>>> >>>> Unfortunately I cannot view resolution. >>>> >>>> is this related to expired CA certificates? >>> >>> If you have expired certificates (you can check with "# getcert list | >>> grep expires"), it could cause issues like that also. >>> >>> The article you are referring to is rather around wrong CA certificate >>> trust attributes in /var/lib/pki/pki-tomcat/alias/ or >>> /etc/dirsrv/slapd-EXAMPLE-COM/ NSS databases. >>> >>> You can check that with >>> # certutil -L -d /var/lib/pki/pki-tomcat/alias/ >>> # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM/ >>> >>> BTW, if you want to see the whole article or other articles from the >>> large KB, I would suggest getting a subscription :-) >> >> > -- Jan Cholasta From mkosek at redhat.com Mon Dec 14 12:12:44 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 14 Dec 2015 13:12:44 +0100 Subject: [Freeipa-users] Clean up DNS Host Cert and other records from IPA In-Reply-To: <703AD3A5-F146-46A1-AA11-3FA3D4D851DD@cccis.com> References: <703AD3A5-F146-46A1-AA11-3FA3D4D851DD@cccis.com> Message-ID: <566EB23C.4050207@redhat.com> On 12/11/2015 11:55 PM, Andrey Ptashnik wrote: > Hello Team, > > We have many servers in our environment that are on a different stage of their lifecycle. All of them are added to IPA domain. There are cases when servers gets moved, sometimes crash, sometimes are being rebuild or decommissioned. In those cases we need to completely remove server identity from IPA including DNS, Host, Certificate and other associated records. > What is the most proper way to completely remove client records in case if server needs to be rebuilt with the same host name down the road? (hardware failure happened, server crashed and needs to be rebuild ? is a perfect example). ipa host-del command (can be also with --updatedns flag) should remove all services and revoke certificates active for the host or service records. Is that insufficient or maybe not working for you? Martin From mkosek at redhat.com Mon Dec 14 12:15:38 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 14 Dec 2015 13:15:38 +0100 Subject: [Freeipa-users] Any recent guides for Postfix and IPA integration? In-Reply-To: <1449876372.5344.29.camel@stefany.eu> References: <1449865759.18285.9.camel@thesandhufamily.ca> <1449876372.5344.29.camel@stefany.eu> Message-ID: <566EB2EA.7050506@redhat.com> On 12/12/2015 12:26 AM, Martin ?tefany wrote: > Hello Ranbir, > > I'm working on this, even today I was putting more things together. > (That DRAFT is really uncommented version of what I currently have). And > I've opened also https://fedorahosted.org/freeipa/ticket/5521 to get a > bit more out of it. > > To sum it up what I've put together: > - Postfix for SMTP MTA > - Dovecot for IMAP (no POP3) > - Amavisd-new with ClamAV and SpamAssassin for Antispam / Antivirus / > additional header checks, etc. > - SPF, DKIM, DMARC support for both sending and receiving mail > - setup is HA thanks to DNS records, and 2 separate systems running > almost identical configuration and Dovecot replicates mailboxes using > dsync > - PLAIN / LOGIN / GSSAPI authentication for SSO login thanks to FreeIPA > (integration with Evolution on Fedora/RHEL/CentOS desktop joined to > FreeIPA domain works also great) > - users, of course, stored in FreeIPA, usage granted only to ones with > correct e-mail field, group membership (and enablement of the ID) > - but some pieces are still missing: > - I'm still reviewing e.g. correct postfix restrictions and > documenting the full setup > - there's missing support for GUI configuration domain aliases, user > aliases, sender/receiver Bcc support, quota setup, etc. even if > something is managable via ipa-admintools and LDAP attributes > > I would like to finish it asap, within a week or two, cause I run this > e-mail system at home (as somebody already mentioned, why not?) and I > don't like it unfinished. ;) > > But to give you a good place to start: have a look to iRedMail project, > http://www.iredmail.org/, ZhangHuangbin's product is great and it helped > me a lot to prepare what I described above. There's no support for 'old- > style' HA, but you can still run it 'HA' on VM with all the benefits, > and there's not direct support for FreeIPA integration, but guideline > for ActiveDirectory integration exists, so you can start there: http://w > ww.iredmail.org/docs/active.directory.html. > > As Natxo mentioned, it all depends what kind of integration you want and > what do you expect from mail setup. ;) > > Martin Looks as a decent amount of work included in this. BTW, if you have cycles to contribute a How To to http://www.freeipa.org/page/HowTos or update/improve existing guides there, I think other FreeIPA community members would be very very grateful :-) Thanks, Martin From abokovoy at redhat.com Mon Dec 14 15:35:38 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 14 Dec 2015 17:35:38 +0200 Subject: [Freeipa-users] otpd heavy load? In-Reply-To: <566A0DD3.3010802@gmail.com> References: <5669B7BD.8020404@gmail.com> <1449770105.23069.6.camel@redhat.com> <5669C0AD.3070603@gmail.com> <1449773343.23069.7.camel@redhat.com> <566A0DD3.3010802@gmail.com> Message-ID: <20151214153538.GU4620@redhat.com> On Thu, 10 Dec 2015, Janelle wrote: >libverto-tevent-0.2.5-4.el7.x86_64 >libverto-0.2.5-4.el7.x86_64 > >Patching problem perhaps? Can you install debuginfo for krb5 and ipa? And then install ltrace? I would go with these tools: - once ipa-otpd recreates its high resource usage, run 'pstack ' periodically to take few snapshots of its stacktraces - do 'ltrace -s 256 -S -ttt -T -r -p ' Save the reports you'd get, and make them available to us. They will be big enough, so avoid sending it to the list, send privately. > >On 12/10/15 10:49 AM, Nathaniel McCallum wrote: >>Please provide the output of the 'rpm -qa libverto*' command. >> >>On Thu, 2015-12-10 at 10:13 -0800, Janelle wrote: >>>RHEL 7.1 >>> >>>On 12/10/15 9:55 AM, Nathaniel McCallum wrote: >>>>On Thu, 2015-12-10 at 09:34 -0800, Janelle wrote: >>>>>Hi, >>>>> >>>>>Hope everyone is enjoying the holiday season. Been away for >>>>>sometime, >>>>>and wanted to jump in with a new question. I am seeing otpd have >>>>>high >>>>>resource usage (from just monitoring via top, sar and uptime) >>>>>however, I >>>>>can not seem to find any logging from it, nor how I might be able >>>>>to >>>>>enable some in order to find out why it is using so much CPU? Any >>>>>thoughts/suggestions? >>>>Log messages should be available through journalctl. >>>> >>>>Which libverto backend are you running? If you are on Fedora, >>>>please >>>>provide the output of the 'rpm -qa libverto*' command. > >-- >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 -- / Alexander Bokovoy From randym at chem.byu.edu Mon Dec 14 15:36:44 2015 From: randym at chem.byu.edu (Randy Morgan) Date: Mon, 14 Dec 2015 08:36:44 -0700 Subject: [Freeipa-users] FreeRadius and FreeIPA In-Reply-To: <20151214101204.GP4620@redhat.com> References: <56684014.9060001@chem.byu.edu> <20151214101204.GP4620@redhat.com> Message-ID: <566EE20C.7030308@chem.byu.edu> Thanks Alexander, that was an excellent explanation with some very helpful information. We will look over our configs and see if we can work this out. Randy Randy Morgan CSR Department of Chemistry and Biochemistry Brigham Young University 801-422-4100 On 12/14/2015 3:12 AM, Alexander Bokovoy wrote: > On Wed, 09 Dec 2015, Randy Morgan wrote: >> Hello, >> >> We are setting up our wireless to authenticate against FreeRadius and >> FreeIPA. I am looking for any instructions on how to integrate >> radius with IPA. We can get them talking via kerberos, but when we >> have a wireless client attempt to authenticate against them, the >> password gets stripped out and only the username gets passed on, >> resulting in a failed logon attempt. >> >> As we have studied the problem we have identified the communication >> protocols used by wireless to pass on the user credentials to >> radius. Wireless uses EAP as it's primary protocol. We are running >> Xirrus wireless APs and from what we can learn, they act only as a >> pass through conduit for the client. Ideally we would like them to >> speak PEAP TTLS, this would allow kerberos to process from the client >> to the IPA server, we are still researching this. >> >> Are there any instructions on how to integrate FreeRadius 3.0.10 with >> FreeIPA 3.3.5? Any help would be appreciated. > We see this question asked periodically. What we ask always prior to > answering it is what it would be used for? What authentication > mechanisms RADIUS is supposed to provide to its clients? > > FreeRADIUS authenticating against IPA is easy. However, depending on > what authentication mechanisms are required it will be either not > possible to achieve or will definitely degrade security of the setup. > > A general approach is to use following setup to use PAP authentication: > 1. Installing the 'freeradius-ldap' rpm from yum > 2. chmod 775 /etc/raddb/certs (so radiusd can write cert files) > 3. Change your 'authorize' and 'authenticate' sections of > /etc/raddb/radiusd.conf to: > authorize { > ldap > } > authenticate { > Auth-Type LDAP { > ldap > } > } > > During PAP a plaintext password is passed to the RADIUS server > (encrypted with a weak MD5 shared secret). > > When the RADIUS server receives the users plaintext password in the > conventional configuration it simply compares the received password with > the stored password. The issue with IPA is there is no stored plaintext > password to compare to, therefore you cannot use conventional PAP with > IPA. > > But FreeRADIUS permits you to do other things with PAP besides just > comparing the received password against the stored password for the > user. You can instruct FreeRADIUS to use what they call an > "authentication oracle", or at the risk of loose terminology to "proxy" > the authentication to another authentication server (not to be confused > with radius proxy where the radius transaction is proxied to another > radius server). > > There are two authentication oracles FreeRADIUS can use > > * LDAP > * Kerberos > > In this scenario the plantext password received by the RADIUS server is > used to authenticate against the oracle. For LDAP it does a simple bind. > For Kerberos it does a kinit. If the authentication succeeds the RADIUS > server ACK's the PAP. The thing to note here is this is still occurring > with PAP but no password comparison is being performed. > > There is a third "oracle" FreeRADIUS can utilize, namely Active > Directory, but in this case the protocol is not PAP, the ntlm_auth > helper from Samba is used instead with the RADIUS server communicating > with ntlm_auth which communicates with AD. > > The suggestion of using strong passwords is always a good idea. The > password transmission between the client and the radius server only > enjoys weak protection so a strong password is especially important. > Communication between the RADIUS server and it's oracles can be quite > strong and is generally not a concern if things are configured properly. > > Now, there is an issue if you would want to authenticate Windows clients > using MS CHAPv2 because that implies that FreeRADIUS would want to fetch > a weak NTLM hash to do negotiation on its own side. > > To achieve that, one would need to give up the hashes to FreeRADIUS > instance. We consider them weak as they can be used to brute force > decryption of the passwords (trivially these days!) so a certain care > should be done to limit who can access them. We strongly not > recommending use of this but sometimes you are forced to provide > authentication for WiFi networks to Windows clients that only support > > 0. Run ipa-adtrust-install to configure IPA to generate NTLM hashes. > Make sure you'll run the task to generate SIDs, ipa-adtrust-install > will ask about it. > > 1. You need to create a system account for FreeRADIUS to acces the LDAP > server. Let's say, it is > uid=freeradius,cn=sysaccounts,cn=etc,dc=example,dc=com > > 2. Make the DN above a member of cn=adtrust > agents,cn=sysaccounts,dc=example,dc=com > Use the DN as in FreeRADIUS configuration. > > 3. For each user that needs to get NTLM hashes, a password change is > required to regenerate all hashes. We currently have no means > to generate them otherwise. > > If you use ldap auth I'd suggest the connection either be SSL or on the > loopback to prevent snooping. Missing from instructions above is the > configuration of the ldap server FreeRADIUS will connect to. > > This is done in /etc/raddb/mods-available/ldap and you'll need to make a > symlink to it in /etc/raddb/mods-enabled to activate it. The ldap config > file has lots of comments that explains all the options, like most > things in FreeRADIUS the doc is in the config files. > > It's not possible to use any RADIUS authentication mechanism that > requires the RADIUS server to lookup a cleartext password, refer to this > chart: > > http://deployingradius.com/documents/protocols/compatibility.html > > If you do step 0 from above and enable NTLM hashes you can utilize > column 2 from above because the server can lookup up the NTLM hash. The > attribute will be named ipaNTHash, so you would need to remap password > attribute for that in the ldap configuration. > > It is currently not possible to configure rlm_ldap module to do LDAP > authentication by SASL GSSAPI instead of using a system account in IPA > because while FreeRADIUS tries to search for SASL-enabled LDAP API, it > doesn't use it at all and always uses LDAP simple bind. This is > something we need to fix --- I'm unable right now to find out the reason > why previously supported SASL GSSAPI authentication is removed from > FreeRADIUS. > From m3freak at thesandhufamily.ca Mon Dec 14 16:30:07 2015 From: m3freak at thesandhufamily.ca (Ranbir) Date: Mon, 14 Dec 2015 11:30:07 -0500 Subject: [Freeipa-users] Any recent guides for Postfix and IPA integration? In-Reply-To: References: <1449865759.18285.9.camel@thesandhufamily.ca> <1449873160.18285.23.camel@thesandhufamily.ca> Message-ID: <1450110607.15210.47.camel@thesandhufamily.ca> On Sun, 2015-12-13 at 21:56 +0100, Natxo Asenjo wrote: > so what have you tried? A number of things. However, I've been able to get past the SASL GSSAPI error I was seeing in Postfix. Now I've run into another issue though I don't think it's related to freeipa. I'm going to post what I did once I have a working setup. In the meantime, I have other questions. How would one handle an email only user in freeipa? I have mail accounts that aren't attached to a real person and yet I need the "user" to exist in freeipa. -- Ranbir -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From janellenicole80 at gmail.com Mon Dec 14 15:38:09 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 14 Dec 2015 07:38:09 -0800 Subject: [Freeipa-users] otpd heavy load? In-Reply-To: <20151214153538.GU4620@redhat.com> References: <5669B7BD.8020404@gmail.com> <1449770105.23069.6.camel@redhat.com> <5669C0AD.3070603@gmail.com> <1449773343.23069.7.camel@redhat.com> <566A0DD3.3010802@gmail.com> <20151214153538.GU4620@redhat.com> Message-ID: <566EE261.9080807@gmail.com> I'll gather up the info first chance I get. Thank you ~J On 12/14/15 7:35 AM, Alexander Bokovoy wrote: > On Thu, 10 Dec 2015, Janelle wrote: >> libverto-tevent-0.2.5-4.el7.x86_64 >> libverto-0.2.5-4.el7.x86_64 >> >> Patching problem perhaps? > Can you install debuginfo for krb5 and ipa? And then install ltrace? > > I would go with these tools: > - once ipa-otpd recreates its high resource usage, run 'pstack ' > periodically to take few snapshots of its stacktraces > - do 'ltrace -s 256 -S -ttt -T -r -p ' > > Save the reports you'd get, and make them available to us. They will be > big enough, so avoid sending it to the list, send privately. > >> >> On 12/10/15 10:49 AM, Nathaniel McCallum wrote: >>> Please provide the output of the 'rpm -qa libverto*' command. >>> >>> On Thu, 2015-12-10 at 10:13 -0800, Janelle wrote: >>>> RHEL 7.1 >>>> >>>> On 12/10/15 9:55 AM, Nathaniel McCallum wrote: >>>>> On Thu, 2015-12-10 at 09:34 -0800, Janelle wrote: >>>>>> Hi, >>>>>> >>>>>> Hope everyone is enjoying the holiday season. Been away for >>>>>> sometime, >>>>>> and wanted to jump in with a new question. I am seeing otpd have >>>>>> high >>>>>> resource usage (from just monitoring via top, sar and uptime) >>>>>> however, I >>>>>> can not seem to find any logging from it, nor how I might be able >>>>>> to >>>>>> enable some in order to find out why it is using so much CPU? Any >>>>>> thoughts/suggestions? >>>>> Log messages should be available through journalctl. >>>>> >>>>> Which libverto backend are you running? If you are on Fedora, >>>>> please >>>>> provide the output of the 'rpm -qa libverto*' command. >> >> -- >> 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 > From wdh at dds.nl Mon Dec 14 16:47:38 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Mon, 14 Dec 2015 17:47:38 +0100 Subject: [Freeipa-users] AD group members Message-ID: <566EF2AA.7080601@dds.nl> An HTML attachment was scrubbed... URL: From m3freak at thesandhufamily.ca Mon Dec 14 18:38:55 2015 From: m3freak at thesandhufamily.ca (Ranbir) Date: Mon, 14 Dec 2015 13:38:55 -0500 Subject: [Freeipa-users] Any recent guides for Postfix and IPA integration? In-Reply-To: <1450110607.15210.47.camel@thesandhufamily.ca> References: <1449865759.18285.9.camel@thesandhufamily.ca> <1449873160.18285.23.camel@thesandhufamily.ca> <1450110607.15210.47.camel@thesandhufamily.ca> Message-ID: <1450118335.15210.52.camel@thesandhufamily.ca> On Mon, 2015-12-14 at 11:30 -0500, Ranbir wrote: > How would one handle an email only user in freeipa? I have mail > accounts that aren't attached to a real person and yet I need the > "user" to exist in freeipa. Should I just create a normal user account, set the password and mail and disable logins? -- Ranbir -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simo at redhat.com Mon Dec 14 18:51:37 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 14 Dec 2015 13:51:37 -0500 Subject: [Freeipa-users] Any recent guides for Postfix and IPA integration? In-Reply-To: <1450118335.15210.52.camel@thesandhufamily.ca> References: <1449865759.18285.9.camel@thesandhufamily.ca> <1449873160.18285.23.camel@thesandhufamily.ca> <1450110607.15210.47.camel@thesandhufamily.ca> <1450118335.15210.52.camel@thesandhufamily.ca> Message-ID: <1450119097.17418.162.camel@redhat.com> On Mon, 2015-12-14 at 13:38 -0500, Ranbir wrote: > On Mon, 2015-12-14 at 11:30 -0500, Ranbir wrote: > > How would one handle an email only user in freeipa? I have mail > > accounts that aren't attached to a real person and yet I need the > > "user" to exist in freeipa. > > Should I just create a normal user account, set the password and mail > and disable logins? There are a few ways to go about it. another way is to use a custom subtree + schema to store these emails only. It really depends on what kind of tools you want to use to manage the information too. Simo. -- Simo Sorce * Red Hat, Inc * New York From APtashnik at cccis.com Mon Dec 14 21:01:14 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Mon, 14 Dec 2015 21:01:14 +0000 Subject: [Freeipa-users] Clean up DNS, Host, Cert and other records from IPA / IDM In-Reply-To: <20151214102156.GQ4620@redhat.com> References: <4924A345-FCFE-4973-B49E-47034BE69358@cccis.com> <20151214102156.GQ4620@redhat.com> Message-ID: Alexander, Thank you for your feedback, this is what I expected to do - 'ipa-client-install ?uninstall' and expected and easy quick fix for my request. It seem to work in environment where server portion is on CentOS/RHEL 7.1 and clients as well on 7.1 with IPA 4.1 However when clients are little older like CentOS/RHEL 6.5-6.6 behavior in our case was different, we had to manually delete records with "ipa host-del? command like Martin Kosek mentioned. So I wanted to reiterate with Red Hat team if 'ipa-client-install ?uninstall' is still the proper way to clean up records completely. Additionally if I can expect the same behavior on client versions lower than CentOS/RHEL 7.1 + IPA 4.1 Regards, Andrey Ptashnik On 12/14/15, 4:21 AM, "Alexander Bokovoy" wrote: >On Fri, 11 Dec 2015, Andrey Ptashnik wrote: >>Hello Team, >> >>We have many servers in our environment that are on a different stage >>of their lifecycle. All of them are added to IPA domain. There are >>cases when servers gets moved, sometimes crash, sometimes are being >>rebuild or decommissioned. In those cases we need to completely remove >>server identity from IPA including DNS, Host, Certificate and other >>associated records. >>What is the most proper way to completely remove client records in case >>if server needs to be rebuilt with the same host name down the road? >>(hardware failure happened, server crashed and needs to be rebuild ? is >>a perfect example). >'ipa-client-install --uninstall' results in calling 'ipa-join --unenroll -h hostname' >which in turn calls 'ipa host-disable hostname'. The latter on the >IPA server side does following: > - disables the host entry > - disables any service associated with the host > - revokes certificates associated with the host > - removes keytab associated with the host > >Disabling services involves revoking of certificates and removal of >keytabs associated with these services. > >Of course, 'keytab removal' means only that the keys are removed from >LDAP entries, not that keytab files are removed. > >Note that none of DNS entries are removed. > >If you don't have hosts anymore, you can issue 'ipa host-disable hostname' >from any other host under credentials of a user that has enough >privileges to remove the host and associated services. 'admins' group >membership should be strong enough to achieve this goal. > >-- >/ Alexander Bokovoy From karl.forner at gmail.com Mon Dec 14 18:32:57 2015 From: karl.forner at gmail.com (Karl Forner) Date: Mon, 14 Dec 2015 19:32:57 +0100 Subject: [Freeipa-users] confused about replica role and use Message-ID: Hello, >From what I understood, a freeipa replica server is a kind of backup of another freeipa server. Both are usable by clients, and they will dynamically update their information. But I do not understand how a client will make use of the replica if the master server is down. Naively I would imagine, that like for DNS servers, that you configure a main freeipa server, and a secondary one in case the main one does not respond, but I can not find how to do it. Is this happening automagically ? Or this is not the way it is supposed to be used ? Thanks. Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald.dunkel at aixigo.de Tue Dec 15 08:13:22 2015 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Tue, 15 Dec 2015 09:13:22 +0100 Subject: [Freeipa-users] ipa-server-install --external-ca failed Message-ID: <566FCBA2.3050604@aixigo.de> ipa-server-install asked me to get the csr signed and come back, but then it refused to continue: # ipa-server-install -n example.com -r EXAMPLE.COM --external-ca --subject="C=DE,O=example AG" --setup-dns --forwarder=8.8.4.4 --forwarder=8.8.8.8 : : The next step is to get /root/ipa.csr signed by your CA and re-run /usr/sbin/ipa-server-install as: /usr/sbin/ipa-server-install --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate # /usr/sbin/ipa-server-install --external-cert-file=/root/ipa_ipa1.crt --external-cert-file=/root/root-ca.crt : : ipa.ipapython.install.cli.install_tool(Server): ERROR IPA CA certificate not found in /root/ipa_ipa1.crt, /root/root-ca.crt openssl verify shows the certificate is OK: # openssl verify -CAfile /root/root-ca.crt /root/ipa_ipa1.crt /root/ipa_ipa1.crt: OK # openssl verify -CAfile /root/root-ca.crt /root/root-ca.crt /root/root-ca.crt: OK The CA attribute is set as well, pathlen=0, etc: # openssl x509 -in /root/ipa_ipa1.crt -noout -text | less : : X509v3 extensions: X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Subject Key Identifier: : Google hasn't seen this error before, either (AFAICS). Every helpful hint is highly appreciated. Harri From sbose at redhat.com Tue Dec 15 08:59:04 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 15 Dec 2015 09:59:04 +0100 Subject: [Freeipa-users] AD group members In-Reply-To: <566EF2AA.7080601@dds.nl> References: <566EF2AA.7080601@dds.nl> Message-ID: <20151215085904.GC27845@p.redhat.com> On Mon, Dec 14, 2015 at 05:47:38PM +0100, Winfried de Heiden wrote: > Using an EL7 client, lot's of times the IPA (posix) groups are missing, > or partly missing. Doing some debugging, sssd_pac.log shows: > > (Mon Dec 14 17:19:08 2015) [sssd[pac]] [pac_user_get_grp_info] (0x2000): Group with SID [S-1-5-21-1802245919-2979536009-1783284443-51509] is not in the PAC anymore, membership must be removed. > (Mon Dec 14 17:19:08 2015) [sssd[pac]] [pac_user_get_grp_info] (0x2000): Group with SID [S-1-5-21-1802245919-2979536009-1783284443-51508] is not in the PAC anymore, membership must be removed. > > These sids are the groups I am missing. What is happening here??? Originally the PAC was the only source for the group-membership data for users coming from AD. To be able to be a member of IPA groups the IPA KDC added SIDs of IPA groups the AD user is a member of. With EL7.1 SSSD is able to read group-membership data on its own if the IPA server is running on 7.1 or newer as well. If this is your case it looks like there is a disconnect between how the IPA KDC and SSSD determine the group memberships for the given user. To investigate this issue further it would be nice if you can share some details about your environment, especially which SSSD and IPA versions are used on the client and the server and how the external group membership is defined on the IPA server. bye, Sumit > > Kind regards, > > Winny From pspacek at redhat.com Tue Dec 15 09:10:27 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 15 Dec 2015 10:10:27 +0100 Subject: [Freeipa-users] confused about replica role and use In-Reply-To: References: Message-ID: <566FD903.4070508@redhat.com> On 14.12.2015 19:32, Karl Forner wrote: > Hello, > >>From what I understood, a freeipa replica server is a kind of backup of > another freeipa server. > Both are usable by clients, and they will dynamically update their > information. > > But I do not understand how a client will make use of the replica if the > master server is down. > Naively I would imagine, that like for DNS servers, that you configure a > main freeipa server, and a secondary one in case the main one does not > respond, but I can not find how to do it. > Is this happening automagically ? Or this is not the way it is supposed to > be used ? All replicas should be listed in SRV records in DNS so clients will find them automatically. It should work out of the box if IPA manages primary DNS domain (--setup-dns parameter for ipa-{server,replica}-install + DNS delegation). In other cases you have to update SRV records manually. -- Petr^2 Spacek From f.zoske at euroimmun.de Tue Dec 15 10:58:09 2015 From: f.zoske at euroimmun.de (Zoske, Fabian) Date: Tue, 15 Dec 2015 10:58:09 +0000 Subject: [Freeipa-users] Cross Domain Trust Message-ID: I?ve setup an IPA-Server with a handful of clients and AD-Trust. The server is a CentOS7.1 with IPA4.1 and the clients are mostly Ubuntu Server 14.04 LTS. Our IPA-Domain is like ipa-domain.com and our AD-Domain is like ad-domain.local, but our user principals in AD are user at old-domain.com for backward compatibility. On the Ubuntu clients I can login with my AD-Credentials, but when trying to do the same on a joined CentOS Server I can?t login. In the logs I can see, that there is no KDC for OLD-DOMAIN.COM is found. Why does this scenario works on Ubuntu but not on CentOS? Can I do something about this? Best regards, Fabian -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.forner at gmail.com Tue Dec 15 12:33:11 2015 From: karl.forner at gmail.com (Karl Forner) Date: Tue, 15 Dec 2015 13:33:11 +0100 Subject: [Freeipa-users] confused about replica role and use Message-ID: >All replicas should be listed in SRV records in DNS so clients will find them >automatically. But then I must add the freeIPA DNS of the master AND the replica in resolv.conf ? Thanks, Karl From sbose at redhat.com Tue Dec 15 12:38:22 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 15 Dec 2015 13:38:22 +0100 Subject: [Freeipa-users] Cross Domain Trust In-Reply-To: References: Message-ID: <20151215123822.GB24928@p.redhat.com> On Tue, Dec 15, 2015 at 10:58:09AM +0000, Zoske, Fabian wrote: > I?ve setup an IPA-Server with a handful of clients and AD-Trust. > The server is a CentOS7.1 with IPA4.1 and the clients are mostly Ubuntu Server 14.04 LTS. > Our IPA-Domain is like ipa-domain.com and our AD-Domain is like ad-domain.local, but our user principals in AD are user at old-domain.com for backward compatibility. > > On the Ubuntu clients I can login with my AD-Credentials, but when trying to do the same on a joined CentOS Server I can?t login. > In the logs I can see, that there is no KDC for OLD-DOMAIN.COM is found. > > Why does this scenario works on Ubuntu but not on CentOS? > Can I do something about this? Are there any differences in /etc/krb5.conf on the Ubuntu client and on the CentOS servers? What name servers are configured? Typically the clients should use the IPA server as a name server. bye, Sumit > > Best regards, > Fabian > -- > 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 From harald.dunkel at aixigo.de Tue Dec 15 12:49:46 2015 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Tue, 15 Dec 2015 13:49:46 +0100 Subject: [Freeipa-users] freeipa-server-install fails to compare DNs in certificates In-Reply-To: <566FCBA2.3050604@aixigo.de> References: <566FCBA2.3050604@aixigo.de> Message-ID: <56700C6A.1070105@aixigo.de> Hi folks, apparently ipa-server-install (4.2) gets confused about the attribute sequence in the DNs of the certificates. If I use ipa-server-install --external-ca --subject="C=DE,O=example AG" then ipa's csr contains O=example AG, C=DE, CN=Certificate Authority The signed certificate contains C=DE, O=example AG, CN=Certificate Authority If I run ipa-server-install again to hand off the certificate chain, then the code in load_external_cert() (installutils.py) sees ca_subject = "CN=Certificate Authority,C=DE,O=example AG" subject = "CN=Certificate Authority,O=example AG,C=DE" : if subject == ca_subject: ca_nickname = nickname : if ca_nickname is None: raise ScriptError("IPA CA certificate not found in %s" % (", ".join(files))) The strings don't match and the certificate chain is rejected, even though it is valid. Please check https://tools.ietf.org/html/rfc5280#section-7.1 for reference. Can anybody reproduce this? What would you suggest to convince ipa 4.2 to accept valid certificate chains? Regards Harri From pspacek at redhat.com Tue Dec 15 12:54:05 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 15 Dec 2015 13:54:05 +0100 Subject: [Freeipa-users] confused about replica role and use In-Reply-To: References: Message-ID: <56700D6D.6030601@redhat.com> On 15.12.2015 13:33, Karl Forner wrote: >> All replicas should be listed in SRV records in DNS so clients will find them >> automatically. > > But then I must add the freeIPA DNS of the master AND the replica in > resolv.conf ? No, it is not necessary as long as you follow usual DNS rules - add all DNS servers into NS records in the parent domain. If DNS domain managed by your IPA is "ipa.example.com" then you need to update NS records in parent DNS zone, which is likely "example.com". -- Petr^2 Spacek From abokovoy at redhat.com Tue Dec 15 13:51:10 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 15 Dec 2015 15:51:10 +0200 Subject: [Freeipa-users] freeipa-server-install fails to compare DNs in certificates In-Reply-To: <56700C6A.1070105@aixigo.de> References: <566FCBA2.3050604@aixigo.de> <56700C6A.1070105@aixigo.de> Message-ID: <20151215135110.GF4620@redhat.com> On Tue, 15 Dec 2015, Harald Dunkel wrote: >Hi folks, > >apparently ipa-server-install (4.2) gets confused about the >attribute sequence in the DNs of the certificates. If I use > > ipa-server-install --external-ca --subject="C=DE,O=example AG" > >then ipa's csr contains > > O=example AG, C=DE, CN=Certificate Authority > >The signed certificate contains > > C=DE, O=example AG, CN=Certificate Authority > >If I run ipa-server-install again to hand off the certificate >chain, then the code in load_external_cert() (installutils.py) >sees > ca_subject = "CN=Certificate Authority,C=DE,O=example AG" > subject = "CN=Certificate Authority,O=example AG,C=DE" > : > if subject == ca_subject: > ca_nickname = nickname > : > if ca_nickname is None: > raise ScriptError("IPA CA certificate not found in %s" % (", ".join(files))) > >The strings don't match and the certificate chain is rejected, >even though it is valid. > >Please check https://tools.ietf.org/html/rfc5280#section-7.1 for >reference. > > >Can anybody reproduce this? What would you suggest to convince >ipa 4.2 to accept valid certificate chains? Could you please file a bug about it? -- / Alexander Bokovoy From simo at redhat.com Tue Dec 15 14:08:20 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 15 Dec 2015 09:08:20 -0500 Subject: [Freeipa-users] confused about replica role and use In-Reply-To: References: Message-ID: <1450188500.17418.168.camel@redhat.com> On Mon, 2015-12-14 at 19:32 +0100, Karl Forner wrote: > Hello, > > >From what I understood, a freeipa replica server is a kind of backup of > another freeipa server. > Both are usable by clients, and they will dynamically update their > information. > > But I do not understand how a client will make use of the replica if the > master server is down. SSSD mostly manages discovery of servers, it is normally configure with the name _srv_ + an actual name as fallback. SSSD also feeds the information to kerberos libraries via a plugin. If you are using another client yuou must make sure it is capable of discovering servers via SRV records, or you have to configure the various servers explicitly. > Naively I would imagine, that like for DNS servers, that you configure a > main freeipa server, and a secondary one in case the main one does not > respond, but I can not find how to do it. > Is this happening automagically ? Yes, if you use ipa-client-install and do not force to use a specific server. > Or this is not the way it is supposed to be used ? This is what replicas are for, redundancy, and load sharing. Simo. -- Simo Sorce * Red Hat, Inc * New York From wdh at dds.nl Tue Dec 15 14:44:46 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Tue, 15 Dec 2015 15:44:46 +0100 Subject: [Freeipa-users] AD group members In-Reply-To: <20151215085904.GC27845@p.redhat.com> References: <566EF2AA.7080601@dds.nl> <20151215085904.GC27845@p.redhat.com> Message-ID: <5670275E.3030401@dds.nl> An HTML attachment was scrubbed... URL: From harald.dunkel at aixigo.de Tue Dec 15 14:56:06 2015 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Tue, 15 Dec 2015 15:56:06 +0100 Subject: [Freeipa-users] freeipa-server-install fails to compare DNs in certificates In-Reply-To: <20151215135110.GF4620@redhat.com> References: <566FCBA2.3050604@aixigo.de> <56700C6A.1070105@aixigo.de> <20151215135110.GF4620@redhat.com> Message-ID: <56702A06.2010500@aixigo.de> On 12/15/2015 02:51 PM, Alexander Bokovoy wrote: > Could you please file a bug about it? I tried, but trac refused my username/password for redhat.com. Due to greylisting I haven't received the confirmation request by EMail, either. Anyway, I have to continue getting ipa running. Filing a bug doesn't help to work around the problem. Regards Harri From abokovoy at redhat.com Tue Dec 15 15:04:28 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 15 Dec 2015 17:04:28 +0200 Subject: [Freeipa-users] freeipa-server-install fails to compare DNs in certificates In-Reply-To: <56702A06.2010500@aixigo.de> References: <566FCBA2.3050604@aixigo.de> <56700C6A.1070105@aixigo.de> <20151215135110.GF4620@redhat.com> <56702A06.2010500@aixigo.de> Message-ID: <20151215150428.GG4620@redhat.com> On Tue, 15 Dec 2015, Harald Dunkel wrote: >On 12/15/2015 02:51 PM, Alexander Bokovoy wrote: >> Could you please file a bug about it? > >I tried, but trac refused my username/password for redhat.com. >Due to greylisting I haven't received the confirmation request >by EMail, either. > >Anyway, I have to continue getting ipa running. Filing a >bug doesn't help to work around the problem. It makes possible others to see your specific details as this is the first time we get such bug report. -- / Alexander Bokovoy From m3freak at thesandhufamily.ca Tue Dec 15 15:15:50 2015 From: m3freak at thesandhufamily.ca (Ranbir) Date: Tue, 15 Dec 2015 10:15:50 -0500 Subject: [Freeipa-users] Any recent guides for Postfix and IPA integration? In-Reply-To: <1450119097.17418.162.camel@redhat.com> References: <1449865759.18285.9.camel@thesandhufamily.ca> <1449873160.18285.23.camel@thesandhufamily.ca> <1450110607.15210.47.camel@thesandhufamily.ca> <1450118335.15210.52.camel@thesandhufamily.ca> <1450119097.17418.162.camel@redhat.com> Message-ID: <1450192550.31930.11.camel@thesandhufamily.ca> On Mon, 2015-12-14 at 13:51 -0500, Simo Sorce wrote: > There are a few ways to go about it. > > another way is to use a custom subtree + schema to store these emails > only. > > It really depends on what kind of tools you want to use to manage the > information too. I ended up creating normal users, set passwords for those that needed them (some are public shared IMAP folders and so don't need passwords) and set all of their shells to /sbin/nologin. None of them have the right to ssh, gdm, etc. The thought of creating a custom schema, OIDs and whatnot sent me into fits. freeipa is supposed to make my life easier, not harder, so I took the simpler route. In a different setting a custom schema would be warranted. -- Ranbir -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From sbose at redhat.com Tue Dec 15 15:19:33 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 15 Dec 2015 16:19:33 +0100 Subject: [Freeipa-users] AD group members In-Reply-To: <5670275E.3030401@dds.nl> References: <566EF2AA.7080601@dds.nl> <20151215085904.GC27845@p.redhat.com> <5670275E.3030401@dds.nl> Message-ID: <20151215151933.GC24928@p.redhat.com> On Tue, Dec 15, 2015 at 03:44:46PM +0100, Winfried de Heiden wrote: > Hi all, > > Even more strange, logging in using SSH public/private keys the problem > disappears and all groups are available! > > Strange.....?! this is expected, because if you use SSH keys no PAC is involved and hence the PAC responder cannot remove group-memberships which are not listed in the PAC. > > RHEL 7.2 with IPA 4.2, sssd 1.13.0-40 last updated Friday December 11 > RHEL 7.2 with sssd 1.13.0-40 as an IPA client > RHEL 6.7 with sssd 1.12.4-47 as an IPA client Do I understand correctly that with 1.12.4-47 the groups are always correct while with 1.13.0-40 the groups are missing when not using SSH keys? bye, Sumit > > Winny > > Op 15-12-15 om 09:59 schreef Sumit Bose: > > On Mon, Dec 14, 2015 at 05:47:38PM +0100, Winfried de Heiden wrote: > > Using an EL7 client, lot's of times the IPA (posix) groups are missing, > or partly missing. Doing some debugging, sssd_pac.log shows: > > (Mon Dec 14 17:19:08 2015) [sssd[pac]] [pac_user_get_grp_info] (0x2000): Group with SID [S-1-5-21-1802245919-2979536009-1783284443-51509] is not in the PAC anymore, membership must be removed. > (Mon Dec 14 17:19:08 2015) [sssd[pac]] [pac_user_get_grp_info] (0x2000): Group with SID [S-1-5-21-1802245919-2979536009-1783284443-51508] is not in the PAC anymore, membership must be removed. > > These sids are the groups I am missing. What is happening here??? > > Originally the PAC was the only source for the group-membership data for > users coming from AD. To be able to be a member of IPA groups the IPA > KDC added SIDs of IPA groups the AD user is a member of. > > With EL7.1 SSSD is able to read group-membership data on its own if the > IPA server is running on 7.1 or newer as well. If this is your case it > looks like there is a disconnect between how the IPA KDC and SSSD > determine the group memberships for the given user. > > To investigate this issue further it would be nice if you can share some > details about your environment, especially which SSSD and IPA versions > are used on the client and the server and how the external group > membership is defined on the IPA server. > > bye, > Sumit > > > Kind regards, > > Winny > From mkosek at redhat.com Tue Dec 15 15:40:02 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 15 Dec 2015 16:40:02 +0100 Subject: [Freeipa-users] FreeIPA 4.2 released in RHEL-7.2! In-Reply-To: <564EEB87.7080805@redhat.com> References: <564EEB87.7080805@redhat.com> Message-ID: <56703452.30608@redhat.com> On 11/20/2015 10:44 AM, Martin Kosek wrote: > Hello, > > As some of you noticed already, RHEL-7.2 with FreeIPA rebased to version 4.2 > was released yesterday! Let me just paste couple information sources if you > want to know more: > > RHEL respective release notes chapter: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.2_Release_Notes/authentication_and_interoperability.html > > > Knowledge Base with brief summary of new features > https://access.redhat.com/solutions/1986213 > > Related documentation books: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html > > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/index.html > > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/index.html > > > > Also, CentOS project already announced that CentOS-7.2 is in works: > http://seven.centos.org/2015/11/rhel-7-2-released-today/ > > Enjoy! Looking at https://lists.centos.org/pipermail/centos-announce/2015-December/021518.html CentOS repos based on RHEL-7.2 with FreeIPA 4.2 should be ready too: http://mirror.centos.org/centos/7/os/x86_64/Packages/ Martin From igreen at redhat.com Tue Dec 15 15:56:57 2015 From: igreen at redhat.com (Ilan Green) Date: Tue, 15 Dec 2015 10:56:57 -0500 (EST) Subject: [Freeipa-users] Freeradius, IPA network switch authentication authorization In-Reply-To: <668710913.35135431.1450194847009.JavaMail.zimbra@redhat.com> Message-ID: <815317789.35144681.1450195017114.JavaMail.zimbra@redhat.com> Has anyone ever set Freeradius & IPA for network devices like Cisco and Juniper. Having the need to provide the network device back with the authorization level e.g. for Cisco 1 to 15. This seems similar to some extent to the following: https://www.redhat.com/archives/freeipa-users/2013-September/msg00058.html Suggesting to implement it within the Freeradius. Question is whether anyone has gone beyond it and has an example for such an implementation? Thanks, Ilan Green Senior Technical Account Manager - EMEA Red Hat Mobile (+972) 52 3403218 email: igreen at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wdh at dds.nl Tue Dec 15 16:02:43 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Tue, 15 Dec 2015 17:02:43 +0100 Subject: [Freeipa-users] AD group members In-Reply-To: <20151215151933.GC24928@p.redhat.com> References: <566EF2AA.7080601@dds.nl> <20151215085904.GC27845@p.redhat.com> <5670275E.3030401@dds.nl> <20151215151933.GC24928@p.redhat.com> Message-ID: <567039A3.7020103@dds.nl> An HTML attachment was scrubbed... URL: From james.masson at jmips.co.uk Tue Dec 15 16:18:01 2015 From: james.masson at jmips.co.uk (James Masson) Date: Tue, 15 Dec 2015 16:18:01 +0000 Subject: [Freeipa-users] IPA 4.2 - installer changes for --external-ca Message-ID: <56703D39.2060608@jmips.co.uk> IPA 4.2 hit the Centos 7 mirrors a day or two ago. It looks like the behaviour of the installer has changed somewhat with regards to the 2 phase --external-ca install Previously, we ran: command => "/sbin/ipa-server-install -U -a '${ipa_admin_pwd}' -p '${ipa_admin_pwd}' --hostname='${::fqdn}' -r '${ipa_realm}' -n '${::domain}' --mkhomedir --setup-dns --forwarder=8.8.8.8 --external-ca", then command => "/sbin/ipa-server-install -p ${ipa_admin_pwd} --external-cert-file=/root/ipa.crt --external-cert-file=/etc/pki/ca-trust/source/anchors/root_ca.crt", this worked fine. The behaviour on IPA 4.2 is different - it will leave you without a DNS server if you use the above commands. It doesn't seem to pass some options through to the 2nd phase installer, one of which is the DNS configuration. We've now switched to this. $ipa_install_command = "/sbin/ipa-server-install -U -a '${ipa_admin_pwd}' -p '${ipa_admin_pwd}' -r '${ipa_realm}'" command => "${ipa_install_command} --hostname='${::fqdn}' -n '${::domain}' --external-ca", command => "${ipa_install_command} --external-cert-file=/root/ipa.crt --external-cert-file=/etc/pki/ca-trust/source/anchors/root_ca.crt --mkhomedir --setup-dns --forwarder=8.8.8.8 ", It seems you have to supply more information to the phase2 installer than in IPA 4.1. We do more than 10 installs of IPA per day as part of CI, I think now we're back to a working configuration again. Hopefully this will help others who come along this path. James M From wdh at dds.nl Tue Dec 15 16:22:37 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Tue, 15 Dec 2015 17:22:37 +0100 Subject: [Freeipa-users] AD group members In-Reply-To: <20151215151933.GC24928@p.redhat.com> References: <566EF2AA.7080601@dds.nl> <20151215085904.GC27845@p.redhat.com> <5670275E.3030401@dds.nl> <20151215151933.GC24928@p.redhat.com> Message-ID: <56703E4D.20204@dds.nl> An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Dec 15 16:38:08 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 15 Dec 2015 11:38:08 -0500 (EST) Subject: [Freeipa-users] AD group members In-Reply-To: <56703E4D.20204@dds.nl> References: <566EF2AA.7080601@dds.nl> <20151215085904.GC27845@p.redhat.com> <5670275E.3030401@dds.nl> <20151215151933.GC24928@p.redhat.com> <56703E4D.20204@dds.nl> Message-ID: <1225908617.48795327.1450197488859.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi, > > If PAC is not being used using key, how is group membership determined? By asking IPA master to give list of groups AD user belongs to. The complexity of this process makes it hard to have full list of groups available in advance in all cases. MS-PAC record in Kerberos ticket has its feature that AD DC will put the correct and full list of groups the user is a member of at the time of issuing TGT, signed by the AD DC's signature. This means after validating the ticket we can trust its content for caching. In case of no PAC data available we have to resort to less precise methods that would give incomplete information for some of situations like incomplete GC content for multidomain AD forests. > Also: it feels like the Linux client is contacting AD to obtain a Kerberos > ticket and not the IPA-server. (for AD users). Is that true? Yes, how would you imagine doing it differently? AD DCs are authoritative for their users, not IPA KDC. This is basic feature of Kerberos protocol. With IPA 4.2 on systems like RHEL 7.2/CentOS 7.2/Fedora 23 you can configure MIT Kerberos to use MS-KKDC proxy provided by IPA. In such case IPA masters can be used as Kerberos proxy but the actual authentication decision is done by AD DCs anyway. -- / Alexander Bokovoy From sbose at redhat.com Tue Dec 15 17:55:41 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 15 Dec 2015 18:55:41 +0100 Subject: [Freeipa-users] AD group members In-Reply-To: <1225908617.48795327.1450197488859.JavaMail.zimbra@redhat.com> References: <566EF2AA.7080601@dds.nl> <20151215085904.GC27845@p.redhat.com> <5670275E.3030401@dds.nl> <20151215151933.GC24928@p.redhat.com> <56703E4D.20204@dds.nl> <1225908617.48795327.1450197488859.JavaMail.zimbra@redhat.com> Message-ID: <20151215175541.GD24928@p.redhat.com> On Tue, Dec 15, 2015 at 11:38:08AM -0500, Alexander Bokovoy wrote: > > > ----- Original Message ----- > > Hi, > > > > If PAC is not being used using key, how is group membership determined? > By asking IPA master to give list of groups AD user belongs to. > The complexity of this process makes it hard to have full list of groups available in advance in all cases. > MS-PAC record in Kerberos ticket has its feature that AD DC will put the correct and full list of groups > the user is a member of at the time of issuing TGT, signed by the AD DC's signature. This means after validating > the ticket we can trust its content for caching. In case of no PAC data available we have to resort to less precise > methods that would give incomplete information for some of situations like incomplete GC content for multidomain > AD forests. > > > Also: it feels like the Linux client is contacting AD to obtain a Kerberos > > ticket and not the IPA-server. (for AD users). Is that true? > Yes, how would you imagine doing it differently? AD DCs are authoritative for their users, not IPA KDC. > This is basic feature of Kerberos protocol. This is true for getting a TGT for the user, but when it comes to authentication against an IPA client there is a step which involves the IPA KDC as well. Either if you use Kerberos/GSSAPI authentication, e.g. with ssh, or password authentication, in both cases a Kerberos service ticket for the IPA client is needed which is issued by the IPA KDC and here is were the SIDs for IPA group memberships are added. In the ssh case the ssh client will ask the IPA KDC for the service ticket by sending a valid TGT or cross-realm TGT in the trust case. In the password authentication case SSSD will ask for the same service ticket after getting a TGT for the user from the AD DC. This step is called validation because SSSD needs a prove that the TGT was really issued by a valid KDC. A user calling kinit can but pretty sure that the KDC is valid because the password is a shared secret between the user and the KDC in this case. A service like SSSD cannot be sure that the user is not an attacker which spoofed e.g. DNS and let SSSD talk to a invalid KDC which of course will issue TGTs for the attacker. To make sure the ticket is valid SSSD uses the shared secret it has with the valid KDC, the host keys in /etc/krb5.keytab, to validate the TGT by requesting a service ticket for the host itself. If the service ticket can be decrypt with the keys in the keytab SSSD can be pretty sure that the service ticket and hence the TGT are valid. Coming back to the original issue with the missing group. Can you share the definition of the IPA external group and the related IPA POSIX group for a group which is still present and one which got deleted. The output of 'ipa group-show --all --raw group_name' should be sufficient for a start. Feel free to send the output to me directly if it contains sensitive data. bye, Sumit > > With IPA 4.2 on systems like RHEL 7.2/CentOS 7.2/Fedora 23 you can configure MIT Kerberos to use MS-KKDC proxy provided by IPA. > In such case IPA masters can be used as Kerberos proxy but the actual authentication decision is done by AD DCs anyway. > -- > / Alexander Bokovoy From jhrozek at redhat.com Tue Dec 15 21:21:34 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 15 Dec 2015 22:21:34 +0100 Subject: [Freeipa-users] Announcing SSSD 1.13.3 Message-ID: <20151215212134.GA4733@hendrix> == SSSD 1.13.3 === The SSSD team is proud to announce the release of version 1.13.3 of the System Security Services Daemon. As always, the source is available from https://fedorahosted.org/sssd RPM packages will be made available for Fedora shortly. == Feedback == Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users == Highlights == * A bug that prevented user lookups and logins after migration from winsync to IPA-AD trusts was fixed * The OCSP certificate validation checks are enabled for smartcard logins if SSSD was compiled with the NSS crypto library. * A bug that prevented the ignore_group_members option from working correctly in AD provider setups that use a dedicated primary group (as opposed to a user-private group) was fixed * Offline detection and offline login timeouts were improved for AD users logging in from a domain trusted by an IPA server * The AD provider supports setting up autofs_provider=ad * Several usability improvements to our debug messages == Packaging Changes == * The p11_child helper binary is able to run completely unprivileged and no longer requires the setgid bit to be set == Documentation Changes == * A new option certificate_verification was added. This option allows the administrator to disable OCSP checks in case the OCSP server is not reachable == Tickets Fixed == https://fedorahosted.org/sssd/ticket/1632 [RFE] Unable to use AD provider for automount lookups https://fedorahosted.org/sssd/ticket/1943 convert sudo timer to be_ptask https://fedorahosted.org/sssd/ticket/2672 sudo: reload hostinfo when going online https://fedorahosted.org/sssd/ticket/2732 Add Integration tests for local views feature https://fedorahosted.org/sssd/ticket/2747 get_object_from_cache() does not handle services https://fedorahosted.org/sssd/ticket/2755 Review p11_child hardening https://fedorahosted.org/sssd/ticket/2787 We should mention SSS_NSS_USE_MEMCACHE in man sssd.conf(5) as well https://fedorahosted.org/sssd/ticket/#2796 fix man page for sssd-ldap https://fedorahosted.org/sssd/ticket/2801 Check next certificate on smart card if first is not valid https://fedorahosted.org/sssd/ticket/2812 Smartcard login when certificate on the card is revoked and ocsp check enabled is not supported https://fedorahosted.org/sssd/ticket/2830 Try to suppress "Could not parse domain SID from [(null)]" for IPA users https://fedorahosted.org/sssd/ticket/2846 Inform about SSSD PAC timeout better https://fedorahosted.org/sssd/ticket/2868 AD provider and ignore_group_members=True might cause flaky group memberships https://fedorahosted.org/sssd/ticket/2874 sssd: [sysdb_add_user] (0x0400): Error: 17 (File exists) == Detailed Changelog == Dan Lavu (1): * Clarify that subdomains always use service discovery Jakub Hrozek (7): * Upgrading the version for the 1.13.3 release * DP: Do not confuse static analysers with dead code * BUILD: Only install polkit rules if the directory is available * IPA: Use search timeout, not enum timeout for searching overrides * AD: Add autofs provider * MAN: Clarify when should TGs be disabled for group nesting restriction * Update translations for the 1.13.3 release Lukas Slebodnik (2): * sbus_codegen_tests: Use portable definition of large constants * DEBUG: Add missing new lines Michal ?idek (1): * MAN: sssd.conf should mention SSS_NSS_USE_MEMCACHE Pavel B?ezina (22): * SYSDB: Add missing include to sysdb_services.h * LDAP: Mark globals in ldap_opts.h as extern * AD: Mark globals in ad_opts.h as extern * IPA: Mark globals in ipa_opts.h as extern * KRB5: Mark globals in krb5_opts.h as extern * SUDO: convert periodical refreshes to be_ptask * SUDO: move refreshes from sdap_sudo.c to sdap_sudo_refresh.c * SUDO: move offline check to handler * SUDO: simplify error handling * SUDO: fix sdap_id_op logic * SUDO: fix tevent style * SUDO: fix sdap_sudo_smart_refresh_recv() * SUDO: sdap_sudo_load_sudoers improve iterator * SUDO: set USN inside sdap_sudo_refresh request * SUDO: built host filter inside sdap_sudo_refresh request * SUDO: do not imitate full refresh if usn is unknown in smart refresh * SUDO: fix potential memory leak in sdap_sudo_init * SUDO: obtain host information when going online * SUDO: remove finalizer * SUDO: make sdap_sudo_handler static * SUDO: use size_t instead of int in for cycles * SUDO: get srv_opts after we are connected Pavel Reichl (1): * sysdb-tests: Fix warning - incompatible pointer type Petr Cech (2): * IPA_PROVIDER: Explicit no handle of services * KRB5_CHILD: Debug logs for PAC timeout Sumit Bose (7): * IPA: fix override with the same name * p11: allow p11_child to run completely unprivileged * p11: check if cert is valid before selecting it * p11: enable ocsp checks * ldap: skip sdap_save_grpmem() if ignore_group_members is set * initgr: only search for primary group if it is not already cached * LDAP: check early for missing SID in mapping check From f.zoske at euroimmun.de Tue Dec 15 23:29:46 2015 From: f.zoske at euroimmun.de (Zoske, Fabian) Date: Tue, 15 Dec 2015 23:29:46 +0000 Subject: [Freeipa-users] Cross Domain Trust In-Reply-To: <20151215123822.GB24928@p.redhat.com> References: <20151215123822.GB24928@p.redhat.com> Message-ID: <870BF334-7620-48C6-8CE6-64D9EB7091B2@euroimmun.de> In the Ubuntu krb5.conf are 2 lines more: udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} The nameservers on both system types are identical and pointing to our AD-Domain Controller. On the AD-Servers the ipa-domain.com is a conditional forwarder to the IPA-Server. I changed the name server configuration on a CentOS just to be sure, but it doesn?t had any effect. Best regards, Fabian > On 15 Dec 2015, at 13:38, Sumit Bose wrote: > > On Tue, Dec 15, 2015 at 10:58:09AM +0000, Zoske, Fabian wrote: >> I?ve setup an IPA-Server with a handful of clients and AD-Trust. >> The server is a CentOS7.1 with IPA4.1 and the clients are mostly Ubuntu Server 14.04 LTS. >> Our IPA-Domain is like ipa-domain.com and our AD-Domain is like ad-domain.local, but our user principals in AD are user at old-domain.com for backward compatibility. >> >> On the Ubuntu clients I can login with my AD-Credentials, but when trying to do the same on a joined CentOS Server I can?t login. >> In the logs I can see, that there is no KDC for OLD-DOMAIN.COM is found. >> >> Why does this scenario works on Ubuntu but not on CentOS? >> Can I do something about this? > > Are there any differences in /etc/krb5.conf on the Ubuntu client and on > the CentOS servers? > > What name servers are configured? Typically the clients should use the > IPA server as a name server. > > bye, > Sumit > >> >> Best regards, >> Fabian > >> -- >> 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 > From wdh at dds.nl Wed Dec 16 08:46:37 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Wed, 16 Dec 2015 09:46:37 +0100 Subject: [Freeipa-users] AD group members In-Reply-To: <20151215175541.GD24928@p.redhat.com> References: <566EF2AA.7080601@dds.nl> <20151215085904.GC27845@p.redhat.com> <5670275E.3030401@dds.nl> <20151215151933.GC24928@p.redhat.com> <56703E4D.20204@dds.nl> <1225908617.48795327.1450197488859.JavaMail.zimbra@redhat.com> <20151215175541.GD24928@p.redhat.com> Message-ID: <567124ED.9020802@dds.nl> An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed Dec 16 09:01:05 2015 From: sbose at redhat.com (Sumit Bose) Date: Wed, 16 Dec 2015 10:01:05 +0100 Subject: [Freeipa-users] AD group members In-Reply-To: <567124ED.9020802@dds.nl> References: <566EF2AA.7080601@dds.nl> <20151215085904.GC27845@p.redhat.com> <5670275E.3030401@dds.nl> <20151215151933.GC24928@p.redhat.com> <56703E4D.20204@dds.nl> <1225908617.48795327.1450197488859.JavaMail.zimbra@redhat.com> <20151215175541.GD24928@p.redhat.com> <567124ED.9020802@dds.nl> Message-ID: <20151216090105.GG24928@p.redhat.com> On Wed, Dec 16, 2015 at 09:46:37AM +0100, Winfried de Heiden wrote: > Hi all, > > Adding AD-users to an IPA external group seems to be problematic. However, > adding AD-groups (with AD-users as members) to a IPA external groups seems to > work well. Four group were created and all are shown. Thank you, this is a very useful information, I hope that I will be able to reproduce the issue with this and the data you send me by private email. bye, Sumit > > Smell a bit like a bug, does't it? > > Winny From wdh at dds.nl Wed Dec 16 10:20:54 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Wed, 16 Dec 2015 11:20:54 +0100 Subject: [Freeipa-users] AD group members In-Reply-To: <20151216090105.GG24928@p.redhat.com> References: <566EF2AA.7080601@dds.nl> <20151215085904.GC27845@p.redhat.com> <5670275E.3030401@dds.nl> <20151215151933.GC24928@p.redhat.com> <56703E4D.20204@dds.nl> <1225908617.48795327.1450197488859.JavaMail.zimbra@redhat.com> <20151215175541.GD24928@p.redhat.com> <567124ED.9020802@dds.nl> <20151216090105.GG24928@p.redhat.com> Message-ID: <56713B06.10701@dds.nl> An HTML attachment was scrubbed... URL: From harald.dunkel at aixigo.de Wed Dec 16 10:27:38 2015 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Wed, 16 Dec 2015 11:27:38 +0100 Subject: [Freeipa-users] freeipa-server-install fails to compare DNs in certificates In-Reply-To: <20151215150428.GG4620@redhat.com> References: <566FCBA2.3050604@aixigo.de> <56700C6A.1070105@aixigo.de> <20151215135110.GF4620@redhat.com> <56702A06.2010500@aixigo.de> <20151215150428.GG4620@redhat.com> Message-ID: <56713C9A.6060608@aixigo.de> On 12/15/2015 04:04 PM, Alexander Bokovoy wrote: > It makes possible others to see your specific details as this is the > first time we get such bug report. Done: https://bugzilla.redhat.com/show_bug.cgi?id=1292042 Now what would you suggest as a workaround? From wouter.hummelink at kpn.com Wed Dec 16 10:33:17 2015 From: wouter.hummelink at kpn.com (wouter.hummelink at kpn.com) Date: Wed, 16 Dec 2015 10:33:17 +0000 Subject: [Freeipa-users] Active Directory Sites and IPA-AD-Trust Message-ID: <2CA71D6C07ADB544847562573DC6BF061859C92D@CPEMS-KPN309.KPNCNL.LOCAL> Hi All, While TCPdumping logins on an IPA client using an AD account I found out that SSSD doesn't take AD Sites into account. I see a DNS lookup for _kerberos._udp. and _kerberos._tcp. and then a Kerberos attempt at one or more of the AD servers (both the local and non-local ones). While this isn't a huge problem it does delay logins where communication with the AD kdc is required. Is there a way to get sssd to use the proper site for trusted AD domains? Met vriendelijke groet, Wouter Hummelink Cloud Engineer [Description: Beschrijving: Beschrijving: cid:image003.gif at 01CC7CE9.FCFEC140] KPN IT Solutions Platform Organisation Cloud Services Mail: wouter.hummelink at kpn.com Telefoon: +31 (0)6 1288 2447 [cid:image002.png at 01D0DA65.706AE4B0] P Save Paper - Do you really need to print this e-mail? ********************************************************************************************************************************************************* KPN IT SOLUTIONS is de 'handelsnaam' voor KPN Corporate Market BV, Handelsregister 52959597 Amsterdam The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you. ********************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2045 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 49569 bytes Desc: image002.png URL: From sbose at redhat.com Wed Dec 16 11:19:48 2015 From: sbose at redhat.com (Sumit Bose) Date: Wed, 16 Dec 2015 12:19:48 +0100 Subject: [Freeipa-users] Active Directory Sites and IPA-AD-Trust In-Reply-To: <2CA71D6C07ADB544847562573DC6BF061859C92D@CPEMS-KPN309.KPNCNL.LOCAL> References: <2CA71D6C07ADB544847562573DC6BF061859C92D@CPEMS-KPN309.KPNCNL.LOCAL> Message-ID: <20151216111948.GA482@p.redhat.com> On Wed, Dec 16, 2015 at 10:33:17AM +0000, wouter.hummelink at kpn.com wrote: > Hi All, > > While TCPdumping logins on an IPA client using an AD account I found out that SSSD doesn't take AD Sites into account. I see a DNS lookup for _kerberos._udp. and _kerberos._tcp. and then a Kerberos attempt at one or more of the AD servers (both the local and non-local ones). > > While this isn't a huge problem it does delay logins where communication with the AD kdc is required. > > Is there a way to get sssd to use the proper site for trusted AD domains? I'm afraid currently there is no way for IPA clients. If the SSSD client is directly joined to a AD domain, SSSD tries to determine the site the client belongs to and prefers DC form this site for all communications. An IPA client gets all information from the IPA server (there is a similar concept to sites in IPA but this is still wip). Only for password authentication SSSD will directly connect to an AD DC. Currently this happens completely inside libkrb5 which by default is configured to do DNS SRV lookups to find a suitable DC (dns_lookup_kdc = true in krb5.conf). Since libkrb5 is not aware fo sites it will just do the plain _kerberos._udp. you see in the dump. The only way to get around this would be to add a configuration section for the ad.domain in krb5.conf and list suitable DC here. But this of course has a number of drawbacks. HTH bye, Sumit > > > Met vriendelijke groet, > > Wouter Hummelink > Cloud Engineer > [Description: Beschrijving: Beschrijving: cid:image003.gif at 01CC7CE9.FCFEC140] > KPN IT Solutions > Platform Organisation Cloud Services > Mail: wouter.hummelink at kpn.com > Telefoon: +31 (0)6 1288 2447 > [cid:image002.png at 01D0DA65.706AE4B0] > P Save Paper - Do you really need to print this e-mail? > ********************************************************************************************************************************************************* > KPN IT SOLUTIONS is de 'handelsnaam' voor KPN Corporate Market BV, Handelsregister 52959597 Amsterdam > The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. > Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons > and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately > and delete the material. 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 From abokovoy at redhat.com Wed Dec 16 11:27:20 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 16 Dec 2015 13:27:20 +0200 Subject: [Freeipa-users] freeipa-server-install fails to compare DNs in certificates In-Reply-To: <56713C9A.6060608@aixigo.de> References: <566FCBA2.3050604@aixigo.de> <56700C6A.1070105@aixigo.de> <20151215135110.GF4620@redhat.com> <56702A06.2010500@aixigo.de> <20151215150428.GG4620@redhat.com> <56713C9A.6060608@aixigo.de> Message-ID: <20151216112720.GK4620@redhat.com> On Wed, 16 Dec 2015, Harald Dunkel wrote: >On 12/15/2015 04:04 PM, Alexander Bokovoy wrote: > >> It makes possible others to see your specific details as this is the >> first time we get such bug report. > >Done: https://bugzilla.redhat.com/show_bug.cgi?id=1292042 > >Now what would you suggest as a workaround? I've asked you to provide ipaserver-install.log in the bug. Without it it is a bit hard to see how to help. Let's continue in the bug. -- / Alexander Bokovoy From harald.dunkel at aixigo.de Wed Dec 16 12:07:19 2015 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Wed, 16 Dec 2015 13:07:19 +0100 Subject: [Freeipa-users] freeipa-server-install fails to compare DNs in certificates In-Reply-To: <20151216112720.GK4620@redhat.com> References: <566FCBA2.3050604@aixigo.de> <56700C6A.1070105@aixigo.de> <20151215135110.GF4620@redhat.com> <56702A06.2010500@aixigo.de> <20151215150428.GG4620@redhat.com> <56713C9A.6060608@aixigo.de> <20151216112720.GK4620@redhat.com> Message-ID: <567153F7.7070501@aixigo.de> On 12/16/2015 12:27 PM, Alexander Bokovoy wrote: > I've asked you to provide ipaserver-install.log in the bug. Without it > it is a bit hard to see how to help. Let's continue in the bug. Bug report has been updated. From giulio at di.unimi.it Wed Dec 16 14:54:32 2015 From: giulio at di.unimi.it (Giulio Casella) Date: Wed, 16 Dec 2015 15:54:32 +0100 Subject: [Freeipa-users] Password expiration after reset Message-ID: <56717B28.6090106@di.unimi.it> Hi guys, I'm trying to populate FreeIPA (4.2.3) using API, but after user creation (and password has been set) user must change password at first logon. Same beahviour after a password change by admin. Although this behaviour is desirable in many situations, I can't afford it, I've got to import tens of thousands users, and I can't force them to change their password. How can I bypass this password change? And, by the way: is there a way to disable password expiration? Thanks in advance, Giulio From abokovoy at redhat.com Wed Dec 16 15:07:32 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 16 Dec 2015 17:07:32 +0200 Subject: [Freeipa-users] Password expiration after reset In-Reply-To: <56717B28.6090106@di.unimi.it> References: <56717B28.6090106@di.unimi.it> Message-ID: <20151216150732.GO4620@redhat.com> On Wed, 16 Dec 2015, Giulio Casella wrote: >Hi guys, >I'm trying to populate FreeIPA (4.2.3) using API, but after user >creation (and password has been set) user must change password at >first logon. Same beahviour after a password change by admin. > >Although this behaviour is desirable in many situations, I can't >afford it, I've got to import tens of thousands users, and I can't >force them to change their password. >How can I bypass this password change? > >And, by the way: is there a way to disable password expiration? http://www.freeipa.org/page/New_Passwords_Expired If you are using API to create users and set their passwords, you can use technique like described here: https://www.redhat.com/archives/freeipa-users/2012-June/msg00360.html -- / Alexander Bokovoy From giulio at di.unimi.it Wed Dec 16 16:06:51 2015 From: giulio at di.unimi.it (Giulio Casella) Date: Wed, 16 Dec 2015 17:06:51 +0100 Subject: [Freeipa-users] Password expiration after reset In-Reply-To: <20151216150732.GO4620@redhat.com> References: <56717B28.6090106@di.unimi.it> <20151216150732.GO4620@redhat.com> Message-ID: <56718C1B.2010305@di.unimi.it> Il 16/12/2015 16:07, Alexander Bokovoy ha scritto: > On Wed, 16 Dec 2015, Giulio Casella wrote: >> Hi guys, >> I'm trying to populate FreeIPA (4.2.3) using API, but after user >> creation (and password has been set) user must change password at >> first logon. Same beahviour after a password change by admin. >> >> Although this behaviour is desirable in many situations, I can't >> afford it, I've got to import tens of thousands users, and I can't >> force them to change their password. >> How can I bypass this password change? >> >> And, by the way: is there a way to disable password expiration? > http://www.freeipa.org/page/New_Passwords_Expired > > If you are using API to create users and set their passwords, you can > use technique like described here: > https://www.redhat.com/archives/freeipa-users/2012-June/msg00360.html > Thank you for the info Alexander, I wasn't aware of the page /ipa/session/change_password. After creating a user via API in the usual way (json submission to /ipa/session/json) I can perform a password change submitting user credential to /ipa/session/change_password, thus resetting password expiration accordingly to system settings. It works like a charme. Thank you again, Giulio. From karl.forner at gmail.com Wed Dec 16 17:34:58 2015 From: karl.forner at gmail.com (Karl Forner) Date: Wed, 16 Dec 2015 18:34:58 +0100 Subject: [Freeipa-users] confused about replica role and use In-Reply-To: <1450188500.17418.168.camel@redhat.com> References: <1450188500.17418.168.camel@redhat.com> Message-ID: > SSSD mostly manages discovery of servers, it is normally configure with > the name _srv_ + an actual name as fallback. > SSSD also feeds the information to kerberos libraries via a plugin. ok, I have this line in my /etc/sssd/sssd.conf: ipa_server = _srv_, ipa.example.com How do I check the current ipa_servers picked up by sssd ? How do the info is fed to kerberos libraries ? Because I set up a replica, using the adelton docker, which seems to work fine. I can use its DNS, access its web UI, the changes are dynamically updated both ways. So far so good. But if suddenly stops the freeIPA master, and try a kdestroy then kinit on my client, I get kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting initial credentials Looking at /etc/krb5.conf, I see hardcoded values: #File modified by ipa-client-install includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false rdns = false ticket_lifetime = 24h forwardable = yes [realms] EXAMPLE.COM = { kdc = ipa.example.com:88 master_kdc = ipa.example.com:88 admin_server = ipa.example.com:749 default_domain = example.com pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .EXAMPLE.com = EXAMPLE.COM EXAMPLE.com = EXAMPLE.COM the same for /etc/ipa/default.conf: #File modified by ipa-client-install [global] basedn = dc=example,dc=com realm = EXAMPLE.COM domain = example.com server = ipah.example.com xmlrpc_uri = https://ipah.example.com/ipa/xml enable_ra = True Is this expected ? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Dec 16 18:11:38 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 16 Dec 2015 13:11:38 -0500 Subject: [Freeipa-users] confused about replica role and use In-Reply-To: References: <1450188500.17418.168.camel@redhat.com> Message-ID: <1450289498.17418.197.camel@redhat.com> On Wed, 2015-12-16 at 18:34 +0100, Karl Forner wrote: > > SSSD mostly manages discovery of servers, it is normally configure with > > the name _srv_ + an actual name as fallback. > > SSSD also feeds the information to kerberos libraries via a plugin. > > ok, I have this line in my /etc/sssd/sssd.conf: > ipa_server = _srv_, ipa.example.com > > How do I check the current ipa_servers picked up by sssd ? > How do the info is fed to kerberos libraries ? > > Because I set up a replica, using the adelton docker, which seems to work > fine. I can use its DNS, access its web UI, the changes are dynamically > updated both ways. > So far so good. > But if suddenly stops the freeIPA master, and try a kdestroy then kinit on > my client, I get > kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting initial > credentials > > Looking at /etc/krb5.conf, I see hardcoded values: > #File modified by ipa-client-install > > includedir /var/lib/sss/pubconf/krb5.include.d/ > > [libdefaults] > default_realm = EXAMPLE.COM > dns_lookup_realm = false > dns_lookup_kdc = false > rdns = false > ticket_lifetime = 24h > forwardable = yes > > [realms] > EXAMPLE.COM = { > kdc = ipa.example.com:88 > master_kdc = ipa.example.com:88 > admin_server = ipa.example.com:749 > default_domain = example.com > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > [domain_realm] > .EXAMPLE.com = EXAMPLE.COM > EXAMPLE.com = EXAMPLE.COM > > the same for /etc/ipa/default.conf: > #File modified by ipa-client-install > > [global] > basedn = dc=example,dc=com > realm = EXAMPLE.COM > domain = example.com > server = ipah.example.com > xmlrpc_uri = https://ipah.example.com/ipa/xml > enable_ra = True > > > Is this expected ? Unfortunately it is, it is a bug in the way we update the krb5 libraries to point to a KDC. SSSD updates this information in a file under /var/lib/sss/pubconf and krb5 libraries read from it, however kinit cannot force sssd to re-evaluate if the file needs updating. If you do a local login instead of a kinit, you will see that SSSD will switch to the new server and subsequent kinit will start using it. This is tracked here: https://fedorahosted.org/sssd/ticket/941 Simo. -- Simo Sorce * Red Hat, Inc * New York From karl.forner at gmail.com Wed Dec 16 18:50:41 2015 From: karl.forner at gmail.com (Karl Forner) Date: Wed, 16 Dec 2015 19:50:41 +0100 Subject: [Freeipa-users] confused about replica role and use In-Reply-To: <1450289498.17418.197.camel@redhat.com> References: <1450188500.17418.168.camel@redhat.com> <1450289498.17418.197.camel@redhat.com> Message-ID: > > If you do a local login instead of a kinit, you will see that SSSD will > switch to the new server and subsequent kinit will start using it. > Ok, I checked and it works just fine for me, thanks. This dynamic discovery of freeipa servers by sssd is very elegant and smart; but I still do not understand how do you automatically switch to a replica (ipa2) if your master (ipa1) is down in some cases: - to access the freeipa web ui. You have to use an url, e.g. https://ipa1.example.com If ipa1 is down, how do you know which url to use ? - if you have other web apps that authenticate against the freeIPA LDAP server. Usually you have to provide a ldap url in the web app configuration, e.g. ldap://ipa1.example.com. What happens when ipa1 is down ? Karl > This is tracked here: > https://fedorahosted.org/sssd/ticket/941 > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Dec 16 21:10:27 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 16 Dec 2015 23:10:27 +0200 Subject: [Freeipa-users] confused about replica role and use In-Reply-To: References: <1450188500.17418.168.camel@redhat.com> <1450289498.17418.197.camel@redhat.com> Message-ID: <20151216211027.GT4620@redhat.com> On Wed, 16 Dec 2015, Karl Forner wrote: >> >> If you do a local login instead of a kinit, you will see that SSSD will >> switch to the new server and subsequent kinit will start using it. >> > >Ok, I checked and it works just fine for me, thanks. > >This dynamic discovery of freeipa servers by sssd is very elegant and >smart; >but I still do not understand how do you automatically switch to a replica >(ipa2) if your master (ipa1) is down >in some cases: > > - to access the freeipa web ui. You have to use an url, e.g. >https://ipa1.example.com > If ipa1 is down, how do you know which url to use ? We have no mechanism for that. Hiding IPA web ui behind a balancer is not easy -- Kerberos does not really like balancers. You can search archives of this list to know more. > - if you have other web apps that authenticate against the freeIPA LDAP >server. > Usually you have to provide a ldap url in the web app configuration, e.g. >ldap://ipa1.example.com. > What happens when ipa1 is down ? That's easy and there are two different approaches here: 1. Use SSSD instead of directly talking to FreeIPA LDAP as we describe and recommend on https://www.freeipa.org/page/Web_App_Authentication 2. Use SRV discovery syntax built-in to openldap's tools. The latter is somewhat less known feature mandated by RFC 4516: http://www.rfc-editor.org/rfc/rfc4516.txt It is achieved with -H option of ldapsearch or other ldap tools if you don't specify a host but rather use DN: dc=example,dc=com, encoded in a way of RFC 2396: dc%3Dexample%2Cdc%3Dcom where %3D is escape sequence for '=' and %2C is escape sequence for ',' ldapsearch -H ldap:///dc%3Dexample%2Cdc%3Dcom would request ldapsearch to first go and resolve DNS SRV record _ldap._tcp.example.com and then connect to the list of servers returned. All tools from OpenLDAP client side use this technique and rotate over list of servers. You can specify multiple servers yourself too as -H "ldap://ipa1.example.com ldap://ipa2.example.com ldap://ipa3.example.com" but using DNS SRV records is more reliable because you don't need to change your script when you decommission the servers. However, the first syntax will not work for just any application using libldap as they don't do this additional SRV discovery. Instead, the second approach should work for them by passing a list of servers separated by space instead of a single one. Again, this is LDAP library specific and not all libraries support this. This is why we recommend you actually use SSSD. :) -- / Alexander Bokovoy From jpazdziora at redhat.com Thu Dec 17 10:30:53 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 17 Dec 2015 11:30:53 +0100 Subject: [Freeipa-users] FreeIPA server in Docker containers -- upcoming changes Message-ID: <20151217103053.GA526@redhat.com> Hello, if you are running FreeIPA servers in containers, you might want to be aware of a change that is coming -- in branch master-systemd of https://github.com/adelton/docker-freeipa we run the FreeIPA services via native systemd in the container, instead of the emulation of systemctl that the current branches and images use. That requires new option to be passed to the docker run command: -v /sys/fs/cgroup:/sys/fs/cgroup:ro Adding that option when running containers from existing images does not hurt so you might want to add them to your startup scripts. Of course, any testing of that master-systemd branch and its suitability for your environments would also be appreciated -- report any successes or failures either on this mailing list, freeipa-devel, or using https://github.com/adelton/docker-freeipa/issues/new Upgrades from existing installations (data volumes) are supported but you certainly want to keep backup around in case you need to revert to the old image. You can also create new replica. The master-systemd branch is based on Fedora 23. Thank you, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From jose.garcia at zap.co.ao Thu Dec 17 10:35:18 2015 From: jose.garcia at zap.co.ao (=?ISO-8859-1?Q?Jos=E9?= Garcia) Date: Thu, 17 Dec 2015 11:35:18 +0100 Subject: [Freeipa-users] deny read Access to passwd for external users Message-ID: <1450348518.2279.8.camel@zap.co.ao> Hi guys, merry christmas and happy new year. I have a freeipa (4.1.0) server on a centos 7 machine and its working fine even with active directory integration. But I would like to know if is it possible to deny read access to certain system configuration files and directories within the server and on clients , such as /etc/passwd for example. -- Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.mortensen at adm.ku.dk Thu Dec 17 13:21:47 2015 From: martin.mortensen at adm.ku.dk (=?UTF-8?Q?Martin_Ren=c3=a9_Mortensen?=) Date: Thu, 17 Dec 2015 14:21:47 +0100 Subject: [Freeipa-users] Avoid auto-setting krbpasswordexpiration to pwdpolicy? Message-ID: <5672B6EB.6050906@adm.ku.dk> Hi, I am setting up an LDAP connection from our Identity Management system which provisions our IPA servers with fresh users and groups. I set it up pretty nice so far, with some added privileges for change admin passwords and avoiding password resets. But when we create a brand new user with a password, IPA resets the krbPasswordExpiration to match the IPA password policy - but we have another policy in our central identity management which gets must get set at user create time. So the question is: Is there any way I can avoid getting krbPasswordExpiration reset to match the password policy? and a followup question: Is this the same with AD sync? passwords from AD gets synced, but expiration is determined by local password policies on the IPA servers? -- Martin R Mortensen Linux Specialist University of Copenhagen -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.forner at gmail.com Thu Dec 17 14:25:48 2015 From: karl.forner at gmail.com (Karl Forner) Date: Thu, 17 Dec 2015 15:25:48 +0100 Subject: [Freeipa-users] bash completion freeze possibly related to freeipa/sssd Message-ID: Hello, Since we use freeIPA, every ubuntu client experiences some sporadic freezes with bash completion. It seems far-fetched but the other ubuntu not using sssd/freeipa do not experience these problems. Could it be related ? How to troubleshoot ? Regards, Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Dec 17 14:33:43 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Dec 2015 15:33:43 +0100 Subject: [Freeipa-users] bash completion freeze possibly related to freeipa/sssd In-Reply-To: References: Message-ID: <5672C7C7.3030000@redhat.com> On 12/17/2015 03:25 PM, Karl Forner wrote: > Hello, > > Since we use freeIPA, every ubuntu client experiences some sporadic freezes > with bash completion. It seems far-fetched but the other ubuntu not using > sssd/freeipa do not experience these problems. > > Could it be related ? How to troubleshoot ? > > Regards, > Karl Hi Karl, FreeIPA itself should only deliver bash completion in /etc/bash_completion.d/ipa around "ipa" command itself, you can try to remove it temporarily to see if this is the reason. It all depends when the bash completion freezes. Maybe some bash completion plugin tries to enumerate users or groups which takes time? We need to see at what command and on which parameter does this happen to provide advise. From mkosek at redhat.com Thu Dec 17 14:40:01 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Dec 2015 15:40:01 +0100 Subject: [Freeipa-users] bash completion freeze possibly related to freeipa/sssd In-Reply-To: References: <5672C7C7.3030000@redhat.com> Message-ID: <5672C941.1060907@redhat.com> Adding freeipa-users mailing list back, so that other users can learn. On 12/17/2015 03:36 PM, Karl Forner wrote: >> It all depends when the bash completion freezes. Maybe some bash completion >> plugin tries to enumerate users or groups which takes time? > > > that's one of my hypothesis > > >> We need to see at >> what command and on which parameter does this happen to provide advise. >> > > it seems to happen frequently when completing make targets for instance. > I'll try to be more precise and have actual commands. Also, running "set -x" before the faulty bash completion may help as it would show the bash commands involved in the completion plugin. From karl.forner at gmail.com Thu Dec 17 19:10:48 2015 From: karl.forner at gmail.com (Karl Forner) Date: Thu, 17 Dec 2015 20:10:48 +0100 Subject: [Freeipa-users] confused about replica role and use In-Reply-To: <1450289498.17418.197.camel@redhat.com> References: <1450188500.17418.168.camel@redhat.com> <1450289498.17418.197.camel@redhat.com> Message-ID: > > Unfortunately it is, it is a bug in the way we update the krb5 libraries > to point to a KDC. > > SSSD updates this information in a file under /var/lib/sss/pubconf and > krb5 libraries read from it, however kinit cannot force sssd to > re-evaluate if the file needs updating. > Is there a work-around ? I've run into this: Imy main server that is stuck with the previous kdc, which is down. And it can not pick up the new kdc. The problem is that the apache server can not authenticate users anymore for my kerberos-enabled web apps. How can I do without rebooting my server ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.forner at gmail.com Fri Dec 18 14:45:33 2015 From: karl.forner at gmail.com (Karl Forner) Date: Fri, 18 Dec 2015 15:45:33 +0100 Subject: [Freeipa-users] unable to effectively delete a replica agreement Message-ID: I am running a master freeIPA called "ipa" in an adelton/freeipa-server (freeIPA 4.1.4). I am able to create a replica server "ipa2", still in an adelton/freeipa-server. If I stop my ipa2 replica, and try to delete the replication agreement: %ipa-replica-manage del ipa2.example.com --force -v It hangs forever. If I run it using the --cleanup option, it seems to work. But when I try to run again from scratch my replica, using the same name, I get: Checking forwarders, please wait ... WARNING: DNS forwarder 10.9.70.7 does not return DNSSEC signatures in answers Please fix forwarder configuration to enable DNSSEC support. (For BIND 9 add directive "dnssec-enable yes;" to "options {}") WARNING: DNSSEC validation will be disabled Warning: skipping DNS resolution of host ipa2.example.com Warning: skipping DNS resolution of host ipa.example.com Using reverse zone(s) 0.17.172.in-addr.arpa. A replication agreement for this host already exists. It needs to be removed. Run this on the master that generated the info file: % ipa-replica-manage del ipa2.example.com --force On my master: # ipa-replica-manage list ipas.example.com: master ipa.example.com: master I manually removed all DNS entries from the 3 zones mentioning ipa2. I can check in the web UI, using the search feature that ipa2 has no occurrence. So I do not understand why the replica install thinks there's still a replication agreement. And I'd like to know: 1) why this command did not work ipa-replica-manage del ipa2.example.com --force -v 2) How could I manually effectively delete this agrrement left-over. Thanks. Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpazdziora at redhat.com Fri Dec 18 15:59:56 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 18 Dec 2015 16:59:56 +0100 Subject: [Freeipa-users] unable to effectively delete a replica agreement In-Reply-To: References: Message-ID: <20151218155956.GD3847@redhat.com> On Fri, Dec 18, 2015 at 03:45:33PM +0100, Karl Forner wrote: > I am running a master freeIPA called "ipa" in an adelton/freeipa-server > (freeIPA 4.1.4). > I am able to create a replica server "ipa2", still in an > adelton/freeipa-server. I should mention that I failed to see the cause of the issues when we discussed it with Karl in https://github.com/adelton/docker-freeipa/issues/40 and at the same time I don't see anything container-specific in what he attempts to do -- therefore I've asked him to bring the issue to this forum. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From pvoborni at redhat.com Fri Dec 18 17:24:14 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 18 Dec 2015 18:24:14 +0100 Subject: [Freeipa-users] Announcing FreeIPA 4.3.0 Message-ID: <5674413E.4000206@redhat.com> The FreeIPA team would like to announce FreeIPA v4.3.0 release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds are available for Fedora rawhide. Builds for Fedora 23 are available in the official COPR repository . This announcement is also available at . == Highlights in 4.3.0 == * Simplified management of replication topology - control and display your topology from CLI and UI * Simplified replica installation - install replica without ''replica package'' via OTP, keytab or privileged user credentials. The new method is called ''replica promotion'' as it adds FreeIPA server capability to existing or new client === Domain Level === Both feature sets are tight with introduction of new "server capability indicator" - a "domain level". Domain level indicates that server is capable of doing certain operations. Domain level 1 means that it supports replica promotion and topology management. Old servers and servers upgraded to 4.3 in existing environments have domain level 0. In order to use new functionality all servers needs to be updated to a version which supports the domain level, right now it is only version 4.3. Domain level is raised by command: $ ipa domainlevel-set 1 Current domain can be obtained by: $ ipa domainlevel-get Or supported levels of individual FreeIPA servers: $ ipa server-show $HOSTNAME === Replica installation === ==== Old method - domain level 0 ==== Prior FreeIPA 4.3 replica installation needed to perform actions on both master and future replica. First step on master: $ ipa-replica-prepare $REPLICA_HOSTNAME --ip-address $REPLICA_IP It created a replica file - an encrypted file containing secrets and other data needed for replica installation. Second step on replica: $ ipa-replica-install --various-options $REPLICA_FILE Disadvantage is that both 'ipa-replica-prepared' and 'ipa-replica-install' need directory manager password and that copying of the replica file is cumbersome. Old method is still available for environments with domain level 0. ==== New method - domain level 1 ==== New method transforms an IPA client into an IPA server. I.e., an IPA client can be installed first and then it can be "promoted" into an FreeIPA server - a new replica. Alternatively, replica installer can also install the client so it can be done in a single operation. New method doesn't require to run 'ipa-replica-prepare' and manipulate with replica file. There are multiple ways to install new replica: ===== 1. Promotion of existing client ===== On client which will become new FreeIPA server: $ kinit admin $ ipa-replica-install [--various-options, ...] ===== 2. Installation of replica on non-FreeIPA client machine ===== $ ipa-replica-install --principal admin -W [--various-options, ...] It will ask for admin password, install a client and then promote it to replica. It will use DNS auto-discovery to locate the master server. Alternatively the same discovery options as for 'ipa-client-install' can be provided: '--server', '--domain', '--realm'. ===== 3. Installation of replica using one time password(OTP) ===== On any host with 'ipa' command line utility available first prepare the host entry with One Time Password set and assign it to 'ipaservers' hostgroup to mark it as future IPA server. $ kinit admin $ ipa host-add $REPLICA_HOSTNAME --password $OTP $ ipa hostgroup-add-member ipaservers --hosts=$REPLICA_HOSTNAME On future replica: $ ipa-replica-install --password $OTP [--various-options, ...] ===== 4. Installation of replica using a host keytab ===== Steps are similar as in installation with OTP: On arbitrary FreeIPA client or server: $ kinit admin $ ipa host-add $REPLICA_HOSTNAME $ ipa hostgroup-add-member ipaservers --hosts=$REPLICA_HOSTNAME $ ipa-getkeytab --server=$IPASERVER_HOSTNAME --principal=host/$REPLICA_HOSTNAME@$REALM --keytab=replica_host.keytab $ # copy the replica_host.keytab to a replica on $REPLICA_KEYTAB_PATH (arbitrary) On future replica: $ ipa-replica-install --keytab $REPLICA_KEYTAB_PATH [--various-options, ...] === Managed Replication Topology === FreeIPA is a multi-master technology. Data changes on a server are replicated automatically to all other servers. Data is stored in Directory Server server in two so-called suffixes: a 'domain' suffix, e.g., 'dc=example,dc=com' which contains all domain related data(users, groups, hbac and sudo rules, ...) and, if the setup has CA, a 'ca' suffix('o=ipaca') which contains Certificate Server data. IPA servers, in general, are not connected with all other servers, but usually with only a few. It means the data is gradually propagated. The way is defined in Directory Server by so-called replication agreements. Replication agreements for each suffix need to be managed separately. Recommended maximum number of agreements on one server is 4 for each suffix. It is required to manage the topology of replication agreements correctly so a failure of one server would not disconnect the entire topology. FreeIPA 4.2 and older manages the agreements using 'ipa-replica-manage' and 'ipa-csreplica-manage' tools. The disadvantage of the tools are: * No single single server has data about the whole topology. * The tools needs to be run on an IPA server -> not possible in CLI or Web UI. * The lack of information prevents of proper disconnection checks, e.g., when a replica or a connection is removed. FreeIPA 4.3 introduces a managed topology. The topology is maintained as data and is replicated to all other servers. It is represented by two new IPA object types: topology suffixes and topology segments. Topology suffix represents a Directory Server suffix mentioned above. Topology segment represents replication agreements between 2 servers. See `ipa help topology` for more information about CLI commands. IPA servers changes their replication agreements automatically according to this configuration. It brings following benefits: * 'ipa' command line interface and Web UI(located under "IPA Server/Topology" menu item) can be used to manage the topology from any place * Modification of the topology performs a check to prevent disconnection (a server or a group of servers would not be connected with rest of the topology). * Uninstallation of replica using 'ipa-replica-manage del' and 'ipa-server-install --uninstall' tools checks if the uninstallation would disconnect the topology and refuses to do so. * Existing topology can be checked for errors using a new 'ipa topologysuffix-verify' command. * Web UI comes with new topology graph which visualizes the topology and allows interactive changes of the topology. * It will allow to monitor state of replication in a future. On domain level 1, managing of IPA replication agreements using 'ipa-replica-manage' and 'ipa-csreplica-manage' tools is no longer possible. But the tools can be still used for managing of winsync agreements, DNA ranges, RUVs and for reinitializing and force-synchronizing of replicas. Long term goal is to completely replace 'ipa-csreplica-manage' and leave 'ipa-replica-manage' only for managing of winsync agreements. === DNS zone creation checks === FreeIPA now checks if specified DNS domains exist prior installing the integrated DNS server and refuses to use DNS domain names which are already served by other DNS servers. This prevents problems caused by situation where multiple DNS servers wrongy act as authoritative servers for single DNS domain. This has multiple consequences: * To avoid conflicts, the unattended installation creates reverse zones only if option '--auto-reverse' is used. * Reverse DNS zones which already exist on some other DNS servers are not automatically created to avoid conflicts (even during interactive installation). * When reverse zones are not managed by FreeIPA DNS, the automatic empty zones (as specified in RFC 6303 ) are automatically created by BIND. In situations where these reverse zones are used and managed by other DNS servers, FreeIPA DNS servers should forward queries for these zones. In that case users must manually create 'forward zone' using `ipa dnsforwarzone-add` command to override automatic empty zone supplied by BIND. This change affects only new installations. === Known Issues === * Running 'ipa-dns-install' when some other IPA server has DNS installed will fail. Use '--force' option to workaround the issue. * FreeIPA 4.3 requires an update of SELinux policy, see bug 1289930 . To workaround the issue, disable SELinux - 'setenforce 0' - on master when installing a replica or a Certificate Server. * Re-installation of replica with CA or re-installation of KRA will fail without pki-core-10.2.6-13 , see bug #1704 === Bug fixes === * Contains all bugfixes and enhancements of 4.2.2 and 4.2.3 releases. * Automatic configuration for Firefox < 10 was dropped. #5144 * '--configure-firefox' is documented in 'ipa-client-install' man page. #5375 === Enhancements === * 'ipa-getkeytab' no longer requires to specify server when run on FreeIPA server. #2203 * Custom configuration for dse.ldif can be provided on replica installation. #4048 #4949 * Added support for Ed25519 SSH keys (RFC 7479). #5471 == Upgrading == Upgrade instructions are available on Upgrade page == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.2.1 == === Abhijeet Kasurde (4) === * Added try/except block for user_input in ipautil * Updated number of legacy permission in ipatests * Added user friendly error message for dnszone enable and disable * Fixed small typo in stage-user documentation === Alexander Bokovoy (7) === * selinux: enable httpd_run_ipa to allow communicating with oddjobd services * oddjob: avoid chown keytab to sssd if sssd user does not exist * Fix selector of protocol for LSA RPC binding string * trusts: harden trust-fetch-domains oddjobd-based script * trusts: format Kerberos principal properly when fetching trust topology * client referral support for trusted domain principals * spec file: depend on Dogtag 10.2.6-12 for tomcat 8 upgrade === Benjamin Drung (3) === * Fix hyphen-used-as-minus-sign warning (found by lintian) * Fix manpage-has-errors-from-man warning (found by Lintian) * default.conf.5: Fix a typo === Christian Heimes (18) === * Start dirsrv for kdcproxy upgrade * Remove tuple unpacking from except clause contrib/RHEL4/ipachangeconf.py * Remove tuple unpacking from except clause ipa-client/ipaclient/ipachangeconf.py * Remove tuple unpacking from except clause ipalib/plugins/hbactest.py * Remove tuple unpacking from except clause ipaserver/dcerpc.py * Replace file() with open() * Fix selinux denial during kdcproxy user creation * certprofile-import: improve profile format documentation * otptoken: use ipapython.nsslib instead of Python's ssl module * Require Dogtag PKI >= 10.2.6 * Replace M2Crypto RC4 with python-cryptography ARC4 * Validate vault's file parameters * certprofile-import: do not require profileId in profile data * Asymmetric vault: validate public key in client * Add flag to list all service and user vaults * Change internal rsa_(public|private)_key variable names * Handle timeout error in ipa-httpd-kdcproxy * mod_auth_gssapi: Remove ntlmssp support and restrict mechanism to krb5 === David Kupka (22) === * migration: Use api.env variables. * cermonger: Use private unix socket when DBus SystemBus is not available. * ipa-client-install: Do not (re)start certmonger and DBus daemons. * dbus: Create empty dbus.Array with specified signature * user-undel: Fix error messages. * client: Add support for multiple IP addresses during installation. * client: Add description of --ip-address and --all-ip-addresses to man page * Backup/resore authentication control configuration * vault: Limit size of data stored in vault * ipactl: Do not start/stop/restart single service multiple times * comment: Add Documentation string to deduplicate function * admintool: Add error message with path to log on failure. * ipa-cacert-renew: Fix connection to ldap. * ipa-otptoken-import: Fix connection to ldap. * ipa-replica-install support caless install with promotion. * install: Run all validators at once. * replica: Fix ipa-replica-install with replica file (domain level 0). * test: Temporarily increase timeout in vault test. * spec file: Add dbus-python to BuildRequires * dns: do not add (forward)zone if it is already resolvable. * dns: Check if domain already exists. * dns: Add --auto-reverse option. === Endi Sukma Dewata (6) === * Fixed missing KRA agent cert on replica. * Added CLI param and ACL for vault service operations. * Fixed vault container ownership. * Added support for changing vault encryption. * Removed clear text passwords from KRA install log. * Using LDAPI to setup CA and KRA agents. === Fran?ois Cami (1) === * ipa-client-install: Fix the "download the CA cert" query === Fraser Tweedale (19) === * user-show: add --out option to save certificates to file * Fix otptoken-remove-managedby command summary * Give more info on virtual command access denial * Allow SAN extension for cert-request self-service * Add profile for DNP3 / IEC 62351-8 certificates * Work around python-nss bug on unrecognised OIDs * Fix default CA ACL added during upgrade * Fix KRB5PrincipalName / UPN SAN comparison * certprofile: add profile format explanation * Add permission for bypassing CA ACL enforcement * Prohibit deletion of predefined profiles * cert-request: remove allowed extensions check * certprofile: prevent rename (modrdn) * certprofile: remove 'rename' option * TLS and Dogtag HTTPS request logging improvements * Avoid race condition caused by profile delete and recreate * Do not erroneously reinit NSS in Dogtag interface * Add profiles and default CA ACL on migration * dogtaginstance: remove unused function 'check_inst' === Gabe Alford (16) === * Fix client ca.crt to match the server's cert * Add Chromium configuration note to ssbrowser * Standardize minvalue for ipasearchrecordlimit and ipasesarchsizelimit for unlimited minvalue * dnssec option missing in ipa-dns-install man page * Update FreeIPA package description * Remove bind configuration detected question * Warn if no installation found when running ipa-server-install --uninstall * Add Firefox options to ipa-client-install man page * interactive installer does not ignore leading/trailing whitespace * Remove 50-lockout-policy.update file * Incomplete ports for IPA AD Trust * custodia: ipa-upgrade failed on replica * ipa-replica-manage del continues when host does not exist in domain level 1 * Check if IPA is configured before attempting a winsync migration * ipa-replica-install prints incorrect error message when replica is already installed * Migrate wget references and usage to curl === Jan Cholasta (70) === * spec file: Move /etc/ipa/kdcproxy to the server subpackage * spec file: Update minimum required version of krb5 * install: Fix server and replica install options * ULC: Prevent preserved users from being assigned membership * baseldap: Allow overriding member param label in LDAPModMember * vault: Fix param labels in output of vault owner commands * install: Fix replica install with custom certificates * vault: Fix vault-find with criteria * vault: Add container information to vault command results * spec file: Add Requires(post) on selinux-policy * cert renewal: Include KRA users in Dogtag LDAP update * cert renewal: Automatically update KRA agent PEM file * install: Fix SASL mappings not added in ipa-server-install * ldap: Make ldap2 connection management thread-safe again * Use six.with_metaclass to specify metaclasses * Use six.python_2_unicode_compatible * Decode script arguments using file system encoding * config: allow user/host attributes with tagging options * Alias "unicode" to "str" under Python 3 * Use bytes instead of str where appropriate * Use byte literals where appropriate * baseldap: make subtree deletion optional in LDAPDelete * vault: set owner to current user on container creation * vault: update access control * vault: add permissions and administrator privilege * install: support KRA update * install: Support overriding knobs in subclasses * install: Add common base class for server and replica install * install: Move unattended option to the general help section * install: create kdcproxy user during server install * platform: add option to create home directory when adding user * install: fix kdcproxy user home directory * install: fix invocation of KRAInstance.create_instance() * install: fix ipa-server-install fail on missing --forwarder * install: fix KRA agent PEM file permissions * install: always export KRA agent PEM file * vault: select a server with KRA for vault operations * schema: do not derive ipaVaultPublicKey from ipaPublicKey * upgrade: make sure ldap2 is connected in export_kra_agent_pem * vault: fix private service vault creation * install: fix command line option validation * install: export KRA agent PEM file in ipa-kra-install * cert renewal: make renewal of ipaCert atomic * client install: do not corrupt OpenSSH config with Match sections * install: drop support for Dogtag 9 * server: use topologysuffix name in iparepltopomanagedsuffix * topology: replace "suffices" with "suffixes" * aci: add IPA servers host group 'ipaservers' * aci: replace per-server ACIs with ipaserver-based ACIs * aci: allow members of ipaservers to set up replication * ipautil: use file in a temporary dir as ccache in private_ccache * replica promotion: use host credentials when setting up replication * replica promotion: automatically add the local host to ipaservers * custodia: do not modify memberPrincipal on key update * replica promotion: allow OTP bulk client enrollment * replica install: add ipaservers if it does not exist * replica promotion: check domain level before ipaservers membership * server uninstall: ignore --ignore-topology-disconnect in domain level 0 * spec file: remove config files from freeipa-python * spec file: put Python modules into standalone packages * build: put oddjob scripts into separate directory * replica install: add remote connection check over API * replica promotion: use host credentials for connection check * replica promotion: notify user about ignoring client enrollment options * aci: merge domain and CA suffix replication agreement ACIs * ca install: use host credentials in domain level 1 * ipautil: allow redirecting command output to standard output in run() * server install: redirect ipa-client-install output to standard output * replica promotion: let ipa-client-install validate enrollment options * ipautil: remove unused import causing cyclic import in tests === Jan Pazdziora (1) === * The delegation uris are not set, match message to code. === Lenka Doudova (3) === * Automated test for stageuser plugin * Fix user tracker to reflect new user-del message * Adding descriptive IDs to stageuser tests === Ludwig Krispenz (5) === * handle multiple managed suffixes * prevent operation on tombstones * handle cleaning of RUV in the topology plugin * reject agreement only if both ends are managed * update list of managed servers when a suffix becomes managed === Luk?? Slebodn?k (9) === * SPEC: Drop sssd from BuildRequires * ipa_kdb_tests: Remove unused variables * ipa_kdb_tests: Fix warning Wmissing-braces * topology: Fix warning Wshadow * ipa-extdom-extop: Fix warning Wformat * SPEC: Run cmocka based unit test in %check phase * BUILD: provide check target in custom Makefiles * cmocka_tests: Do not use deprecated cmocka interface * ipa_kdb_tests: Fix test with default krb5.conf === Martin Babinsky (50) === * ipa-ca-install: print more specific errors when CA is already installed * enable debugging of ntpd during client installation * fix broken search for users by their manager * ACI plugin: correctly parse bind rules enclosed in parentheses * test suite for user/host/service certificate management API commands * store certificates issued for user entries as userCertificate;binary * idranges: raise an error when local IPA ID range is being modified * fix typo in BasePathNamespace member pointing to ods exporter config * ipa-backup: archive DNSSEC zone file and kasp.db * ipa-restore: check whether DS is running before attempting connection * improve the handling of krb5-related errors in dnssec daemons * improve the usability of `ipa user-del --preserve` command * load RA backend plugins during standalone CA install on CA-less IPA master * destroy httpd ccache after stopping the service * ipa-server-install: mark master_password Knob as deprecated * re-kinit after ipa-restore in backup/restore CI tests * do not overwrite files with local users/groups when restoring authconfig * remove ID overrides when deleting a user * do not ask for segment direction when running topology commands * fix dsinstance.py:get_domain_level function * disable ipa-replica-prepare in non-zero IPA domain level * execute user-del pre-callback also during user preservation * fix class teardown in user plugin tests * always ask the resolver for the reverse zone when manipulating PTR records * silence pylint in Python 3-specific portion of ipalib/rpc.py * ipa-replica-prepare: domain level check improvements * fix error reporting when installer option is supplied with invalid choice * remove Kerberos authenticators when installing/uninstalling service instance * remove an unneccesary check from IPA server uninstaller * check for disconnected topology and deleted agreements for all suffices * suppress errors arising from adding existing LDAP entries during KRA install * update idrange tests to reflect disabled modification of local ID ranges * disconnect ldap2 backend after adding default CA ACL profiles * do not disconnect when using existing connection to check default CA ACLs * fix a typo in replica DS creation code * replica promotion: modify default.conf even if DS configuration fails * perform IPA client uninstallation as a last step of server uninstall * fix 'iparepltopomanagedsuffix' attribute consumers * extract domain level 1 topology-checking code from ipa-replica-manage * implement domain level 1 specific topology checks into IPA server uninstaller * replica install: improvements in the handling of CA-related IPA config entries * add auto-forwarders option to standalone DNS installer * add '--auto-forwarders' description to server/replica/DNS installer man pages * check whether replica exists before executing the domain level 1 deletion code * CI tests: ignore disconnected domain level 1 topology on IPA master teardown * add ACIs for custodia container to its parent during IPA upgrade * fix error message assertion in negative forced client reenrollment tests * prevent crashes of server uninstall check caused by failed LDAP connections * CI tests: remove '-p' option from ipa-dns-install calls * ipa-client-install: create a temporary directory for ccache files === Martin Ba?ti (92) === * Prevent to rename certprofile profile id * Stageusedr-activate: show username instead of DN * copy-schema-to-ca: allow to overwrite schema files * fix selinuxusermap search for non-admin users * Validate adding privilege to a permission * sysrestore: copy files instead of moving them to avoind SELinux issues * Allow value 'no' for replica-certify-all attr in abort-clean-ruv subcommand * Py3: replace tab with space * DNS: Consolidate DNS RR types in API and schema * DNS: check if DNS package is installed * Remove ico files from Makefile * Use 'mv -Z' in specfile to restore SELinux context * ULC: Fix stageused-add --from-delete command * Fix upgrade of sidgen and extdom plugins * Add dependency to SSSD 1.13.1 * Server Upgrade: Start DS before CA is started. * Add user-stage command * DNSSEC: fix forward zone forwarders checks * Fix: Remove leftover krbV reference * DNSSEC: remove "DNSSEC is experimental" warnings * Backup: back up the hosts file * Server Upgrade: fix traceback caused by cidict * Installer: do not modify /etc/hosts before user agreement * DNSSEC: backup and restore opendnssec zone list file * DNSSEC: remove ccache and keytab of ipa-ods-exporter * FIX vault tests * Server Upgrade: backup CS.cfg when dogtag is turned off * IPA Restore: allows to specify files that should be removed * Server Install: print message that client is being installed * DNSSEC: improve CI test * DNSSEC CI: test master migration * backup CI: test DNS/DNSSEC after backup and restore * Limit max age of replication changelog * Server Upgrade: addifnew should not create entry * CI: backup and restore with KRA * Replica inst. fix: do not require -r, -a, -p options in unattended mode * CI TEST: Vault * CI Test: add setup_kra options into install scripts * Replace tab with space in test_user_plugin.py * Make offline LDIF modify more robust * Add method to read changes from LDIF * Add option to specify LDIF file that contains DS configuration changes * CI: installation with customized DS config * Rename option --dirsrv-config-mods to --dirsrv-config-file * DNSSEC CI: wait until DS records is replicated * DNSSEC: store status of services only before first install * DNSSEC: Remove service containers from LDAP after uninstalling * DNSSEC: warn user if DNSSEC key master is not installed * ipa-replica-manage: fix undefined variable * Remove executable bit from ipa_kra_install.py * Domain levels: use constants rather than hardcoded values * KRA: fix check that CA is installed * ipa-csreplica-manage: disable connect/disconnect/del with domain level > 0 * Fix typo in ods-exporter uninstall to restore state * DNSSEC: remove sysrestore state after uninstall * Upgrade: enable custodia service during upgrade * Use domain level constants in topology plugin * Tests: DNS replace 192.0.2.0/24 with 198.18.0.0/15 range * Tests: DNS various exceptions can be raised in test * Drop configure.jar * Fix CI tests domain_level env config * CI test: Fix installation of KRA on a replica * fix caching in get_ipa_config * Move common code of user and stageuser to baseuser postcallback * Allow multiple managers per user - CLI part * upgrade: fix migration of old dns forward zones * remove forgotten print in DNS plugin * Install: Force service add during replica promotion * Fix upgrade of forwardzones when zone is in realmdomains * Remove invalid error messages from topology upgrade * Make command dns-resolve deprecated. * Call directly function is_host_resolvable instead do call via framework * Use absolute domain in detection of A/AAAA records * ipa-getkeytab: do not return error when translations cannot be loaded * Compare objectclasses as case insensitive in baseuser.py * KRA: do not stop certmonger during standalone uninstall * ipa-ca-install: error when replica file is passed with domain level > 0 * KRA install: show installation message only if install really started * ipa-kra-install: error when replica file is passed with domain level > 0 * FIX: ipa_kdb_principals: add missing break statement * Upgrade: increase time limit for upgrades * ipa-kra-install: allow to install first KRA on replica * Modify error message to install first instance of KRA * CI: test various topologies with multiple replicas * Force creation of services during replica install * CI: installation tests * CI: fix function that prepare the hosts file before CI run * CI: fix ipa-kra-install on domain level 1 * Install RA cert during replica promotion * Tests: test_ipagetkeytab: fix assert that is always true * DNS: fix file permissions * Explicitly call chmod on newly created directories === Martin Ko?ek (2) === * Update Contributors.txt * Update Build instructions === Michael Simacek (4) === * Port from python-kerberos to python-gssapi * Bump python-gssapi version to 1.1.2 * Port from python-krbV to python-gssapi * Rewrap errors in get_principal to CCacheError === Milan Kub?k (16) === * ipalib: pass api instance into textui in doctest snippets * spec file: update the python package names for libipa_hbac and libsss_nss_idmap * tests: Allow Tracker.dn be an instance of Fuzzy * ipatests: Take otptoken import test out of execution * ipatests: Add Certprofile tracker class implementation * ipatests: Add basic tests for certificate profile plugin * ipatests: configure Network Manager not to manage resolv.conf * Include ipatests/test_xmlrpc/data directory into distribution. * ipatests: add fuzzy instances for CA ACL DN and RDN * ipatests: Add initial CAACLTracker implementation * tests: add test to check the default ACL * ipatests: CA ACL - added config templates * ipatests: added unlock_principal_password and change_principal * ipatests: CA ACL and cert profile functional test * Applied tier0 and tier1 marks on unit tests and xmlrpc tests * Separated Tracker implementations into standalone package === Nathaniel McCallum (1) === * Fix an integer underflow bug in libotp === Niranjan MR (1) === * enable pem=True in export_pem_cert function === Niranjan Mallapadi (1) === * Use Exception class instead of StandardError === Oleg Fayans (9) === * Added test - topology plugin is listed among DS plugins * Added a user-friendly output to an import error * Temporary fix for ticket 5240 * Integration tests for topology plugin * Added a proper workaround for dnssec test failures in Beaker environment * Fixed a timing issue with drill returning non-zero exitcode * Updated the tests according to the new replica installation workflow * The test was made to be skipped if domainlevel is 0 * Fixed A record creation bug === Petr Viktorin (60) === * Modernize number literals * Modernize 'except' clauses * Modernize function and method attribute names * Replace dict.has_key with the 'in' operator * Import 'reduce' from functools * Use absolute imports * Remove use of sys.exc_value * Don't use a tuple in function arguments * Add python-six to dependencies * Remove the unused pygettext script * Use six.string_types instead of "basestring" * Use Python3-compatible dict method names * Replace filter() calls with list comprehensions * Use six.moves.input instead of raw_input * Use six.integer_types instead of (long, int) * Replace uses of map() * Use next() function on iterators * Use the print function * Use new-style raise syntax * Use six.reraise * Modernize use of range() * Convert zip() result to list() * ipap11helper: Port to Python 3 * rpc: Don't use undocumented urllib functions * ipapython.dn: Use rich comparisons * test_dn: Split bytes and unicode * Use sys.maxsize instead of sys.maxint * Use six.moves.urllib instead of urllib/urllib2/urlparse * Use six.moves.xmlrpc.client instead of xmlrpclib * Use six.moves.configparser instead of ConfigParser * Use six.moves.http_client instead of httplib * Use six.Stringio instead of StringIO.StringIO * Remove uses of the `types` module * ipapython.ssh: Port to Python 3 * Appease pylint * Do not compare types that are not comparable in Python 3 * x509: Port to Python 3 * Rename caught exception for use outside the except: block. * test_ipalib.test_frontend: Port unbound method tests to Python 3 * ipalib.aci: Port to Python 3 * Add `message` property to IPA's errors and warnings under Python 3 * test_keyring: Use str(e) instead of e.message for exceptions * ipalib.parameters: Handle 0-prefixed octal format of ints * ipalib.parameters: Require bytes for Bytes.pattern * rpc: Name argument to KerberosError * Alias long to int under Python 3 * ipaldap: Remove extraneous `long` (included in six.int_types) * Handle binascii.Error from base64.b64decode() * ipatest.util: Port to Python 3 * ipalib.messages: Add "message" property to PublicMessage * Fix more bytes/unicode issues * Work around ipalib.text (i18n) str/unicode handling * Fix left-over Python 3 syntax errors * ipapython.nsslib, ipalib.rpc: Remove code for Python 2.6 and below * ipapython.nsslib: Remove NSSHTTPS * ipapython.secrets: Port to Python 3 * test_parameters: Alias long to int under Python 3 * ipalib.rpc: Update for Python 3 * Refactor ipautil.run * Package ipapython, ipalib, ipaplatform, ipatests for Python 3 === Petr Voborn?k (45) === * Become IPA 4.2.0 * Bump 4.3 development version to 4.2.90 * do not import memcache on client * webui: fix user reset password dialog * fix hbac rule search for non-admin users * webui: add Kerberos configuration instructions for Chrome * webui: fix regressions failed auth messages * webui: add LDAP vs Kerberos behavior description to user auth types * adjust search so that it works for non-admin users * validate mutually exclusive options in vault-add * add permission: System: Manage User Certificates * vault: normalize service principal in service vault operations * vault: validate vault type * vault: change default vault type to symmetric * fix missing information in object metadata * webui: add option to establish bidirectional trust * vault: fix vault tests after default type change * vault: add vault container commands * webui: use manual Firefox configuration for Firefox >= 40 * webui: improve performance of search in association dialog * topology: add realm suffix to master entry on update * topology: manage ca replication agreements * enable topology plugin on upgrade * topology plugin configuration workaround * change pki-core required version for replica promotion * Update .po files * fix broken translations after last po update * webui: add Deferred/Promise API to rpc.command * webui: split facet header into two classes * webui: extract header and action logic from facet to separate mixins * webui: allow to update action_state directly * webui: add d3 library - version 3.5.6 * webui: topology graph component * webui: topology graph facet * webui: add segments on topology graph page * webui: remove segments on topology graph page * webui: update topology graph after raising domain level * topology: treat server suffix as multivalued attribute in API * use starttls in CSReplicationManager connection again * change suffices to suffixes * topologysuffix: change iparepltopoconfroot API properties * rename topology suffixes to "domain" and "ca" * Update ipa-(cs)replica-manage man pages * Extend topology help * Become IPA 4.3.0 === Petr ?pa?ek (19) === * Create server-dns sub-package. * DNSSEC: prevent ipa-ods-exporter from looping after service auto-restart * DNSSEC: Fix deadlock in ipa-ods-exporter <-> ods-enforcerd interaction * DNSSEC: Fix HSM synchronization in ipa-dnskeysyncd when running on DNSSEC key master * DNSSEC: Fix key metadata export * DNSSEC: Wrap master key using RSA OAEP instead of old PKCS v1.5. * Avoid ipa-dnskeysync-replica & ipa-ods-exporter crashes caused by exceeding LDAP limits * ipa-adtrust-install: Print complete SRV records * DNSSEC: on uninstall, do not restore OpenDNSSEC kasp.db if backup failed * DNSSEC: improve log messages in uninstaller * DNS record-add warns when a suspicious DNS name is detected * Remove dead code in ipaserver/install/installutils: read_ip_address() * Remove unused constant NEW_MASTER_MARK from ipaserver.install.dns * ipa-client-install: add support for Ed25519 SSH keys (RFC 7479) * ipa-dns-install offer IP addresses from resolv.conf as default forwarders * Remove global variable dns_forwarders from ipaserver.install.dns * add missing /ipaplatform/constants.py to .gitignore * Makefile: disable parallel build * dns: Handle SERVFAIL in check if domain already exists. === Rob Crittenden (1) === * Use %license instead of %doc for packaging the license === Robert Kuska (1) === * Replace StandardError with Exception === Simo Sorce (23) === * Fix DNS records installation for replicas * Remove custom utility function from krbinstance * Move sasl mappings creation to dsinstance * Simplify adding options in ipachangeconf * Insure the admin_conn is disconnected on stop * Remove unused arguments * Simplify the install_replica_ca function * Add ipa-custodia service * Require a DS version that has working DNA plugin * Implement replica promotion functionality * Change DNS installer code to use passed in api * Allow ipa-replica-conncheck to use default creds * Add function to extract CA certs for install * Allow to setup the CA when promoting a replica * Make checks for existing credentials reusable * Add low level helper to get domain level * Remove unused kra option * Allow ipa-ca-install to use the new promotion code * Allow to install the KRA on a promoted server * Check early if a CA is already installed locally * Return default TL_DATA is krbExtraData is missing * Support sourcing the IPA server name from config * Sync kerberos LDAP schema with upstream. === Stanislav Laznicka (3) === * ipa-client-install: warn when IP used in --server * Fixes disappearing automember expressions * Removed duplicate domain name validating function === Sumit Bose (3) === * ipasam: fix wrong usage of talloc_new() * ipasam: use more restrictive search filter for group lookup * ipasam: fix a use-after-free issue === Timo Aaltonen (7) === * paths: Add GENERATE_RNDC_KEY. * httpinstance: Replace a hardcoded path to password.conf with HTTPD_PASSWORD_CONF * ipaplatform: Add HTTPD_USER to constants, and use it. * ipaplatform: Add NAMED_USER to constants * httpinstance: Use full path via HTTPD_IPA_REWRITE_CONF for Include. * ipaplatform: Add SECURE_NFS_VAR to constants * ipaplatform: Add NTPD_OPTS_VAR and NTPD_OPTS_QUOTE to constants === Tom?? Babej (59) === * ipalib: Fix missing format for InvalidDomainLevelError * Revert "Hide topology and domainlevel features" * trusts: Check for AD root domain among our trusted domains * domainlevel: Fix incorrect initializations of InvalidDomainLevelError exceptions * ipaplatform: Add constants submodule * tests: user_plugin: Add preserved flag when --all is used * dcerpc: Expand explanation for WERR_ACCESS_DENIED * idviews: Check for the Default Trust View only if applying the view * tests: service_plugin: Make sure the cert is decoded from base64 * tests: realmdomains_plugin: Add explanatory comment * tests: Version is currently generated during command call * tests: vault_plugin: Skip tests if KRA not available * tests: test_rpc: Create connection for the current thread * tests: test_cert: Services can have multiple certificates * dcerpc: Fix UnboundLocalError for ccache_name * dcerpc: Add get_trusted_domain_object_type method * idviews: Restrict anchor to name and name to anchor conversions * idviews: Enforce objectclass check in idoverride*-del * replication: Fix incorrect exception invocation * Fix incorrect type comparison in trust-fetch-domains * dcerpc: Simplify generation of LSA-RPC binding strings * adtrust-install: Correctly determine 4.2 FreeIPA servers * trusts: Detect domain clash with IPA domain when adding a AD trust * trusts: Detect missing Samba instance * winsync-migrate: Add warning about passsync * winsync-migrate: Expand the man page * winsync: Add inetUser objectclass to the passsync sysaccount * ipa-backup: Add mechanism to store empty directory structure * winsync-migrate: Convert entity names to posix friendly strings * winsync-migrate: Properly handle collisions in the names of external groups * util: Add detect_dns_zone_realm_type helper * realmdomains: Minor style and wording improvements * realmdomains: Add validation that realmdomain being added is indeed from our realm * realmdomains: Issue a warning when automated management of realmdomains failed * realmdomains: Do not fail due the ValidationError when adding _kerberos TXT record * tests: Amend result assertions in realmdomains tests * idoverride: Ignore ValidationErrors when converting the anchor * tests: Add tests for idoverride object integrity * trusts: Make trust_show.get_dn raise properly formatted NotFound * trustdomain: Perform validation of the trust domain first * adtrustinstance: Wait for sidgen task completion * adtrustinstance: Restart samba service at the end of adtrust-install * adtrustinstance: Do not use bare except clauses * ipachangeconf: Remove reference to an old-style interface * spec: Add Provides directives to alternative package names * private_ccache: Harden the removal of KRB5CCNAME env variable * ipachangeconf: Add ability to preserve section case * ipa-client-automount: Leverage IPAChangeConf to configure the domain for idmapd * custodia: Make sure container is created with first custodia replica * replicainstall: Add possiblity to install client in one command * translations: Update ipa.pot file * man: Update the ipa-replica-install manpage with promotion related info * tests: Fix incorrect uninstall method invocation * replicainstall: Admin password should not conflict with replica file * topology: Make sure the old 'realm' topology suffix is not used * topology: Fix: Make sure the old 'realm' topology suffix is not used * tests: Add hostmask detection for sudo rules validating on hostmask * replicainstall: Add check for domain if server is specified * replicainstall: Make sure the enrollment state is preserved === Yuri Chornoivan (2) === * Fix minor typos * Fix minor typos -- Petr Vobornik From cal-s at blue-bolt.com Sun Dec 20 14:09:30 2015 From: cal-s at blue-bolt.com (Cal Sawyer) Date: Sun, 20 Dec 2015 14:09:30 +0000 Subject: [Freeipa-users] OS X Yosemite unable to authenticate In-Reply-To: References: Message-ID: <5676B69A.6040501@blue-bolt.com> Hi, all I'm attempting to set up LDAP auth (against IPA server 4.10) from a OSX 10.10.5 (Yosemite) client Using the excellent instructions at http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8%20%22Linsec.ca%20tutorial%20for%20connecting%20Mac%20OS%2010.7%20to%20IPA%20Server, I've populated the specified files, d/l'd the cert, am able to configure Users and Groups objects/attribs and browse both from within OSX's Directory Utility. ldapsearch similarly returns the expected results. In spite of this, i'm unable to authenticate as any IPA-LDAP user on this system dirsrv log on the ipa master shows no apparent errors - remote auth attempts exit with "RESULT err=0 tag=101 nentries=1 etime=0", but tell the truth, there so much stuff there and being rather inexperienced with LDAP diags i might easily be missing something in the details The linsec.ca instructions were written in the 10.7-10.8 era so something may have changed since. Having said that, we've had no problems authenticating against our existing OpenLDAP server (which IPA is slated to replace) right up to 10.10.5 with no zero to our Directory Utility setup. Hoping someone here has some contemporary experience with OSX and IPA and for whom this issue rings a bell? many thanks Cal Sawyer | Systems Engineer | BlueBolt Ltd 15-16 Margaret Street | London W1W 8RW +44 (0)20 7637 5575 | www.blue-bolt.com From john.obaterspok at gmail.com Mon Dec 21 06:50:43 2015 From: john.obaterspok at gmail.com (John Obaterspok) Date: Mon, 21 Dec 2015 07:50:43 +0100 Subject: [Freeipa-users] OS X Yosemite unable to authenticate In-Reply-To: <5676B69A.6040501@blue-bolt.com> References: <5676B69A.6040501@blue-bolt.com> Message-ID: Hi Cal, Does a kinit work from a terminal? Does it work if you use "kinit user" or just if you use "kinit user at REALM.suffix" -- john 2015-12-20 15:09 GMT+01:00 Cal Sawyer : > Hi, all > > I'm attempting to set up LDAP auth (against IPA server 4.10) from a OSX > 10.10.5 (Yosemite) client > > Using the excellent instructions at > http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8%20%22Linsec.ca%20tutorial%20for%20connecting%20Mac%20OS%2010.7%20to%20IPA%20Server, > I've populated the specified files, d/l'd the cert, am able to configure > Users and Groups objects/attribs and browse both from within OSX's > Directory Utility. ldapsearch similarly returns the expected results. > > In spite of this, i'm unable to authenticate as any IPA-LDAP user on this > system > > dirsrv log on the ipa master shows no apparent errors - remote auth > attempts exit with "RESULT err=0 tag=101 nentries=1 etime=0", but tell the > truth, there so much stuff there and being rather inexperienced with LDAP > diags i might easily be missing something in the details > > The linsec.ca instructions were written in the 10.7-10.8 era so something > may have changed since. Having said that, we've had no problems > authenticating against our existing OpenLDAP server (which IPA is slated to > replace) right up to 10.10.5 with no zero to our Directory Utility setup. > > Hoping someone here has some contemporary experience with OSX and IPA and > for whom this issue rings a bell? > > many thanks > > Cal Sawyer | Systems Engineer | BlueBolt Ltd > 15-16 Margaret Street | London W1W 8RW > +44 (0)20 7637 5575 | www.blue-bolt.com > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From canepa.n at mmfg.it Mon Dec 21 07:57:36 2015 From: canepa.n at mmfg.it (Nicola Canepa) Date: Mon, 21 Dec 2015 08:57:36 +0100 Subject: [Freeipa-users] OS X Yosemite unable to authenticate In-Reply-To: References: <5676B69A.6040501@blue-bolt.com> Message-ID: <5677B0F0.6000105@mmfg.it> Hello, I tried 2 weeks ago from Mavericks (OSX 10.9), but I had the opposite problem: kinit works fine, while I'm unable to see users with Directory Admin ((it always says it cant' connect, either with or without SSL) I disabled anonymous searches in 389-ds, by the way. Nicola Il 21/12/15 07:50, John Obaterspok ha scritto: > Hi Cal, > > Does a kinit work from a terminal? Does it work if you use "kinit > user" or just if you use "kinit user at REALM.suffix" > > -- john > > > 2015-12-20 15:09 GMT+01:00 Cal Sawyer >: > > Hi, all > > I'm attempting to set up LDAP auth (against IPA server 4.10) from > a OSX 10.10.5 (Yosemite) client > > Using the excellent instructions at > http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8%20%22Linsec.ca%20tutorial%20for%20connecting%20Mac%20OS%2010.7%20to%20IPA%20Server, > I've populated the specified files, d/l'd the cert, am able to > configure Users and Groups objects/attribs and browse both from > within OSX's Directory Utility. ldapsearch similarly returns > the expected results. > > In spite of this, i'm unable to authenticate as any IPA-LDAP user > on this system > > dirsrv log on the ipa master shows no apparent errors - remote > auth attempts exit with "RESULT err=0 tag=101 nentries=1 etime=0", > but tell the truth, there so much stuff there and being rather > inexperienced with LDAP diags i might easily be missing something > in the details > > The linsec.ca instructions were written in the > 10.7-10.8 era so something may have changed since. Having said > that, we've had no problems authenticating against our existing > OpenLDAP server (which IPA is slated to replace) right up to > 10.10.5 with no zero to our Directory Utility setup. > > Hoping someone here has some contemporary experience with OSX and > IPA and for whom this issue rings a bell? > > many thanks > > Cal Sawyer | Systems Engineer | BlueBolt Ltd > 15-16 Margaret Street | London W1W 8RW > +44 (0)20 7637 5575 | > www.blue-bolt.com > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > > > > -- Nicola Canepa Tel: +39-0522-399-3474 canepa.n at mmfg.it --- Il contenuto della presente comunicazione ? riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avr? valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, n? rinuncia o riconoscimento di diritti, debiti e/o crediti, n? sar? impegnativa, qualora non sia sottoscritto successivo accordo da chi pu? validamente obbligarci. Non deriver? alcuna responsabilit? precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti. The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bahanw042014 at gmail.com Mon Dec 21 10:23:20 2015 From: bahanw042014 at gmail.com (bahan w) Date: Mon, 21 Dec 2015 11:23:20 +0100 Subject: [Freeipa-users] FreeIPA availability, what to do client side ? Message-ID: Hello ! I contact you because I have a question relative to high availbility with FreeIPA and replications. In the documentation, we can see information about what to do server side. But I can't find any information about what to do client side. Imagine one of the master server crash, how the client knows where to switch ? What is the configuration to perform to allow this switch. Thank you in advance for these informations ! Best regards. Bahan -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Dec 21 10:36:56 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 21 Dec 2015 12:36:56 +0200 Subject: [Freeipa-users] FreeIPA availability, what to do client side ? In-Reply-To: References: Message-ID: <20151221103656.GD5255@redhat.com> On Mon, 21 Dec 2015, bahan w wrote: >Hello ! > >I contact you because I have a question relative to high availbility with >FreeIPA and replications. >In the documentation, we can see information about what to do server side. > >But I can't find any information about what to do client side. > >Imagine one of the master server crash, how the client knows where to >switch ? What is the configuration to perform to allow this switch. > >Thank you in advance for these informations ! Please read archives of this mailing list. There was a thread just a week or two ago were this question was answered from multiple angles. -- / Alexander Bokovoy From pspacek at redhat.com Mon Dec 21 11:38:26 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 21 Dec 2015 12:38:26 +0100 Subject: [Freeipa-users] FreeIPA availability, what to do client side ? In-Reply-To: <20151221103656.GD5255@redhat.com> References: <20151221103656.GD5255@redhat.com> Message-ID: <5677E4B2.2060302@redhat.com> On 21.12.2015 11:36, Alexander Bokovoy wrote: > On Mon, 21 Dec 2015, bahan w wrote: >> Hello ! >> >> I contact you because I have a question relative to high availbility with >> FreeIPA and replications. >> In the documentation, we can see information about what to do server side. >> >> But I can't find any information about what to do client side. >> >> Imagine one of the master server crash, how the client knows where to >> switch ? What is the configuration to perform to allow this switch. >> >> Thank you in advance for these informations ! > Please read archives of this mailing list. There was a thread just a > week or two ago were this question was answered from multiple angles. Here is the link: https://www.redhat.com/archives/freeipa-users/2015-December/msg00184.html -- Petr^2 Spacek From ejnersan at gmail.com Mon Dec 21 09:27:35 2015 From: ejnersan at gmail.com (Ejner Fergo) Date: Mon, 21 Dec 2015 10:27:35 +0100 Subject: [Freeipa-users] OS X Yosemite unable to authenticate In-Reply-To: <5676B69A.6040501@blue-bolt.com> References: <5676B69A.6040501@blue-bolt.com> Message-ID: I've setup some OSX (10.9 + 10.10) machines to authenticate against IPA (centos 7.x), and like you I've followed the linsec.ca tutorial precisely. I haven't had problems login in as an IPA user on any system I have setup, so I'm afraid this reply is pretty useless to you. Only issue that I had, that the linsec.ca tutorial didn't mention, was support for nested groups. I managed to figure it out, by adding this Group object/attribute: GroupMemberShip / memberUid Sorry I can't help you, just wanted to let you know it is possible to use. Best regards, Ejner Fergo On Sunday, December 20, 2015, Cal Sawyer wrote: > Hi, all > > I'm attempting to set up LDAP auth (against IPA server 4.10) from a OSX 10.10.5 (Yosemite) client > > Using the excellent instructions at http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8%20%22Linsec.ca%20tutorial%20for%20connecting%20Mac%20OS%2010.7%20to%20IPA%20Server, I've populated the specified files, d/l'd the cert, am able to configure Users and Groups objects/attribs and browse both from within OSX's Directory Utility. ldapsearch similarly returns the expected results. > > In spite of this, i'm unable to authenticate as any IPA-LDAP user on this system > > dirsrv log on the ipa master shows no apparent errors - remote auth attempts exit with "RESULT err=0 tag=101 nentries=1 etime=0", but tell the truth, there so much stuff there and being rather inexperienced with LDAP diags i might easily be missing something in the details > > The linsec.ca instructions were written in the 10.7-10.8 era so something may have changed since. Having said that, we've had no problems authenticating against our existing OpenLDAP server (which IPA is slated to replace) right up to 10.10.5 with no zero to our Directory Utility setup. > > Hoping someone here has some contemporary experience with OSX and IPA and for whom this issue rings a bell? > > many thanks > > Cal Sawyer | Systems Engineer | BlueBolt Ltd > 15-16 Margaret Street | London W1W 8RW > +44 (0)20 7637 5575 | www.blue-bolt.com > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.forner at gmail.com Mon Dec 21 12:57:02 2015 From: karl.forner at gmail.com (Karl Forner) Date: Mon, 21 Dec 2015 13:57:02 +0100 Subject: [Freeipa-users] ipa-replica-prepare error: Profile caIPAserviceCert Not Found Message-ID: Hello, Running: ipa-replica-prepare ipa-h3s1.example.com --ip-address xx.xx.xx.xx -d -v fails with ipa: DEBUG: Protocol: TLS1.2 ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_128_CBC_SHA ipa: DEBUG: request status 200 ipa: DEBUG: request reason_phrase u'OK' ipa: DEBUG: request headers {'date': 'Mon, 21 Dec 2015 12:50:59 GMT', 'content-length': '148', 'content-type': 'application/xml', 'server': 'Apache-Coyote/1.1'} ipa: DEBUG: request body '1Profile caIPAserviceCert Not Found' ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute The context is probably unusual: I run the command on a replica with CA from a server in freeipa v4.1.4 (in a adelton/freeipa-server docker) which is a freeipa v4.2.3 running in adelton/freeipa-server:lastest-systemd docker I found this ticket which looks similar: https://fedorahosted.org/freeipa/ticket/5376 Is there something wrong with my replica knowing that it has been replicated from a 4.1.4 ? Is there a work-around ? Thanks Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andy.Thompson at e-tcc.com Mon Dec 21 13:22:00 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Mon, 21 Dec 2015 13:22:00 +0000 Subject: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system In-Reply-To: <5661BB57.7070001@redhat.com> References: <20151202210209.GD8374@redhat.com> <565FF769.3010707@redhat.com> <5660B7AF.2070209@redhat.com> <2864351c1611466d84893c4200a24416@TCCCORPEXCH02.TCC.local> <5661BB57.7070001@redhat.com> Message-ID: > >> > >> -----Original Message----- > >> From: freeipa-users-bounces at redhat.com >> users-bounces at redhat.com> [mailto:freeipa-users- > >> bounces at redhat.com ] On > Behalf Of Petr > >> Spacek > >> Sent: Thursday, December 3, 2015 3:04 AM > >> To: freeipa-users at redhat.com users at redhat.com> > >> Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd > hanging > >> system > >> > >> On 2.12.2015 22:02, Alexander Bokovoy wrote: > >> > >> On Wed, 02 Dec 2015, Andy Thompson wrote: > >> > >> Since updating to RHEL 7.2 I've got issues with > ns-slapd hanging > >> the > >> system up after a period of time. The > directory becomes > >> unresponsive > >> to searches or any connections. After a > restart I see > >> > >> [02/Dec/2015:15:27:41 -0500] - slapd started. > >> Listening on All > >> Interfaces port 389 for LDAP requests > >> [02/Dec/2015:15:27:41 -0500] - Listening on > All Interfaces port > >> 636 > >> for LDAPS requests > >> [02/Dec/2015:15:27:41 -0500] - Listening on > >> /var/run/slapd-MHBENP-LIN.socket for > LDAPI requests > >> [02/Dec/2015:15:27:44 -0500] > >> NSMMReplicationPlugin - > >> agmt="cn=meTomdhixnpipa02.mhbenp.lin" > >> (mdhixnpipa02:389): > >> > >> Replication > >> > >> bind with GSSAPI auth resumed > >> [02/Dec/2015:15:27:47 -0500] > >> NSMMReplicationPlugin - replication keep > >> alive entry >> 4,dc=mhbenp,dc=lin> already exists > >> > >> In the logs and occasionally the keepalive > entry message is seen > >> a > >> few times and then eventually the ns-slapd > taps the system. 100% > >> util, system load crawls up between 30 and 40 > and eventually I > >> have > >> to restart the service to get it to respond > again. Memory usage > >> is > >> normal, db and entry cache is sufficient.. > >> possibly a little on the > >> high side but resource is sitting there asking > to be used :) > >> > >> Running 389-ds-base-1.3.4.0-19.el7.x86_64 > after the update > >> yesterday. > >> > >> What additional information can I provide? > >> > >> install debuginfo for 389-ds-base and slapi-nis, and > take a pstack > >> output for ns-slapd pid. > >> > >> > >> For detailed instructions please see > >> > >> http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug > >> _hangs > >> > >> > >> > >> Here is the resulting stacktrace during the last hang. > >> > >> > >> The server is idle at this point. None of the threads are doing any work, or > >> are blocked/deadlocked. It does not appear hung at all. > >> > >> When the server is in the "hung" state again, use ldapsearch (e.g. -s base - > b > >> "") to "ping" the server to see if it is entirely unresponsive. > >> > >> > >> > > No ldapsearch does not respond, it just hangs and doesn't ever return. > > Try doing an strace of ldapsearch to see in what system call it is stuck > in (or you can just do an strace/pstack on the running, hung ldapsearch > process). > I ended up opening a ticket with Redhat but wanted to pass along that Thierry tracked it down to this bug https://fedorahosted.org/freeipa/ticket/5464 I bumped up the nsslapd-threadnumber and things have settled down it appears, been running since Friday with no issues. -andy From pdomineaux at gmail.com Mon Dec 21 16:29:01 2015 From: pdomineaux at gmail.com (Gmail) Date: Mon, 21 Dec 2015 17:29:01 +0100 Subject: [Freeipa-users] NetworkError : invalid continuation byte with utf8 codec Message-ID: Hi all, When trying to install on a fresh new Centos 7 I?ve got this error : 2015-12-21T16:04:44Z DEBUG The ipa-server-install command failed, exception: NetworkError: cannot connect to 'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't decode byte 0xea in position 13: invalid continuation byte 2015-12-21T16:04:44Z ERROR cannot connect to 'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't decode byte 0xea in position 13: invalid continuation byte My freeipa-server version is : ?4.2.0 I?m running a Centos 3.10.0-327.3.1.el7.x86_64 Any idea of what goes wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal-s at blue-bolt.com Mon Dec 21 16:39:26 2015 From: cal-s at blue-bolt.com (Cal Sawyer) Date: Mon, 21 Dec 2015 16:39:26 +0000 Subject: [Freeipa-users] OS X Yosemite unable to authenticate In-Reply-To: <5677B0F0.6000105@mmfg.it> References: <5676B69A.6040501@blue-bolt.com> <5677B0F0.6000105@mmfg.it> Message-ID: <56782B3E.2030103@blue-bolt.com> Thanks, John and Nicola Kerberos occurred to me as well late in the day yesterday. Happily (?), knit works fine simply specifying the user in question with no need to suffix with the kerberos realm I did find that my test user had an expired password, which i fixed on the IPA server. This was never flagged up under Linux, btw. It has not change anything, however, other than not prompting for password changes that never take effect. Funnily, it expired in the midst of testing - fun. I was mistaken when i said i was unable to log in - it turns out that it takes almost 10 minutes for a login from the frintend to complete - i just didn't wait long enough. 10 mins is of course unacceptable :) "su - user" and "login user" fail outright after rejecting accept any user's password DNS is fine and i can resolve ldap and kerberos SRV records from the Mac In line with Nicola's experience, i can browse groups and users in the Directory Editor and all attributes appear spot on. Besides modding /etc/pam.d/authorization, adding a corrected edu.mit.kerberos to /LibraryPreferences and setting up the directory per linsec.ca, can anyone think of something i may have missed? It's a real shame that the documentation on this stops around 5 years ago. IPA devs: is there anything i should be on the lookout for in the dirsrv or krb5 logs on the IPA master? I've disabled the secondary to prevent replication from clouding the log events thanks, everyone Cal Sawyer | Systems Engineer | BlueBolt Ltd 15-16 Margaret Street | London W1W 8RW +44 (0)20 7637 5575 | www.blue-bolt.com On 21/12/15 07:57, Nicola Canepa wrote: > Hello, I tried 2 weeks ago from Mavericks (OSX 10.9), but I had the > opposite problem: kinit works fine, while I'm unable to see users with > Directory Admin ((it always says it cant' connect, either with or > without SSL) > I disabled anonymous searches in 389-ds, by the way. > > Nicola > > Il 21/12/15 07:50, John Obaterspok ha scritto: >> Hi Cal, >> >> Does a kinit work from a terminal? Does it work if you use "kinit >> user" or just if you use "kinit user at REALM.suffix" >> >> -- john >> >> >> 2015-12-20 15:09 GMT+01:00 Cal Sawyer > >: >> >> Hi, all >> >> I'm attempting to set up LDAP auth (against IPA server 4.10) from >> a OSX 10.10.5 (Yosemite) client >> >> Using the excellent instructions at >> http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8%20%22Linsec.ca%20tutorial%20for%20connecting%20Mac%20OS%2010.7%20to%20IPA%20Server, >> I've populated the specified files, d/l'd the cert, am able to >> configure Users and Groups objects/attribs and browse both from >> within OSX's Directory Utility. ldapsearch similarly returns the >> expected results. >> >> In spite of this, i'm unable to authenticate as any IPA-LDAP user >> on this system >> >> dirsrv log on the ipa master shows no apparent errors - remote >> auth attempts exit with "RESULT err=0 tag=101 nentries=1 >> etime=0", but tell the truth, there so much stuff there and being >> rather inexperienced with LDAP diags i might easily be missing >> something in the details >> >> The linsec.ca instructions were written in the >> 10.7-10.8 era so something may have changed since. Having said >> that, we've had no problems authenticating against our existing >> OpenLDAP server (which IPA is slated to replace) right up to >> 10.10.5 with no zero to our Directory Utility setup. >> >> Hoping someone here has some contemporary experience with OSX and >> IPA and for whom this issue rings a bell? >> >> many thanks >> >> Cal Sawyer | Systems Engineer | BlueBolt Ltd >> 15-16 Margaret Street | London W1W 8RW >> +44 (0)20 7637 5575 | >> www.blue-bolt.com >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project >> >> >> >> > > -- > > Nicola Canepa > Tel: +39-0522-399-3474 > canepa.n at mmfg.it > --- > Il contenuto della presente comunicazione ? riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avr? valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, n? rinuncia o riconoscimento di diritti, debiti e/o crediti, n? sar? impegnativa, qualora non sia sottoscritto successivo accordo da chi pu? validamente obbligarci. Non deriver? alcuna responsabilit? precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti. > > The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.forner at gmail.com Mon Dec 21 16:35:10 2015 From: karl.forner at gmail.com (Karl Forner) Date: Mon, 21 Dec 2015 17:35:10 +0100 Subject: [Freeipa-users] unable to effectively delete a replica agreement In-Reply-To: References: Message-ID: It's quite a problem for me. Would upgrading to a more recent version solve the problem ? How does freeIPA knows that a host is a freeIPA host ? From the LDAP ? Thanks On Fri, Dec 18, 2015 at 3:45 PM, Karl Forner wrote: > I am running a master freeIPA called "ipa" in an adelton/freeipa-server > (freeIPA 4.1.4). > I am able to create a replica server "ipa2", still in an > adelton/freeipa-server. > > If I stop my ipa2 replica, and try to delete the replication agreement: > > %ipa-replica-manage del ipa2.example.com --force -v > > It hangs forever. > If I run it using the --cleanup option, it seems to work. > > But when I try to run again from scratch my replica, using the same name, > I get: > > Checking forwarders, please wait ... > WARNING: DNS forwarder 10.9.70.7 does not return DNSSEC signatures in > answers > Please fix forwarder configuration to enable DNSSEC support. > (For BIND 9 add directive "dnssec-enable yes;" to "options {}") > WARNING: DNSSEC validation will be disabled > Warning: skipping DNS resolution of host ipa2.example.com > Warning: skipping DNS resolution of host ipa.example.com > Using reverse zone(s) 0.17.172.in-addr.arpa. > A replication agreement for this host already exists. It needs to be > removed. > Run this on the master that generated the info file: > % ipa-replica-manage del ipa2.example.com --force > > On my master: > # ipa-replica-manage list > ipas.example.com: master > ipa.example.com: master > > I manually removed all DNS entries from the 3 zones mentioning ipa2. I can > check in the web UI, using the search feature that ipa2 has no occurrence. > > So I do not understand why the replica install thinks there's still a > replication agreement. > And I'd like to know: > 1) why this command did not work > > ipa-replica-manage del ipa2.example.com --force -v > > > 2) How could I manually effectively delete this agrrement left-over. > > > Thanks. > Karl > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From canepa.n at mmfg.it Mon Dec 21 16:49:28 2015 From: canepa.n at mmfg.it (Nicola Canepa) Date: Mon, 21 Dec 2015 17:49:28 +0100 Subject: [Freeipa-users] OS X Yosemite unable to authenticate In-Reply-To: <56782B3E.2030103@blue-bolt.com> References: <5676B69A.6040501@blue-bolt.com> <5677B0F0.6000105@mmfg.it> <56782B3E.2030103@blue-bolt.com> Message-ID: <56782D98.9030503@mmfg.it> I had to configure /etc/krb5.conf, and to avoid the requested reboot, I did a "dscacheutil -flushcache", both as the logged in user and as root. I tried enabling the anonymous bind and now also the directory browser (and all the login process) works as expected. Nicola Il 21/12/15 17:39, Cal Sawyer ha scritto: > Thanks, John and Nicola > > Kerberos occurred to me as well late in the day yesterday. Happily > (?), knit works fine simply specifying the user in question with no > need to suffix with the kerberos realm > > I did find that my test user had an expired password, which i fixed on > the IPA server. This was never flagged up under Linux, btw. It has > not change anything, however, other than not prompting for password > changes that never take effect. Funnily, it expired in the midst of > testing - fun. > > I was mistaken when i said i was unable to log in - it turns out that > it takes almost 10 minutes for a login from the frintend to complete - > i just didn't wait long enough. 10 mins is of course unacceptable :) > "su - user" and "login user" fail outright after rejecting accept any > user's password > > DNS is fine and i can resolve ldap and kerberos SRV records from the Mac > > In line with Nicola's experience, i can browse groups and users in the > Directory Editor and all attributes appear spot on. > > Besides modding /etc/pam.d/authorization, adding a corrected > edu.mit.kerberos to /LibraryPreferences and setting up the directory > per linsec.ca, can anyone think of something i may have missed? It's > a real shame that the documentation on this stops around 5 years ago. > > IPA devs: is there anything i should be on the lookout for in the > dirsrv or krb5 logs on the IPA master? I've disabled the secondary to > prevent replication from clouding the log events > > thanks, everyone > Cal Sawyer | Systems Engineer | BlueBolt Ltd > 15-16 Margaret Street | London W1W 8RW > +44 (0)20 7637 5575 |www.blue-bolt.com > > On 21/12/15 07:57, Nicola Canepa wrote: >> Hello, I tried 2 weeks ago from Mavericks (OSX 10.9), but I had the >> opposite problem: kinit works fine, while I'm unable to see users >> with Directory Admin ((it always says it cant' connect, either with >> or without SSL) >> I disabled anonymous searches in 389-ds, by the way. >> >> Nicola >> >> Il 21/12/15 07:50, John Obaterspok ha scritto: >>> Hi Cal, >>> >>> Does a kinit work from a terminal? Does it work if you use "kinit >>> user" or just if you use "kinit user at REALM.suffix" >>> >>> -- john >>> >>> >>> 2015-12-20 15:09 GMT+01:00 Cal Sawyer >> >: >>> >>> Hi, all >>> >>> I'm attempting to set up LDAP auth (against IPA server 4.10) >>> from a OSX 10.10.5 (Yosemite) client >>> >>> Using the excellent instructions at >>> http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8%20%22Linsec.ca%20tutorial%20for%20connecting%20Mac%20OS%2010.7%20to%20IPA%20Server, >>> I've populated the specified files, d/l'd the cert, am able to >>> configure Users and Groups objects/attribs and browse both from >>> within OSX's Directory Utility. ldapsearch similarly returns the >>> expected results. >>> >>> In spite of this, i'm unable to authenticate as any IPA-LDAP >>> user on this system >>> >>> dirsrv log on the ipa master shows no apparent errors - remote >>> auth attempts exit with "RESULT err=0 tag=101 nentries=1 >>> etime=0", but tell the truth, there so much stuff there and >>> being rather inexperienced with LDAP diags i might easily be >>> missing something in the details >>> >>> The linsec.ca instructions were written in >>> the 10.7-10.8 era so something may have changed since. Having >>> said that, we've had no problems authenticating against our >>> existing OpenLDAP server (which IPA is slated to replace) right >>> up to 10.10.5 with no zero to our Directory Utility setup. >>> >>> Hoping someone here has some contemporary experience with OSX >>> and IPA and for whom this issue rings a bell? >>> >>> many thanks >>> >>> Cal Sawyer | Systems Engineer | BlueBolt Ltd >>> 15-16 Margaret Street | London W1W 8RW >>> +44 (0)20 7637 5575 | >>> www.blue-bolt.com >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go to http://freeipa.org for more info on the project >>> >>> >>> >>> >> >> -- >> >> Nicola Canepa >> Tel: +39-0522-399-3474 >> canepa.n at mmfg.it >> --- >> Il contenuto della presente comunicazione ? riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avr? valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, n? rinuncia o riconoscimento di diritti, debiti e/o crediti, n? sar? impegnativa, qualora non sia sottoscritto successivo accordo da chi pu? validamente obbligarci. Non deriver? alcuna responsabilit? precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti. >> >> The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties. > -- Nicola Canepa Tel: +39-0522-399-3474 canepa.n at mmfg.it --- Il contenuto della presente comunicazione ? riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avr? valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, n? rinuncia o riconoscimento di diritti, debiti e/o crediti, n? sar? impegnativa, qualora non sia sottoscritto successivo accordo da chi pu? validamente obbligarci. Non deriver? alcuna responsabilit? precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti. The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daryl.Fonseca-Holt at umanitoba.ca Mon Dec 21 16:55:22 2015 From: Daryl.Fonseca-Holt at umanitoba.ca (Daryl Fonseca-Holt) Date: Mon, 21 Dec 2015 10:55:22 -0600 Subject: [Freeipa-users] Want faster user-add Message-ID: <56782EFA.1090300@umanitoba.ca> Hi all, Environment: RHEL6 with IPA 3.0 at current RedHat level. 64-core 256-GB RAM Oracle x4470 M2. During our migration from NIS on Solaris 140,000+ accounts will be added. After tuning per the guides dbmon.sh shows no roevicts and we get high cache hit ratios. Per a previous discussion with the list the input is broken down into batches of less than 1,000 users and the default IPA group is changed before each batch. This helped greatly. Adding all the users takes many hours. Initially ipa user-add takes an average 2.3 seconds per user but degrades by the time there are 140,000 users to an average 6.7 seconds per user. In tracing it appears that a significant portion of the time ipa user-add takes is not the add itself, it is the query at the end that displays the resulting user account. Is there any legit way to prevent this query? The length of time it takes to migrate is not a big concern. The concern is the start of the fall school term when we typically add approximately 1,300 accounts per hour during the registration period with our current system. All suggestions will be appreciated. Regards, Daryl -- -- Daryl Fonseca-Holt IST/CNS/Unix Server Team University of Manitoba 204.480.1079 From peter at pakos.pl Mon Dec 21 16:43:19 2015 From: peter at pakos.pl (Peter Pakos) Date: Mon, 21 Dec 2015 16:43:19 +0000 Subject: [Freeipa-users] Using 3rd party certificates for HTTP/LDAP Message-ID: <56782C27.3000102@pakos.pl> Hi, I tried to install a wildcard SSL certificate for HTTP/LDAP in our FreeIPA 4.1 (Centos 7.1) installation by following instructions from wiki page at http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP: # ipa-server-certinstall -w -d shdc01.ipa.wandisco.com.pem Directory Manager password: Enter private key unlock password: Command /usr/bin/certutil' '-d' '/etc/httpd/alias' '-D' '-n' 'Server-Cert returned non-zero exit status 255 After this I was unable to start httpd service, error_log revealed the following error messages: [Wed Nov 25 18:15:44.262751 2015] [:error] [pid 22124] Certificate not found: 'Server-Cert' In order to resurrect the service I had to change NSSNickname in /etc/httpd/conf.d/nss.conf to match the new certificate's nickname. Although the httpd service started, I couldn't get into Authentication tab in FreeIPA UI - I kept getting the following error message: "Unable to communicate with CMS (Service Unavailable)". [root at shdc01 ~]# yum list installed | grep ipa-server ipa-server.x86_64 4.1.0-18.el7.centos.4 @updates [root at shdc01 ~]# cat /etc/redhat-release CentOS Linux release 7.1.1503 (Core) At this point I was forced to restore our FreeIPA installation from a snapshot as I wasn't able to fix it (I got some useful hints from #freeipa Freenode channel however we still didn't manage to fully resurrect the server). My question is, what is the correct way of installing a 3rd party certificate for HTTP/LDAP that will actually work? Many thanks in advance. BTW, I also added a comment describing this problem to the ticket at https://fedorahosted.org/freeipa/ticket/5496. -- Kind regards, Peter Pakos From alex.williams at brighter-technology.com Mon Dec 21 16:49:21 2015 From: alex.williams at brighter-technology.com (Alex Williams) Date: Mon, 21 Dec 2015 16:49:21 +0000 Subject: [Freeipa-users] Issues with 'A replication agreement for the host already exists', when it very much doesn't Message-ID: <56782D91.1020605@brighter-technology.com> I began installing a new ipa4 replica this morning and it all went wrong. The ipa-replica-install script got all the way to restarting ipa with systemctl at the very end, having set up replication and then fell over, because systemctl couldn't find the ipa service. I removed the replica from our master, I deleted the host from there too, I un-installed ipa-server on the new replica machine, I even created a new replica-prepare script on the master, but now the server just errors immediately with: A replication agreement for this host already exists. It needs to be removed. I've verified several times, that no replica, or host with the same name exists in the master, there are no ldap entries under masters, with that hostname, nothing. There is literally no trace of the new host, on the old master. Running `ipa-replica-manage list` shows just the 3 ipa servers we have already, no sign of this new host. Yet, if I run `ipa-replica-manage del hostname --force` on the master, it will in fact say that it's forcing removal, skipping checking if anything will be orphaned and that no RUV records were found. I'm now lost, I really don't know where to start with fixing this. Not sure if this is relevant or not, but I'd rather bring it up and it not be, than not mention it and it turn out to be the reason. Our yum mirror is unfortunately now holding rhel7.2 packages, whilst our servers, are still on rhel7.1, which means our existing IPA servers, are ipa4.1 and the new one I tried to install, was ipa4.2, but on a rhel7.1 box. I had previously attributed the failed systemctl command, to the fact that I was trying to run ipa4.2 on a rhel7.1 box, as I'm told there were a lot of modifications to systemctl in rhel7.2, but I need to fix this replication agreement issue, before I can try again with the box upgraded to rhel7.2. Any ideas? Cheers Alex From ftweedal at redhat.com Tue Dec 22 01:30:01 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 22 Dec 2015 11:30:01 +1000 Subject: [Freeipa-users] NetworkError : invalid continuation byte with utf8 codec In-Reply-To: References: Message-ID: <20151222013001.GT23644@dhcp-40-8.bne.redhat.com> On Mon, Dec 21, 2015 at 05:29:01PM +0100, Gmail wrote: > Hi all, > > When trying to install on a fresh new Centos 7 I?ve got this error : > > 2015-12-21T16:04:44Z DEBUG The ipa-server-install command failed, exception: NetworkError: cannot connect to 'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't decode byte 0xea in position 13: invalid continuation byte > 2015-12-21T16:04:44Z ERROR cannot connect to 'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't decode byte 0xea in position 13: invalid continuation byte > > My freeipa-server version is : ?4.2.0 > I?m running a Centos 3.10.0-327.3.1.el7.x86_64 > > Any idea of what goes wrong? > Thanks for reporting. I have not seen this error before. Could you please include the following log files and I will take a closer look: /var/log/ipaserver-install.log /var/log/pki/pki-tomcat/ca/debug Cheers, Fraser From ftweedal at redhat.com Tue Dec 22 01:46:54 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 22 Dec 2015 11:46:54 +1000 Subject: [Freeipa-users] ipa-replica-prepare error: Profile caIPAserviceCert Not Found In-Reply-To: References: Message-ID: <20151222014654.GU23644@dhcp-40-8.bne.redhat.com> On Mon, Dec 21, 2015 at 01:57:02PM +0100, Karl Forner wrote: > Hello, > > Running: > ipa-replica-prepare ipa-h3s1.example.com --ip-address xx.xx.xx.xx -d -v > fails > with > ipa: DEBUG: Protocol: TLS1.2 > ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_128_CBC_SHA > ipa: DEBUG: request status 200 > ipa: DEBUG: request reason_phrase u'OK' > ipa: DEBUG: request headers {'date': 'Mon, 21 Dec 2015 12:50:59 GMT', > 'content-length': '148', 'content-type': 'application/xml', 'server': > 'Apache-Coyote/1.1'} > ipa: DEBUG: request body ' standalone="no"?>1Profile > caIPAserviceCert Not Found' > ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in > execute > > The context is probably unusual: > I run the command on a replica with CA from a server in freeipa v4.1.4 (in > a adelton/freeipa-server docker) > which is a freeipa v4.2.3 running in > adelton/freeipa-server:lastest-systemd docker > > I found this ticket which looks similar: > https://fedorahosted.org/freeipa/ticket/5376 > > Is there something wrong with my replica knowing that it has been > replicated from a 4.1.4 ? > Is there a work-around ? > > Thanks > Karl Hi Karl, I have a patch for Dogtag that I think will fix this issue. Would you be willing to test it? If so, which version of Fedora/RHEL are you using and I will prepare a build. Regards, Fraser > -- > 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 From pdomineaux at gmail.com Tue Dec 22 07:39:09 2015 From: pdomineaux at gmail.com (Gmail) Date: Tue, 22 Dec 2015 08:39:09 +0100 Subject: [Freeipa-users] NetworkError : invalid continuation byte with utf8 codec In-Reply-To: <20151222013001.GT23644@dhcp-40-8.bne.redhat.com> References: <20151222013001.GT23644@dhcp-40-8.bne.redhat.com> Message-ID: Here are the files you ask for: Le 22 d?cembre 2015 ? 02:30:06, Fraser Tweedale (ftweedal at redhat.com) a ?crit: On Mon, Dec 21, 2015 at 05:29:01PM +0100, Gmail wrote: > Hi all, > > When trying to install on a fresh new Centos 7 I?ve got this error : > > 2015-12-21T16:04:44Z DEBUG The ipa-server-install command failed, exception: NetworkError: cannot connect to 'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't decode byte 0xea in position 13: invalid continuation byte > 2015-12-21T16:04:44Z ERROR cannot connect to 'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't decode byte 0xea in position 13: invalid continuation byte > > My freeipa-server version is : ?4.2.0 > I?m running a Centos 3.10.0-327.3.1.el7.x86_64 > > Any idea of what goes wrong? > Thanks for reporting. I have not seen this error before. Could you please include the following log files and I will take a closer look: /var/log/ipaserver-install.log /var/log/pki/pki-tomcat/ca/debug Cheers, Fraser -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: debug Type: application/octet-stream Size: 942940 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipaserver-install.log Type: application/octet-stream Size: 271791 bytes Desc: not available URL: From john.obaterspok at gmail.com Tue Dec 22 06:07:13 2015 From: john.obaterspok at gmail.com (John Obaterspok) Date: Tue, 22 Dec 2015 07:07:13 +0100 Subject: [Freeipa-users] OS X Yosemite unable to authenticate In-Reply-To: <56782D98.9030503@mmfg.it> References: <5676B69A.6040501@blue-bolt.com> <5677B0F0.6000105@mmfg.it> <56782B3E.2030103@blue-bolt.com> <56782D98.9030503@mmfg.it> Message-ID: Hi, Are you only having problems to login to login to OSX with the IPA user now? If that is the case then check the DNS settings you are using and make sure the IPA server is listed first and that it has full name. Exactly the same problem occurred for me with the slow logins to OSX which was due to the DNS settings and that OSX only used short name of IPA server during login (if I logged in as local user I could ping and lookup hosts using short name) -- john 2015-12-21 17:49 GMT+01:00 Nicola Canepa : > I had to configure /etc/krb5.conf, and to avoid the requested reboot, I > did a "dscacheutil -flushcache", both as the logged in user and as root. > I tried enabling the anonymous bind and now also the directory browser > (and all the login process) works as expected. > > Nicola > > Il 21/12/15 17:39, Cal Sawyer ha scritto: > > Thanks, John and Nicola > > Kerberos occurred to me as well late in the day yesterday. Happily (?), > knit works fine simply specifying the user in question with no need to > suffix with the kerberos realm > > I did find that my test user had an expired password, which i fixed on the > IPA server. This was never flagged up under Linux, btw. It has not change > anything, however, other than not prompting for password changes that never > take effect. Funnily, it expired in the midst of testing - fun. > > I was mistaken when i said i was unable to log in - it turns out that it > takes almost 10 minutes for a login from the frintend to complete - i just > didn't wait long enough. 10 mins is of course unacceptable :) "su - user" > and "login user" fail outright after rejecting accept any user's password > > DNS is fine and i can resolve ldap and kerberos SRV records from the Mac > > In line with Nicola's experience, i can browse groups and users in the > Directory Editor and all attributes appear spot on. > > Besides modding /etc/pam.d/authorization, adding a corrected > edu.mit.kerberos to /LibraryPreferences and setting up the directory per > linsec.ca, can anyone think of something i may have missed? It's a real > shame that the documentation on this stops around 5 years ago. > > IPA devs: is there anything i should be on the lookout for in the dirsrv > or krb5 logs on the IPA master? I've disabled the secondary to prevent > replication from clouding the log events > > thanks, everyone > > Cal Sawyer | Systems Engineer | BlueBolt Ltd > 15-16 Margaret Street | London W1W 8RW+44 (0)20 7637 5575 | www.blue-bolt.com > > On 21/12/15 07:57, Nicola Canepa wrote: > > Hello, I tried 2 weeks ago from Mavericks (OSX 10.9), but I had the > opposite problem: kinit works fine, while I'm unable to see users with > Directory Admin ((it always says it cant' connect, either with or without > SSL) > I disabled anonymous searches in 389-ds, by the way. > > Nicola > > Il 21/12/15 07:50, John Obaterspok ha scritto: > > Hi Cal, > > Does a kinit work from a terminal? Does it work if you use "kinit user" or > just if you use "kinit user at REALM.suffix" > > -- john > > > 2015-12-20 15:09 GMT+01:00 Cal Sawyer : > >> Hi, all >> >> I'm attempting to set up LDAP auth (against IPA server 4.10) from a OSX >> 10.10.5 (Yosemite) client >> >> Using the excellent instructions at >> >> http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8%20%22Linsec.ca%20tutorial%20for%20connecting%20Mac%20OS%2010.7%20to%20IPA%20Server, >> I've populated the specified files, d/l'd the cert, am able to configure >> Users and Groups objects/attribs and browse both from within OSX's >> Directory Utility. ldapsearch similarly returns the expected results. >> >> In spite of this, i'm unable to authenticate as any IPA-LDAP user on this >> system >> >> dirsrv log on the ipa master shows no apparent errors - remote auth >> attempts exit with "RESULT err=0 tag=101 nentries=1 etime=0", but tell the >> truth, there so much stuff there and being rather inexperienced with LDAP >> diags i might easily be missing something in the details >> >> The linsec.ca instructions were written in the 10.7-10.8 era so >> something may have changed since. Having said that, we've had no problems >> authenticating against our existing OpenLDAP server (which IPA is slated to >> replace) right up to 10.10.5 with no zero to our Directory Utility setup. >> >> Hoping someone here has some contemporary experience with OSX and IPA and >> for whom this issue rings a bell? >> >> many thanks >> >> Cal Sawyer | Systems Engineer | BlueBolt Ltd >> 15-16 Margaret Street | London W1W 8RW >> +44 (0)20 7637 5575 <%2B44%20%280%2920%207637%205575> | www.blue-bolt.com >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project >> > > > > > -- > > Nicola Canepa > Tel: +39-0522-399-3474canepa.n at mmfg.it > --- > Il contenuto della presente comunicazione ? riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avr? valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, n? rinuncia o riconoscimento di diritti, debiti e/o crediti, n? sar? impegnativa, qualora non sia sottoscritto successivo accordo da chi pu? validamente obbligarci. Non deriver? alcuna responsabilit? precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti. > > The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties. > > > > -- > > Nicola Canepa > Tel: +39-0522-399-3474canepa.n at mmfg.it > --- > Il contenuto della presente comunicazione ? riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avr? valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, n? rinuncia o riconoscimento di diritti, debiti e/o crediti, n? sar? impegnativa, qualora non sia sottoscritto successivo accordo da chi pu? validamente obbligarci. Non deriver? alcuna responsabilit? precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti. > > The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Tue Dec 22 08:28:09 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 22 Dec 2015 09:28:09 +0100 Subject: [Freeipa-users] Issues with 'A replication agreement for the host already exists', when it very much doesn't In-Reply-To: <56782D91.1020605@brighter-technology.com> References: <56782D91.1020605@brighter-technology.com> Message-ID: <56790999.8020707@redhat.com> On 12/21/2015 05:49 PM, Alex Williams wrote: > I began installing a new ipa4 replica this morning and it all went > wrong. The ipa-replica-install script got all the way to restarting > ipa with systemctl at the very end, having set up replication and then > fell over, because systemctl couldn't find the ipa service. I removed > the replica from our master, I deleted the host from there too, I > un-installed ipa-server on the new replica machine, I even created a > new replica-prepare script on the master, but now the server just > errors immediately with: > > A replication agreement for this host already exists. It needs to > be removed. > > I've verified several times, that no replica, or host with the same > name exists in the master, there are no ldap entries under masters, > with that hostname, nothing. There is literally no trace of the new > host, on the old master. Running `ipa-replica-manage list` shows just > the 3 ipa servers we have already, no sign of this new host. Yet, if I > run `ipa-replica-manage del hostname --force` on the master, it will > in fact say that it's forcing removal, skipping checking if anything > will be orphaned and that no RUV records were found. > > I'm now lost, I really don't know where to start with fixing this. we should first try to get a clear picture of existing agreements and state of replication. Could you on all servers do the following searches (as directory manager) ldapsearch -LLL -o ldif-wrap=no ..... -b "cn=config" "objectclass=nsds5replicationagreement" nsDS5ReplicaRoot nsDS5ReplicaHost ldapsearch -LLL -o ldif-wrap=no ...... -b "cn=config" "objectclass=nsds5replica" nsDS5ReplicaRoot nsDS5ReplicaId nsds50ruv > > Not sure if this is relevant or not, but I'd rather bring it up and it > not be, than not mention it and it turn out to be the reason. Our yum > mirror is unfortunately now holding rhel7.2 packages, whilst our > servers, are still on rhel7.1, which means our existing IPA servers, > are ipa4.1 and the new one I tried to install, was ipa4.2, but on a > rhel7.1 box. I had previously attributed the failed systemctl command, > to the fact that I was trying to run ipa4.2 on a rhel7.1 box, as I'm > told there were a lot of modifications to systemctl in rhel7.2, but I > need to fix this replication agreement issue, before I can try again > with the box upgraded to rhel7.2. > > Any ideas? > > Cheers > > Alex > From tbordaz at redhat.com Tue Dec 22 09:24:20 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 22 Dec 2015 10:24:20 +0100 Subject: [Freeipa-users] Want faster user-add In-Reply-To: <56782EFA.1090300@umanitoba.ca> References: <56782EFA.1090300@umanitoba.ca> Message-ID: <567916C4.3020905@redhat.com> On 12/21/2015 05:55 PM, Daryl Fonseca-Holt wrote: > Hi all, > > Environment: RHEL6 with IPA 3.0 at current RedHat level. 64-core > 256-GB RAM Oracle x4470 M2. > > During our migration from NIS on Solaris 140,000+ accounts will be > added. After tuning per the guides dbmon.sh shows no roevicts and we > get high cache hit ratios. > > Per a previous discussion with the list the input is broken down into > batches of less than 1,000 users and the default IPA group is changed > before each batch. This helped greatly. > > Adding all the users takes many hours. Initially ipa user-add takes an > average 2.3 seconds per user but degrades by the time there are > 140,000 users to an average 6.7 seconds per user. > > In tracing it appears that a significant portion of the time ipa > user-add takes is not the add itself, it is the query at the end that > displays the resulting user account. Is there any legit way to prevent > this query? > > The length of time it takes to migrate is not a big concern. The > concern is the start of the fall school term when we typically add > approximately 1,300 accounts per hour during the registration period > with our current system. > > All suggestions will be appreciated. > > Regards, Daryl > Hi Daryl, I can reproduce similar trend of user-add becoming slower and slower. Now in my tests (etime=7s) the time was spent half by authentication and half by ADD and MOD (update of ipausers group). I agree there are many direct SRCH (~10) but they all seems to be rapid. I know that the vast majority of the time is spent in DS schema-compat plugin. Disabling it, during provisioning, reduce the duration by ~3. Now I do not know if it is a valid option to disable this plugin during provisioning. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.forner at gmail.com Tue Dec 22 09:06:55 2015 From: karl.forner at gmail.com (Karl Forner) Date: Tue, 22 Dec 2015 10:06:55 +0100 Subject: [Freeipa-users] ipa-replica-prepare error: Profile caIPAserviceCert Not Found In-Reply-To: <20151222014654.GU23644@dhcp-40-8.bne.redhat.com> References: <20151222014654.GU23644@dhcp-40-8.bne.redhat.com> Message-ID: Hi Fraser, The ipa-replica-prepare ran in a adelton/freeipa-server:lastest-systemd docker, which I think is based on fedora 23 and contains freeIPA v 4.2.3. I can try to patch it, but I'm really not used to fedora, and moreover there's a debian/docker bug that prevents me from building the docker image on my computers. Thanks, Karl On Tue, Dec 22, 2015 at 2:46 AM, Fraser Tweedale wrote: > On Mon, Dec 21, 2015 at 01:57:02PM +0100, Karl Forner wrote: > > Hello, > > > > Running: > > ipa-replica-prepare ipa-h3s1.example.com --ip-address xx.xx.xx.xx -d -v > > fails > > with > > ipa: DEBUG: Protocol: TLS1.2 > > ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_128_CBC_SHA > > ipa: DEBUG: request status 200 > > ipa: DEBUG: request reason_phrase u'OK' > > ipa: DEBUG: request headers {'date': 'Mon, 21 Dec 2015 12:50:59 GMT', > > 'content-length': '148', 'content-type': 'application/xml', 'server': > > 'Apache-Coyote/1.1'} > > ipa: DEBUG: request body ' > standalone="no"?>1Profile > > caIPAserviceCert Not Found' > > ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File > > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in > > execute > > > > The context is probably unusual: > > I run the command on a replica with CA from a server in freeipa v4.1.4 > (in > > a adelton/freeipa-server docker) > > which is a freeipa v4.2.3 running in > > adelton/freeipa-server:lastest-systemd docker > > > > I found this ticket which looks similar: > > https://fedorahosted.org/freeipa/ticket/5376 > > > > Is there something wrong with my replica knowing that it has been > > replicated from a 4.1.4 ? > > Is there a work-around ? > > > > Thanks > > Karl > > Hi Karl, > > I have a patch for Dogtag that I think will fix this issue. Would > you be willing to test it? If so, which version of Fedora/RHEL are > you using and I will prepare a build. > > Regards, > Fraser > > > -- > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.goudet at lyra-network.com Tue Dec 22 10:43:24 2015 From: david.goudet at lyra-network.com (David Goudet) Date: Tue, 22 Dec 2015 11:43:24 +0100 (CET) Subject: [Freeipa-users] Purge old entries in /var/lib/dirsrv/slapd-xxx/cldb/xxx.db4 file Message-ID: <951477293.2060162.1450781004914.JavaMail.zimbra@lyra-network.com> Hi, I have multimaster replication environment. On each replica, folder /var/lib/dirsrv/slapd-xxxx/cldb/ has big size (3~GB) and old entries in /var/lib/dirsrv/slapd-xxx/cldb/xxx.db4 have three month year old: sudo dbscan -f /var/lib/dirsrv/slapd-xxxx/cldb/ef155b03-dda611e2-a156db20-90xxx06_51c9aed900xxxxxx000.db4 | less dbid: 56239e5e000000040000 replgen: 1445174777 Sun Oct 18 15:26:17 2015 csn: 56239e5e000000040000 uniqueid: e55d5e01-26f211e4-9b60db20-90c3b706 dn: xxxx operation: modify krbLastSuccessfulAuth: 20151018132617Z modifiersname: cn=Directory Manager modifytimestamp: 20151018132617Z entryusn: 68030946 My questions are: a) How to purge old entries in file /var/lib/dirsrv/slapd-xxx/cldb/xxx.db4? (what is the procedure) b) What is the right configuration to limit increase of this file? This topic has been already talk on https://www.redhat.com/archives/freeipa-users/2013-February/msg00433.html or https://www.redhat.com/archives/freeipa-users/2015-April/msg00573.html but no response work for me. Response here seems to be not applicable https://bugzilla.redhat.com/show_bug.cgi?id=1181341 (Centos 7, Fixed In Version: 389-ds-base-1.3.4.0-1.el7) I used some attributes from the docuementation: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnchangelog5-nsslapd_changelogdir. Old entries are not purged and file increase even after restart service (service dirvsrv start and service dirvsrv stop). (This test environment values) dn: cn=changelog5,cn=config objectClass: top objectClass: extensibleobject cn: changelog5 ... nsslapd-changelogmaxentries: 100 nsslapd-changelogmaxage: 4m dn: cn=replica,cn=xxxxx,cn=mapping tree,cn=config cn: replica nsDS5Flags: 1 objectClass: top objectClass: nsds5replica objectClass: extensibleobject nsDS5ReplicaType: 3 nsDS5ReplicaRoot: dc=xxxxx nsds5ReplicaLegacyConsumer: off nsDS5ReplicaId: 6 nsDS5ReplicaBindDN: cn=replication manager,cn=config nsDS5ReplicaBindDN: krbprincipalname=ldap/xxxxxx .LYRA,cn=services,cn=accounts,dc=xxxxx nsState:: xxxxx nsDS5ReplicaName: d9663d08-a80f11e5-aa48d241-0b88f012 nsds5ReplicaTombstonePurgeInterval: 200 nsds5ReplicaPurgeDelay: 200 nsds5ReplicaChangeCount: 3091 nsds5replicareapactive: 0 Hereafter some informations about my environment: CentOS release 6.5 (Final) 389-ds-base-libs-1.2.11.15-65.el6_7.x86_64 389-ds-base-1.2.11.15-65.el6_7.x86_64 ipa-client-3.0.0-47.el6.centos.1.x86_64 ipa-server-3.0.0-47.el6.centos.1.x86_64 Thanks for your help! David From ftweedal at redhat.com Tue Dec 22 11:03:35 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 22 Dec 2015 21:03:35 +1000 Subject: [Freeipa-users] ipa-replica-prepare error: Profile caIPAserviceCert Not Found In-Reply-To: References: <20151222014654.GU23644@dhcp-40-8.bne.redhat.com> Message-ID: <20151222110335.GV23644@dhcp-40-8.bne.redhat.com> On Tue, Dec 22, 2015 at 10:06:55AM +0100, Karl Forner wrote: > Hi Fraser, > The ipa-replica-prepare ran in a adelton/freeipa-server:lastest-systemd > docker, which I think is based on fedora 23 and contains freeIPA v 4.2.3. > I can try to patch it, but I'm really not used to fedora, and moreover > there's a debian/docker bug that prevents me from building the docker image > on my computers. > > Thanks, > Karl > OK, fair enough. A couple of follow-up questions: - Is the issue always reproducible or only some of the time? - Are you running replica-prepare immediately after starting the container? Does the issue still occur after waiting a while? If you attach your /var/log/pki/pki-tomcat/ca/debug log it will help pinpoint the cause and confirm/deny whether the existing patch will fix it. Cheers, Fraser > On Tue, Dec 22, 2015 at 2:46 AM, Fraser Tweedale > wrote: > > > On Mon, Dec 21, 2015 at 01:57:02PM +0100, Karl Forner wrote: > > > Hello, > > > > > > Running: > > > ipa-replica-prepare ipa-h3s1.example.com --ip-address xx.xx.xx.xx -d -v > > > fails > > > with > > > ipa: DEBUG: Protocol: TLS1.2 > > > ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_128_CBC_SHA > > > ipa: DEBUG: request status 200 > > > ipa: DEBUG: request reason_phrase u'OK' > > > ipa: DEBUG: request headers {'date': 'Mon, 21 Dec 2015 12:50:59 GMT', > > > 'content-length': '148', 'content-type': 'application/xml', 'server': > > > 'Apache-Coyote/1.1'} > > > ipa: DEBUG: request body ' > > standalone="no"?>1Profile > > > caIPAserviceCert Not Found' > > > ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File > > > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in > > > execute > > > > > > The context is probably unusual: > > > I run the command on a replica with CA from a server in freeipa v4.1.4 > > (in > > > a adelton/freeipa-server docker) > > > which is a freeipa v4.2.3 running in > > > adelton/freeipa-server:lastest-systemd docker > > > > > > I found this ticket which looks similar: > > > https://fedorahosted.org/freeipa/ticket/5376 > > > > > > Is there something wrong with my replica knowing that it has been > > > replicated from a 4.1.4 ? > > > Is there a work-around ? > > > > > > Thanks > > > Karl > > > > Hi Karl, > > > > I have a patch for Dogtag that I think will fix this issue. Would > > you be willing to test it? If so, which version of Fedora/RHEL are > > you using and I will prepare a build. > > > > Regards, > > Fraser > > > > > -- > > > 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 > > > > From rmj at ast.cam.ac.uk Tue Dec 22 11:10:08 2015 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Tue, 22 Dec 2015 11:10:08 +0000 Subject: [Freeipa-users] Queries on migrating nis netgroups Message-ID: <56792F90.10506@ast.cam.ac.uk> Hi I'm migrating our nis environment to freeipa 4.2.0 on Redhat 7. I need to have the netgroups set up in freeipa before migrating systems to be freeipa clients. At this point I'm trying to understand the relationship between hostgroups and netgroups and whether I should just be using ipa netgroup-add and ipa netgroup-add-member commands or whether I should be using equivalent ipa hostgroup* commands. Section 14.5.1 of the Redhat 7 Domain Identity Authentication and Policy Guide is telling me that I get a shadow netgroup for every hostgroup I create and that I can manage these netgroups with the "ipa-host-net-manage" command. I don't see the ipa-host-net-manage command. There are ipa host* commands but these don't include ipa host-net* commands. What am I missing here? Also the ipa netgroup* commands don't seem to be able to manage the shadow netgroups so I'm currently unable to manipulate my shadow netgroups to eg change the nisdomain associated with them. How do I do that? Also it looks like I can't add non-ipa clients into hostgroups so presumable not into shadow netgroups either, so maybe this is a non-starter for me. Did I understand that correctly? Thanks Roderick Johnstone From lkrispen at redhat.com Tue Dec 22 12:55:06 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 22 Dec 2015 13:55:06 +0100 Subject: [Freeipa-users] Purge old entries in /var/lib/dirsrv/slapd-xxx/cldb/xxx.db4 file In-Reply-To: <951477293.2060162.1450781004914.JavaMail.zimbra@lyra-network.com> References: <951477293.2060162.1450781004914.JavaMail.zimbra@lyra-network.com> Message-ID: <5679482A.3060303@redhat.com> Hi, On 12/22/2015 11:43 AM, David Goudet wrote: > Hi, > > I have multimaster replication environment. On each replica, folder /var/lib/dirsrv/slapd-xxxx/cldb/ has big size (3~GB) and old entries in /var/lib/dirsrv/slapd-xxx/cldb/xxx.db4 have three month year old: > > sudo dbscan -f /var/lib/dirsrv/slapd-xxxx/cldb/ef155b03-dda611e2-a156db20-90xxx06_51c9aed900xxxxxx000.db4 | less > dbid: 56239e5e000000040000 > replgen: 1445174777 Sun Oct 18 15:26:17 2015 > csn: 56239e5e000000040000 > uniqueid: e55d5e01-26f211e4-9b60db20-90c3b706 > dn: xxxx > operation: modify > krbLastSuccessfulAuth: 20151018132617Z > modifiersname: cn=Directory Manager > modifytimestamp: 20151018132617Z > entryusn: 68030946 > > My questions are: > > a) How to purge old entries in file /var/lib/dirsrv/slapd-xxx/cldb/xxx.db4? (what is the procedure) > b) What is the right configuration to limit increase of this file? setting changelog maxage should be sufficient to trim changes, but the age is not the only condition deciding if a recored in the changelog can be deleted. - for each replicaID the last record will never be deleted, independent of its age, so if you have replicas in your topology which are not (or not frequently) updated directly there will be old changes in the changelog - if the replica where the trimming is run and if it has replication agreements to other replicas, changes which were not yet replicated to the other replica will not be purged. So, if you have some stale agreements to other replicas this could prevent trimming as well. Also trimming removes changelog records and frees space internally ro th edb4 file to be reused, but it will not shrink the file size > > > > This topic has been already talk on https://www.redhat.com/archives/freeipa-users/2013-February/msg00433.html or https://www.redhat.com/archives/freeipa-users/2015-April/msg00573.html but no response work for me. > Response here seems to be not applicable https://bugzilla.redhat.com/show_bug.cgi?id=1181341 (Centos 7, Fixed In Version: 389-ds-base-1.3.4.0-1.el7) > > I used some attributes from the docuementation: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnchangelog5-nsslapd_changelogdir. Old entries are not purged and file increase even after restart service (service dirvsrv start and service dirvsrv stop). > > (This test environment values) > dn: cn=changelog5,cn=config > objectClass: top > objectClass: extensibleobject > cn: changelog5 > ... > nsslapd-changelogmaxentries: 100 > nsslapd-changelogmaxage: 4m > > dn: cn=replica,cn=xxxxx,cn=mapping tree,cn=config > cn: replica > nsDS5Flags: 1 > objectClass: top > objectClass: nsds5replica > objectClass: extensibleobject > nsDS5ReplicaType: 3 > nsDS5ReplicaRoot: dc=xxxxx > nsds5ReplicaLegacyConsumer: off > nsDS5ReplicaId: 6 > nsDS5ReplicaBindDN: cn=replication manager,cn=config > nsDS5ReplicaBindDN: krbprincipalname=ldap/xxxxxx > .LYRA,cn=services,cn=accounts,dc=xxxxx > nsState:: xxxxx > nsDS5ReplicaName: d9663d08-a80f11e5-aa48d241-0b88f012 > nsds5ReplicaTombstonePurgeInterval: 200 > nsds5ReplicaPurgeDelay: 200 > nsds5ReplicaChangeCount: 3091 > nsds5replicareapactive: 0 > > Hereafter some informations about my environment: > CentOS release 6.5 (Final) > 389-ds-base-libs-1.2.11.15-65.el6_7.x86_64 > 389-ds-base-1.2.11.15-65.el6_7.x86_64 > ipa-client-3.0.0-47.el6.centos.1.x86_64 > ipa-server-3.0.0-47.el6.centos.1.x86_64 > > Thanks for your help! > > David > From Daryl.Fonseca-Holt at umanitoba.ca Tue Dec 22 14:08:39 2015 From: Daryl.Fonseca-Holt at umanitoba.ca (Daryl Fonseca-Holt) Date: Tue, 22 Dec 2015 08:08:39 -0600 Subject: [Freeipa-users] Want faster user-add In-Reply-To: <567916C4.3020905@redhat.com> References: <56782EFA.1090300@umanitoba.ca> <567916C4.3020905@redhat.com> Message-ID: <56795967.8030303@umanitoba.ca> On 12/22/15 03:24, thierry bordaz wrote: > On 12/21/2015 05:55 PM, Daryl Fonseca-Holt wrote: >> Hi all, >> >> Environment: RHEL6 with IPA 3.0 at current RedHat level. 64-core >> 256-GB RAM Oracle x4470 M2. >> >> During our migration from NIS on Solaris 140,000+ accounts will be >> added. After tuning per the guides dbmon.sh shows no roevicts and we >> get high cache hit ratios. >> >> Per a previous discussion with the list the input is broken down into >> batches of less than 1,000 users and the default IPA group is changed >> before each batch. This helped greatly. >> >> Adding all the users takes many hours. Initially ipa user-add takes >> an average 2.3 seconds per user but degrades by the time there are >> 140,000 users to an average 6.7 seconds per user. >> >> In tracing it appears that a significant portion of the time ipa >> user-add takes is not the add itself, it is the query at the end that >> displays the resulting user account. Is there any legit way to >> prevent this query? >> >> The length of time it takes to migrate is not a big concern. The >> concern is the start of the fall school term when we typically add >> approximately 1,300 accounts per hour during the registration period >> with our current system. >> >> All suggestions will be appreciated. >> >> Regards, Daryl >> > Hi Daryl, > > I can reproduce similar trend of user-add becoming slower and slower. > > Now in my tests (etime=7s) the time was spent half by authentication > and half by ADD and MOD (update of ipausers group). I agree there are > many direct SRCH (~10) but they all seems to be rapid. > > I know that the vast majority of the time is spent in DS schema-compat > plugin. Disabling it, during provisioning, reduce the duration by ~3. > Now I do not know if it is a valid option to disable this plugin > during provisioning. > > thanks > thierry Thanks for validating my timings, it's good to know I'm not off track somewhere. Not being sure what I will end up with if the DS schema-compat plugin is disabled I'm not sure I'll end up with what we need. We need NIS in the future and further out we will convert the clients to LDAP and possible SSSD in the case of Linux clients. Thanks, Daryl -- -- Daryl Fonseca-Holt IST/CNS/Unix Server Team University of Manitoba 204.480.1079 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Tue Dec 22 14:09:59 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 22 Dec 2015 15:09:59 +0100 Subject: [Freeipa-users] Want faster user-add In-Reply-To: <567916C4.3020905@redhat.com> References: <56782EFA.1090300@umanitoba.ca> <567916C4.3020905@redhat.com> Message-ID: <567959B7.4020805@redhat.com> On 12/22/2015 10:24 AM, thierry bordaz wrote: > On 12/21/2015 05:55 PM, Daryl Fonseca-Holt wrote: >> Hi all, >> >> Environment: RHEL6 with IPA 3.0 at current RedHat level. 64-core >> 256-GB RAM Oracle x4470 M2. >> >> During our migration from NIS on Solaris 140,000+ accounts will be >> added. After tuning per the guides dbmon.sh shows no roevicts and we >> get high cache hit ratios. >> >> Per a previous discussion with the list the input is broken down into >> batches of less than 1,000 users and the default IPA group is changed >> before each batch. This helped greatly. >> >> Adding all the users takes many hours. Initially ipa user-add takes an >> average 2.3 seconds per user but degrades by the time there are >> 140,000 users to an average 6.7 seconds per user. >> >> In tracing it appears that a significant portion of the time ipa >> user-add takes is not the add itself, it is the query at the end that >> displays the resulting user account. Is there any legit way to prevent >> this query? >> >> The length of time it takes to migrate is not a big concern. The >> concern is the start of the fall school term when we typically add >> approximately 1,300 accounts per hour during the registration period >> with our current system. >> >> All suggestions will be appreciated. >> >> Regards, Daryl >> > Hi Daryl, > > I can reproduce similar trend of user-add becoming slower and slower. > > Now in my tests (etime=7s) the time was spent half by authentication and > half by ADD and MOD (update of ipausers group). I agree there are many > direct SRCH (~10) but they all seems to be rapid. > > I know that the vast majority of the time is spent in DS schema-compat > plugin. Disabling it, during provisioning, reduce the duration by ~3. > Now I do not know if it is a valid option to disable this plugin during > provisioning. > > thanks > thierry We must also distinguish performance on IPA 3.x (RHEL 6.x) and FreeIPA 4.2/4.3 FreeIPA 4.2 got some performance improvements mostly related to group membership handling. Improving user-add is one of primary goals for 4.4 release: * https://fedorahosted.org/freeipa/ticket/5448 There are couple issues tracked about plugins output (also planned to be fixed in 4.4): * https://fedorahosted.org/freeipa/ticket/5281 * https://fedorahosted.org/freeipa/ticket/5282 * https://fedorahosted.org/freeipa/ticket/4995 You can try to call user-add with --raw options but it won't help much because some parts ignore it. Other than that, there is not clean workaround. When user is added, the user_add typically: * adds the user to ipadefaultprimarygroup * converts manger dn to human friedly value (should not cause perf. issues) * set description to magic value to cause generation of user private group (calls user-mod) * fetches password attributes and resolves ssh pub keys (does couple of searches) An unsupported possibility - do on your own risk - is to remove these operations from user_add post_callback in ipalib/plugins/user.py (around line 535 on 6.7). Other thing which might help is to remove 'memberof' and 'memberofindirect' values from default_attributes in user.py (~line 216). Note that it also affects other user-* commands. All should be tried in testing environment. Another performance improvement is to call IPA API directly and use batch command - with that it is possible to add e.g. 100 users with one call and save some network calls. Example could be seen in this ugly script: https://pvoborni.fedorapeople.org/scripts/ipa-generate-users.sh -- Petr Vobornik From Daryl.Fonseca-Holt at umanitoba.ca Tue Dec 22 14:25:15 2015 From: Daryl.Fonseca-Holt at umanitoba.ca (Daryl Fonseca-Holt) Date: Tue, 22 Dec 2015 08:25:15 -0600 Subject: [Freeipa-users] Want faster user-add In-Reply-To: <567959B7.4020805@redhat.com> References: <56782EFA.1090300@umanitoba.ca> <567916C4.3020905@redhat.com> <567959B7.4020805@redhat.com> Message-ID: <56795D4B.4060206@umanitoba.ca> On 12/22/15 08:09, Petr Vobornik wrote: > On 12/22/2015 10:24 AM, thierry bordaz wrote: >> On 12/21/2015 05:55 PM, Daryl Fonseca-Holt wrote: >>> Hi all, >>> >>> Environment: RHEL6 with IPA 3.0 at current RedHat level. 64-core >>> 256-GB RAM Oracle x4470 M2. >>> >>> During our migration from NIS on Solaris 140,000+ accounts will be >>> added. After tuning per the guides dbmon.sh shows no roevicts and we >>> get high cache hit ratios. >>> >>> Per a previous discussion with the list the input is broken down into >>> batches of less than 1,000 users and the default IPA group is changed >>> before each batch. This helped greatly. >>> >>> Adding all the users takes many hours. Initially ipa user-add takes an >>> average 2.3 seconds per user but degrades by the time there are >>> 140,000 users to an average 6.7 seconds per user. >>> >>> In tracing it appears that a significant portion of the time ipa >>> user-add takes is not the add itself, it is the query at the end that >>> displays the resulting user account. Is there any legit way to prevent >>> this query? >>> >>> The length of time it takes to migrate is not a big concern. The >>> concern is the start of the fall school term when we typically add >>> approximately 1,300 accounts per hour during the registration period >>> with our current system. >>> >>> All suggestions will be appreciated. >>> >>> Regards, Daryl >>> >> Hi Daryl, >> >> I can reproduce similar trend of user-add becoming slower and slower. >> >> Now in my tests (etime=7s) the time was spent half by authentication and >> half by ADD and MOD (update of ipausers group). I agree there are many >> direct SRCH (~10) but they all seems to be rapid. >> >> I know that the vast majority of the time is spent in DS schema-compat >> plugin. Disabling it, during provisioning, reduce the duration by ~3. >> Now I do not know if it is a valid option to disable this plugin during >> provisioning. >> >> thanks >> thierry > > We must also distinguish performance on IPA 3.x (RHEL 6.x) and FreeIPA > 4.2/4.3 > > FreeIPA 4.2 got some performance improvements mostly related to group > membership handling. > > Improving user-add is one of primary goals for 4.4 release: > * https://fedorahosted.org/freeipa/ticket/5448 > > There are couple issues tracked about plugins output (also planned to > be fixed in 4.4): > * https://fedorahosted.org/freeipa/ticket/5281 > * https://fedorahosted.org/freeipa/ticket/5282 > * https://fedorahosted.org/freeipa/ticket/4995 > > You can try to call user-add with --raw options but it won't help much > because some parts ignore it. Other than that, there is not clean > workaround. > > When user is added, the user_add typically: > * adds the user to ipadefaultprimarygroup > * converts manger dn to human friedly value (should not cause perf. > issues) > * set description to magic value to cause generation of user private > group (calls user-mod) > * fetches password attributes and resolves ssh pub keys (does couple > of searches) > > An unsupported possibility - do on your own risk - is to remove these > operations from user_add post_callback in ipalib/plugins/user.py > (around line 535 on 6.7). > > Other thing which might help is to remove 'memberof' and > 'memberofindirect' values from default_attributes in user.py (~line > 216). Note that it also affects other user-* commands. > > All should be tried in testing environment. > > Another performance improvement is to call IPA API directly and use > batch command - with that it is possible to add e.g. 100 users with > one call and save some network calls. > > Example could be seen in this ugly script: > https://pvoborni.fedorapeople.org/scripts/ipa-generate-users.sh I did test with RHEL7 and IPA 4.2 and the performance was much better. We don't have RHEL7 deployed yet so there are some issues with change management but we may have to revisit that. I looked at changing the code but we can't end up with an unsupported product. We depend on our Red Hat support heavily for production. So I could speed up the migration from the NIS server but I won't be able to keep the optimization during day-to-day operation. Thanks for the script. Ugly scripts are good learning examples because it's easy to see the real purpose without the distraction of frills. Regards, Daryl -- -- Daryl Fonseca-Holt IST/CNS/Unix Server Team University of Manitoba 204.480.1079 From yks0000 at gmail.com Tue Dec 22 13:21:25 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Tue, 22 Dec 2015 18:51:25 +0530 Subject: [Freeipa-users] Two Factor = SSHKeys + OTP or Password Message-ID: Hi List, Did not see any options for SSH Keys + OTP or Password, However would like to know if it is possible with FreeIPA user. With Generic SSH , We can use use AuthenticationMethods, but not sure where to check in FreeIPA. *Best Regards,* *__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Tue Dec 22 15:16:51 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 22 Dec 2015 10:16:51 -0500 Subject: [Freeipa-users] Want faster user-add In-Reply-To: <567916C4.3020905@redhat.com> References: <56782EFA.1090300@umanitoba.ca> <567916C4.3020905@redhat.com> Message-ID: <1450797411.7465.3.camel@redhat.com> On Tue, 2015-12-22 at 10:24 +0100, thierry bordaz wrote: > On 12/21/2015 05:55 PM, Daryl Fonseca-Holt wrote: > > Hi all, > > > > Environment: RHEL6 with IPA 3.0 at current RedHat level. 64-core > > 256-GB RAM Oracle x4470 M2. > > > > During our migration from NIS on Solaris 140,000+ accounts will be > > added. After tuning per the guides dbmon.sh shows no roevicts and we > > get high cache hit ratios. > > > > Per a previous discussion with the list the input is broken down into > > batches of less than 1,000 users and the default IPA group is changed > > before each batch. This helped greatly. > > > > Adding all the users takes many hours. Initially ipa user-add takes an > > average 2.3 seconds per user but degrades by the time there are > > 140,000 users to an average 6.7 seconds per user. > > > > In tracing it appears that a significant portion of the time ipa > > user-add takes is not the add itself, it is the query at the end that > > displays the resulting user account. Is there any legit way to prevent > > this query? > > > > The length of time it takes to migrate is not a big concern. The > > concern is the start of the fall school term when we typically add > > approximately 1,300 accounts per hour during the registration period > > with our current system. > > > > All suggestions will be appreciated. > > > > Regards, Daryl > > > Hi Daryl, > > I can reproduce similar trend of user-add becoming slower and slower. > > Now in my tests (etime=7s) the time was spent half by authentication and > half by ADD and MOD (update of ipausers group). I agree there are many > direct SRCH (~10) but they all seems to be rapid. > > I know that the vast majority of the time is spent in DS schema-compat > plugin. Disabling it, during provisioning, reduce the duration by ~3. > Now I do not know if it is a valid option to disable this plugin during > provisioning. As long as the schema compat is not needed by users during the provisioning, turning it off is fine. All the contents are regenerated at startup anyway. So it can be re-enabled and the server restarted after the bulk provisioning is done. Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Tue Dec 22 15:21:47 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 22 Dec 2015 16:21:47 +0100 Subject: [Freeipa-users] Two Factor = SSHKeys + OTP or Password In-Reply-To: References: Message-ID: <20151222152147.GA3392@p.redhat.com> On Tue, Dec 22, 2015 at 06:51:25PM +0530, Yogesh Sharma wrote: > Hi List, > > Did not see any options for SSH Keys + OTP or Password, However would like > to know if it is possible with FreeIPA user. > > With Generic SSH , We can use use AuthenticationMethods, but not sure where > to check in FreeIPA. I think there is nothing specific about FreeIPA here. If you set on a IPA client 'AuthenticationMethods = publickey,password' in sshd_config, sshd will check the ssh key first and then ask the user for a password. If the user is configured to use OTP on the IPA server then you have to enter not only the password but the OTP token as well. HTH bye, Sumit > > > > > *Best Regards,* > > *__________________________________________* > > *Yogesh Sharma* > *Email: yks0000 at gmail.com | Web: www.initd.in > * > > *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* > > > > > -- > 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 From ftweedal at redhat.com Wed Dec 23 04:11:24 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 23 Dec 2015 14:11:24 +1000 Subject: [Freeipa-users] NetworkError : invalid continuation byte with utf8 codec In-Reply-To: References: <20151222013001.GT23644@dhcp-40-8.bne.redhat.com> Message-ID: <20151223041124.GA16124@dhcp-40-8.bne.redhat.com> On Tue, Dec 22, 2015 at 08:39:09AM +0100, Gmail wrote: > Here are the files you ask for: > Thank you. I see Tomcat is running in an fr_FR locale. Could you also provide contents of `/etc/locale.conf'? Cheers, Fraser > > > Le 22 d?cembre 2015 ? 02:30:06, Fraser Tweedale (ftweedal at redhat.com) a ?crit: > > On Mon, Dec 21, 2015 at 05:29:01PM +0100, Gmail wrote: > > Hi all, > > > > When trying to install on a fresh new Centos 7 I?ve got this error : > > > > 2015-12-21T16:04:44Z DEBUG The ipa-server-install command failed, exception: NetworkError: cannot connect to 'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't decode byte 0xea in position 13: invalid continuation byte > > 2015-12-21T16:04:44Z ERROR cannot connect to 'https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't decode byte 0xea in position 13: invalid continuation byte > > > > My freeipa-server version is : ?4.2.0 > > I?m running a Centos 3.10.0-327.3.1.el7.x86_64 > > > > Any idea of what goes wrong? > > > Thanks for reporting. I have not seen this error before. Could you > please include the following log files and I will take a closer > look: > > /var/log/ipaserver-install.log > /var/log/pki/pki-tomcat/ca/debug > > Cheers, > Fraser From dmwither at us.ibm.com Wed Dec 23 19:08:20 2015 From: dmwither at us.ibm.com (Danielle M Witherspoon) Date: Wed, 23 Dec 2015 14:08:20 -0500 Subject: [Freeipa-users] (no subject) In-Reply-To: <815317789.35144681.1450195017114.JavaMail.zimbra@redhat.com> References: <668710913.35135431.1450194847009.JavaMail.zimbra@redhat.com> <815317789.35144681.1450195017114.JavaMail.zimbra@redhat.com> Message-ID: <201512231908.tBNJ8SoN008261@d01av04.pok.ibm.com> Hello everyone, We've run into an issue with our instance of IPA. Our LDAP certificate was deleted with the command "ldapdelete -Y GSSAPI "cn=CAcert,cn=ipa,cn=etc,dc=example,dc=test"". When we now attempt to enroll servers as IPA clients, we get the following (sanitized for this email) output: [root at server1 ~]# ipa-client-install ?enable-dns-updates Discovery was successful! Hostname: server1.SERVER.local Realm: SERVER.LOCAL DNS Domain: SERVER.local IPA Server: ipaserver1.SERVER.local BaseDN: dc=server dc=local Continue to configure the system with these values? [no]: yes User authorized to enroll computers: bob Synchronizing time with KDC... Password for bob at SERVER.LOCAL: Cannot obtain CA certificate 'ldap://ipaserver1.SERVER.local' doesn't have a certificate. Installation failed. Rolling back changes. IPA client is not configured on this system. Advice on how to remediate this issue would be welcomed with open arms. Thank you for your time, Danielle Witherspoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From yks0000 at gmail.com Wed Dec 23 22:01:46 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Thu, 24 Dec 2015 03:31:46 +0530 Subject: [Freeipa-users] Two Factor = SSHKeys + OTP or Password In-Reply-To: <20151222152147.GA3392@p.redhat.com> References: <20151222152147.GA3392@p.redhat.com> Message-ID: Thanks. After upgrading the openssh to 6.1 and using AuthenticationMethod, it works. -Yogesh Sharma (Sent from my HTC) On 22-Dec-2015 8:51 pm, "Sumit Bose" wrote: > On Tue, Dec 22, 2015 at 06:51:25PM +0530, Yogesh Sharma wrote: > > Hi List, > > > > Did not see any options for SSH Keys + OTP or Password, However would > like > > to know if it is possible with FreeIPA user. > > > > With Generic SSH , We can use use AuthenticationMethods, but not sure > where > > to check in FreeIPA. > > I think there is nothing specific about FreeIPA here. If you set on a > IPA client 'AuthenticationMethods = publickey,password' in sshd_config, > sshd will check the ssh key first and then ask the user for a password. > > If the user is configured to use OTP on the IPA server then you have to > enter not only the password but the OTP token as well. > > HTH > > bye, > Sumit > > > > > > > > > > > *Best Regards,* > > > > *__________________________________________* > > > > *Yogesh Sharma* > > *Email: yks0000 at gmail.com | Web: www.initd.in > > * > > > > *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* > > > > > > > > > > > -- > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald.dunkel at aixigo.de Mon Dec 28 12:10:07 2015 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Mon, 28 Dec 2015 13:10:07 +0100 Subject: [Freeipa-users] ipa-replica-install --setup-ca: do or don't? Message-ID: <5681269F.70004@aixigo.de> Hi folks, how comes that '--setup-ca' is not the default for ipa-replica-install? What is best practice wrt creating a local ca on the replicas? Every insightful comment is highly appreciated. Best seasons greetings Harri From yamakasi.014 at gmail.com Mon Dec 28 13:01:51 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Mon, 28 Dec 2015 14:01:51 +0100 Subject: [Freeipa-users] Samba Authentication progres Message-ID: Hi guys, How is the progres on the Samba (Share) Authentication for FreeIpa ? I hope we already have some work around to use the FreeIPA credentials for authing network shares. Matt From simo at redhat.com Mon Dec 28 18:11:18 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 28 Dec 2015 13:11:18 -0500 Subject: [Freeipa-users] ipa-replica-install --setup-ca: do or don't? In-Reply-To: <5681269F.70004@aixigo.de> References: <5681269F.70004@aixigo.de> Message-ID: <1451326278.3830.4.camel@redhat.com> On Mon, 2015-12-28 at 13:10 +0100, Harald Dunkel wrote: > Hi folks, > > how comes that '--setup-ca' is not the default for > ipa-replica-install? What is best practice wrt creating > a local ca on the replicas? > > Every insightful comment is highly appreciated. There is no need to have a CA on every ipa server, so a CA is not installed by default. You can pass --setup-ca at install time or you can use ipa-ca-install later on. Simo. -- Simo Sorce * Red Hat, Inc * New York From karl.forner at gmail.com Mon Dec 28 18:18:46 2015 From: karl.forner at gmail.com (Karl Forner) Date: Mon, 28 Dec 2015 19:18:46 +0100 Subject: [Freeipa-users] ipa-replica-install --setup-ca: do or don't? In-Reply-To: <1451326278.3830.4.camel@redhat.com> References: <5681269F.70004@aixigo.de> <1451326278.3830.4.camel@redhat.com> Message-ID: > There is no need to have a CA on every ipa server, so a CA is not > installed by default. What is the downside of having every replica as a CA ? Because in case of big trouble with your master, if your replica is not a CA you can not replace your master from this replica right ? In particular you can not make another replica from your existing replica. On Mon, Dec 28, 2015 at 7:11 PM, Simo Sorce wrote: > On Mon, 2015-12-28 at 13:10 +0100, Harald Dunkel wrote: > > Hi folks, > > > > how comes that '--setup-ca' is not the default for > > ipa-replica-install? What is best practice wrt creating > > a local ca on the replicas? > > > > Every insightful comment is highly appreciated. > > There is no need to have a CA on every ipa server, so a CA is not > installed by default. > > You can pass --setup-ca at install time or you can use ipa-ca-install > later on. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kurt.Bendl at nrel.gov Mon Dec 28 19:43:52 2015 From: Kurt.Bendl at nrel.gov (Bendl, Kurt) Date: Mon, 28 Dec 2015 19:43:52 +0000 Subject: [Freeipa-users] missing attribute "ipaNTSecurityIdentifier" Message-ID: Hi folks, I'm testing getting a samba server working against IPA. Now, when adding a user via the interface, I get ============================================================ IPA Error 4205: ObjectclassViolation missing attribute "ipaNTSecurityIdentifier" required by object class "ipaNTUserAttrs" ### To get here, I did the following on the IPA server:: ipa service-add cifs/obscon4.hpctest.nrel.gov ipa privilege-add 'CIFS server privilege' ipa privilege-add-permission 'CIFS server privilege' --permission='CIFS server can read user passwords' ipa permission-add "CIFS server can read user passwords" --attrs={ipaNTHash,ipaNTSecurityIdentifier} --type=user --right={read,search,compare} --bindtype=permission ipa role-add 'CIFS server' ipa role-add-privilege 'CIFS server' --privilege='CIFS server privilege' ipa role-add-member 'CIFS server' --services=cifs/obscon4.hpctest.nrel.gov Then, I ran `ipa-adtrust-install`, and realized later that I need to append the `--add-sids` mojo. So, I re-ran that wiht the switch. I then added the 'ipantuserattrs' objectClass. I'm messing around with this in a test environment, so I can blow the IPA server away if I really have to. So, if there are tips on what you might see that I missed in the set up, or how I I might get IPA set up correctly, I'd appreciate it. Versions: RHEL: 7.2 IPA: VERSION: 4.2.0, API_VERSION: 2.156 Thanks, Kurt From simo at redhat.com Mon Dec 28 20:12:39 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 28 Dec 2015 15:12:39 -0500 Subject: [Freeipa-users] ipa-replica-install --setup-ca: do or don't? In-Reply-To: References: <5681269F.70004@aixigo.de> <1451326278.3830.4.camel@redhat.com> Message-ID: <1451333559.3830.11.camel@redhat.com> On Mon, 2015-12-28 at 19:18 +0100, Karl Forner wrote: > > There is no need to have a CA on every ipa server, so a CA is not > > installed by default. > > What is the downside of having every replica as a CA ? A CA is relatively heavyweight as the dogtag code brings up a whole java VM, also it means duplicating the CA private key on more servers. Plus there is additional DS replication (for the CA database). This is why the compromise was to not install the CA by default. We have since been thinking that maybe the first replica should have the CA by default but this hasn't been done (and I can't find a ticket for it). > Because in case of big trouble with your master, if your replica is not a > CA you can not replace your master from this replica right ? > In particular you can not make another replica from your existing replica. Now that we have changed the way replicas are created, at domain level 1, it may be a good RFE to ask to make it possible to install w/o CA by generating a self signed cert for HTTP only. Simo. > On Mon, Dec 28, 2015 at 7:11 PM, Simo Sorce wrote: > > > On Mon, 2015-12-28 at 13:10 +0100, Harald Dunkel wrote: > > > Hi folks, > > > > > > how comes that '--setup-ca' is not the default for > > > ipa-replica-install? What is best practice wrt creating > > > a local ca on the replicas? > > > > > > Every insightful comment is highly appreciated. > > > > There is no need to have a CA on every ipa server, so a CA is not > > installed by default. > > > > You can pass --setup-ca at install time or you can use ipa-ca-install > > later on. > > > > Simo. > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > -- Simo Sorce * Red Hat, Inc * New York From gjn at gjn.priv.at Tue Dec 29 13:30:24 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Tue, 29 Dec 2015 14:30:24 +0100 Subject: [Freeipa-users] DNSSEC Question (KSK ZSK) Message-ID: <3743165.C1AC4MrIvI@techz> Hello, Is it possible to install a DSNSEC Master with my before created KSK ZSK? Background: I have installed a IPA Master on my System now I have change the Hardware and make a new installation with new Hardware? I have only a backup from the Files in /var/named/dyndb-ldap/ipa/master/example.com/keys/ When I now enable a new DNSSEC Master create freeIPA new KSK ZSK for the Domain ? Then I have to wait after the holidays to UPDATE the DS Record on my ISP :-(. Thanks for a answer, -- mit freundlichen Gr??en / best regards, G?nther J. Niederwimmer From gparente at redhat.com Tue Dec 29 13:49:11 2015 From: gparente at redhat.com (German Parente) Date: Tue, 29 Dec 2015 08:49:11 -0500 (EST) Subject: [Freeipa-users] (no subject) In-Reply-To: <201512231908.tBNJ8SoN008261@d01av04.pok.ibm.com> References: <668710913.35135431.1450194847009.JavaMail.zimbra@redhat.com> <815317789.35144681.1450195017114.JavaMail.zimbra@redhat.com> <201512231908.tBNJ8SoN008261@d01av04.pok.ibm.com> Message-ID: <1283684025.2697187.1451396951670.JavaMail.zimbra@redhat.com> Hi Danielle, I think you could recreate the entry. The information can be found in "o=ipaca" database. ldapsearch -D "cn=directory manager" -W -b "ou=certificateRepository,ou=ca,o=ipaca" "(subjectname=CN=Certificate Authority,o=example.test)" usercertificate (remember that in RHEL6 you will need to query instance in 7389 port, that is to say, add "-p 7389 -h localhost" to the ldapsearch command). And recreate your entry with this information: ======================================================== dn: cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com objectClass: nsContainer objectClass: pkiCA objectClass: top cn: CAcert cACertificate;binary: ======================================================== Another possibility. If this deleted entry has not been purged, you could find still the information as a tomsbtone. And then, re-create the entry with the information in the tombstone: ldapsearch -D "cn=directory manager" -W -b "dc=example,dc=test" "(&(objectclass=nstombstone)(cn=CAcert))" you will see an entry with a dn of this sort: dn: nsuniqueid=f3b4a182-ae3111e5-a3a1dc9f-3b3599c3,cn=CAcert,cn=ipa,cn=etc,dc=example,dc=test And you could add a new entry (shown before) with the exact information found in the tombstone, changing the dn by the right one, of course. Regards, German. ----- Original Message ----- > From: "Danielle M Witherspoon" > To: freeipa-users at redhat.com > Sent: Wednesday, December 23, 2015 8:08:20 PM > Subject: [Freeipa-users] (no subject) > > > > Hello everyone, > > We've run into an issue with our instance of IPA. Our LDAP certificate was > deleted with the command "ldapdelete -Y GSSAPI > "cn=CAcert,cn=ipa,cn=etc,dc=example,dc=test"". When we now attempt to enroll > servers as IPA clients, we get the following (sanitized for this email) > output: > > > [root at server1 ~]# ipa-client-install ?enable-dns-updates > Discovery was successful! > Hostname: server1.SERVER.local > Realm: SERVER.LOCAL > DNS Domain: SERVER.local > IPA Server: ipaserver1.SERVER.local > BaseDN: dc=server dc=local > > Continue to configure the system with these values? [no]: yes > User authorized to enroll computers: bob > Synchronizing time with KDC... > Password for bob at SERVER.LOCAL: > Cannot obtain CA certificate > 'ldap://ipaserver1.SERVER.local' doesn't have a certificate. > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > Advice on how to remediate this issue would be welcomed with open arms. > > Thank you for your time, > Danielle Witherspoon > > -- > 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 From simo at redhat.com Tue Dec 29 16:36:32 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 29 Dec 2015 11:36:32 -0500 Subject: [Freeipa-users] DNSSEC Question (KSK ZSK) In-Reply-To: <3743165.C1AC4MrIvI@techz> References: <3743165.C1AC4MrIvI@techz> Message-ID: <1451406992.3830.20.camel@redhat.com> On Tue, 2015-12-29 at 14:30 +0100, G?nther J. Niederwimmer wrote: > Hello, > > Is it possible to install a DSNSEC Master with my before created KSK ZSK? > > Background: > > I have installed a IPA Master on my System now I have change the Hardware and > make a new installation with new Hardware? Unless you want to trash your current install for some reason, it would be easier to simply create an ipa replica on the new hardware so that all keys get transferred too. When you retire your old master you will have to reconfigure the remaining replica to become the server that rotate the DNS keys. > I have only a backup from the Files in > /var/named/dyndb-ldap/ipa/master/example.com/keys/ > > When I now enable a new DNSSEC Master create freeIPA new KSK ZSK for the > Domain ? If you have already destroyed your original master it is probably easier to just regenerate all keys and upload the new public keys on the glue record of the delegating provider. Simo. > Then I have to wait after the holidays to UPDATE the DS Record on my ISP :-(. > > Thanks for a answer, > > -- > mit freundlichen Gr??en / best regards, > > G?nther J. Niederwimmer > -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Tue Dec 29 16:39:01 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 29 Dec 2015 17:39:01 +0100 Subject: [Freeipa-users] DNSSEC Question (KSK ZSK) In-Reply-To: <3743165.C1AC4MrIvI@techz> References: <3743165.C1AC4MrIvI@techz> Message-ID: <5682B725.6070202@redhat.com> On 29.12.2015 14:30, G?nther J. Niederwimmer wrote: > Hello, > > Is it possible to install a DSNSEC Master with my before created KSK ZSK? > > Background: > > I have installed a IPA Master on my System now I have change the Hardware and > make a new installation with new Hardware? > > I have only a backup from the Files in > /var/named/dyndb-ldap/ipa/master/example.com/keys/ > > When I now enable a new DNSSEC Master create freeIPA new KSK ZSK for the > Domain ? > > Then I have to wait after the holidays to UPDATE the DS Record on my ISP :-(. > > Thanks for a answer, > I'm not sure if this is possible, IPA uses openDNSSEC, and it needs softhsm database and database of keys metadata, which are not located in /var/named/... New installation of DNSSEC master will create new keys. My colleague is more familiar with bind-dyndb-ldap, but he will be available after holidays too. From mbasti at redhat.com Tue Dec 29 16:42:52 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 29 Dec 2015 17:42:52 +0100 Subject: [Freeipa-users] DNSSEC Question (KSK ZSK) In-Reply-To: <1451406992.3830.20.camel@redhat.com> References: <3743165.C1AC4MrIvI@techz> <1451406992.3830.20.camel@redhat.com> Message-ID: <5682B80C.50906@redhat.com> On 29.12.2015 17:36, Simo Sorce wrote: > On Tue, 2015-12-29 at 14:30 +0100, G?nther J. Niederwimmer wrote: >> Hello, >> >> Is it possible to install a DSNSEC Master with my before created KSK ZSK? >> >> Background: >> >> I have installed a IPA Master on my System now I have change the Hardware and >> make a new installation with new Hardware? > Unless you want to trash your current install for some reason, it would > be easier to simply create an ipa replica on the new hardware so that > all keys get transferred too. > > When you retire your old master you will have to reconfigure the > remaining replica to become the server that rotate the DNS keys. If you still have accessible master, create new replica with DNS, CA(if master has CA too). Please follow following guide to migrate DNSSEC master http://www.freeipa.org/page/Howto/DNSSEC#Migrate_DNSSEC_master_to_another_IPA_server Martin > >> I have only a backup from the Files in >> /var/named/dyndb-ldap/ipa/master/example.com/keys/ >> >> When I now enable a new DNSSEC Master create freeIPA new KSK ZSK for the >> Domain ? > If you have already destroyed your original master it is probably easier > to just regenerate all keys and upload the new public keys on the glue > record of the delegating provider. > > Simo. > >> Then I have to wait after the holidays to UPDATE the DS Record on my ISP :-(. >> >> Thanks for a answer, >> >> -- >> mit freundlichen Gr??en / best regards, >> >> G?nther J. Niederwimmer >> > From sconley at caci.com Tue Dec 29 19:36:16 2015 From: sconley at caci.com (Sean Conley - US) Date: Tue, 29 Dec 2015 19:36:16 +0000 Subject: [Freeipa-users] IPA DS migration Message-ID: <3033736F-E924-4A3F-9B02-E645113880B0@caci.com> Hello, I need to migrate the users from an existing IPA server to a new IPA server on an isolated network. It appears that ?ipa migrate-ds? works only when direct connection to source LDAP server is possible. I have searched with no success for a method that would be more like an LDIF-based migration. These servers are in different realms and so have different base DNs. My hope is that I could create an LDIF file from a query against the source server, modify records to reflect the new base DN, copy result to destination server, and import it there. Can anyone direct me to some good resources or other recommendations to accomplish this? The source server in this case is CentOS 7 with FreeIPA v4.1.0. The planned destination server is RHEL 7 with FreeIPA v4.2.0. Thanks much in advance! Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From listeranon at gmail.com Wed Dec 30 06:17:53 2015 From: listeranon at gmail.com (Anon Lister) Date: Wed, 30 Dec 2015 01:17:53 -0500 Subject: [Freeipa-users] Bi directional login with AD trusts Message-ID: Hello, New to list. This is kind of a followup to the post here: https://www.redhat.com/archives/freeipa-users/2015-January/msg00351.html We are one of the odder shops that runs almost entirely linux, but the need to support some windows stuff that requires AD has come up. We have things setup as domain.com (NetBIOS name: DOM), with ipa.domain.com and ipa-replica.domain.com. We just added win.domain.com with a windows DC on ad.win.domain.com (NB Name: WIN). We are running EL 6.7/ipa 3.0.0. we got the trust setup working, can confirm we can mount (tesT) shares from IPA to windows domain, can login to the linux boxes with windows user credentials, but have been unable to figure out how to login to the windows boxes with ipa credentials (this was really our primary use case, as everything is managed in IPA and hits it for authentication, we were hoping to not have to manage 2 sets of accounts for the people needing windows, two places to update passwords, etc.). Is there support for bidirectional login in newer FreeIPA? I found the above thread that seemed to suggest you could not use IPA credentials for logging into the windows domain. Has this changed at all? We would be willing to look at upgrading to EL7 (or, id rather not, but even Fedora Server, if we can get this feature). If not is it down the pipeline? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.obaterspok at gmail.com Wed Dec 30 08:43:01 2015 From: john.obaterspok at gmail.com (John Obaterspok) Date: Wed, 30 Dec 2015 09:43:01 +0100 Subject: [Freeipa-users] Samba Authentication progres In-Reply-To: References: Message-ID: Hi Matt, It already works fine to use kerberos ticket to access samba shares. -- john 2015-12-28 14:01 GMT+01:00 Matt . : > Hi guys, > > > How is the progres on the Samba (Share) Authentication for FreeIpa ? > > I hope we already have some work around to use the FreeIPA credentials > for authing network shares. > > Matt > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Wed Dec 30 11:25:22 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Wed, 30 Dec 2015 12:25:22 +0100 Subject: [Freeipa-users] Samba Authentication progres In-Reply-To: References: Message-ID: Hi John, With which OS, package version and config ? On Ubuntu 15.10 I'm not able it seems. Thanks! 2015-12-30 9:43 GMT+01:00 John Obaterspok : > Hi Matt, > > It already works fine to use kerberos ticket to access samba shares. > > -- john > > 2015-12-28 14:01 GMT+01:00 Matt . : >> >> Hi guys, >> >> >> How is the progres on the Samba (Share) Authentication for FreeIpa ? >> >> I hope we already have some work around to use the FreeIPA credentials >> for authing network shares. >> >> Matt >> >> -- >> 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 > > From abokovoy at redhat.com Wed Dec 30 15:38:49 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 30 Dec 2015 17:38:49 +0200 Subject: [Freeipa-users] Samba Authentication progres In-Reply-To: References: Message-ID: <20151230153849.GA24668@redhat.com> On Wed, 30 Dec 2015, Matt . wrote: >Hi John, > >With which OS, package version and config ? On Ubuntu 15.10 I'm not >able it seems. That is purely issue of Ubuntu packaging: - Samba in Ubuntu 15.10 is built provide and use libwbclient.so.0.11 - SSSD in Ubuntu 15.10 is built to provide libwbclient.so.0.12 -8<-8<-8<- root at u1510:~# ls -la /usr/lib/x86_64-linux-gnu/libwbclient.so.0.11 -rw-r--r-- 1 root root 43216 Nov 12 18:08 /usr/lib/x86_64-linux-gnu/libwbclient.so.0.11 root at u1510:~# ls -la /usr/lib/x86_64-linux-gnu/sssd/modules/libwbclient.so.0.12.0 -rw-r--r-- 1 root root 35032 Sep 7 13:50 /usr/lib/x86_64-linux-gnu/sssd/modules/libwbclient.so.0.12.0 ->8->8->8- - There are no alternatives configured to switch libwbclient to use SSSD's version (Ubuntu packaging of Samba doesn't really know that there could be an alternative implementation of libwbclient) So you Samba wouldn't be able to use the libwbclient provided by SSSD directly without special tricks or rebuilding. Furthermore, - Samba in Ubuntu 15.10 is built with Heimdal Kerberos, SSSD is built with MIT Kerberos. When you enroll Ubuntu 15.10 client into FreeIPA, it configures /etc/krb5.conf according to use of MIT Kerberos, including default ccache location to be in the kernel keyring: -8<-8<-8<- root at u1510:~# cat /etc/krb5.conf|grep default_ccache_name default_ccache_name = KEYRING:persistent:%{uid} ->8->8->8- This means that Samba will not be able to see default credentials cache as set up by SSSD for the user. Also, if you change default_ccache_name to be somewhere on file system, like FILE:/tmp/krb5cc_%{uid}, MIT Kerberos has some differences in the internal format of the credentials cache and applications compiled against Heimdal kerberos library will not be able to see some of the extended details in that ccache. While Heimdal and MIT Kerberos are mostly compatible on the wire, there are no promises of compatibility here for the credentials caches beyond the basics. Also, libldap is built against Heimdal in Ubuntu 15.10. This means that whenever SSSD starts using some advanced features provided by MIT Kerberos, LDAP libraries might fail to pick them up for SASL GSSAPI authentication. In most cases this would probably work fine but for cases like using kernel keyring it would fail miserably as well. So, really, there are issues with packaging that you might overcome by doing manual work of symlinking proper libraries like we did in Fedora in coordination between Samba and SSSD packages, but things still might not work unless you downgrade a common base to features supported by both Heimdal and MIT Kerberos. There are also practical issues of SSSD's ldap helper loading both MIT and Heimdal Kerberos code in the same process instance -- which is a disaster to happen when a function with the same name from one library is called on a structure allocated by another library. A proper solution would be to get Canonical more involved into the work we do with move of Samba to use MIT Kerberos for Samba AD as lack of MIT Kerberos support in Samba AD is what forces Debian and Ubuntu to stick to Heimdal (and Fedora to abstain from packaging Samba AD flavor for several years to avoid using Heimdal instead of MIT Kerberos). Until that happens, using Fedora/CentOS/RHEL is a better choice. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Dec 30 16:28:58 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 30 Dec 2015 18:28:58 +0200 Subject: [Freeipa-users] Bi directional login with AD trusts In-Reply-To: References: Message-ID: <20151230162858.GB24668@redhat.com> On Wed, 30 Dec 2015, Anon Lister wrote: >Hello, > >New to list. This is kind of a followup to the post here: >https://www.redhat.com/archives/freeipa-users/2015-January/msg00351.html > >We are one of the odder shops that runs almost entirely linux, but the need >to support some windows stuff that requires AD has come up. We have things >setup as domain.com (NetBIOS name: DOM), with ipa.domain.com and >ipa-replica.domain.com. > >We just added win.domain.com with a windows DC on ad.win.domain.com (NB >Name: WIN). > >We are running EL 6.7/ipa 3.0.0. we got the trust setup working, can >confirm we can mount (tesT) shares from IPA to windows domain, can login to >the linux boxes with windows user credentials, but have been unable to >figure out how to login to the windows boxes with ipa credentials (this was >really our primary use case, as everything is managed in IPA and hits it >for authentication, we were hoping to not have to manage 2 sets of accounts >for the people needing windows, two places to update passwords, etc.). > >Is there support for bidirectional login in newer FreeIPA? I found the >above thread that seemed to suggest you could not use IPA credentials for >logging into the windows domain. Has this changed at all? We would be >willing to look at upgrading to EL7 (or, id rather not, but even Fedora >Server, if we can get this feature). If not is it down the pipeline? Nothing changed. It is down the pipeline but implementation of it depends on multiple factors so current plan is 'next major update' but not fixed in time. It is not an easy feat. -- / Alexander Bokovoy From yamakasi.014 at gmail.com Wed Dec 30 16:06:15 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Wed, 30 Dec 2015 17:06:15 +0100 Subject: [Freeipa-users] Samba Authentication progres In-Reply-To: <20151230153849.GA24668@redhat.com> References: <20151230153849.GA24668@redhat.com> Message-ID: He Alexander! I saw your post some time form some time ago on your G+ page and I see you guys are really making a lot of progres, there is a lot todo, but it's great, really! What you say is right, but I thought this was fixed by the newer SSSD package from 1.12.2+ or so, need to check that out. For the moment I cannot move to CentOS for this machine, I can actually add another VM for Samba with CentOS, but also here I had an issue in the past, CentOS 7 and IPA 4. Which version should be working, so Distro (I prefer CentOS), IPA, SSSD and Samba ? If I know those, I can fire another test in minutes :) Thanks and have a great new year ! (With MIT!) Matt 2015-12-30 16:38 GMT+01:00 Alexander Bokovoy : > On Wed, 30 Dec 2015, Matt . wrote: >> >> Hi John, >> >> With which OS, package version and config ? On Ubuntu 15.10 I'm not >> able it seems. > > That is purely issue of Ubuntu packaging: > - Samba in Ubuntu 15.10 is built provide and use libwbclient.so.0.11 > - SSSD in Ubuntu 15.10 is built to provide libwbclient.so.0.12 > -8<-8<-8<- > root at u1510:~# ls -la /usr/lib/x86_64-linux-gnu/libwbclient.so.0.11 > -rw-r--r-- 1 root root 43216 Nov 12 18:08 > /usr/lib/x86_64-linux-gnu/libwbclient.so.0.11 > root at u1510:~# ls -la > /usr/lib/x86_64-linux-gnu/sssd/modules/libwbclient.so.0.12.0 -rw-r--r-- 1 > root root 35032 Sep 7 13:50 > /usr/lib/x86_64-linux-gnu/sssd/modules/libwbclient.so.0.12.0 > ->8->8->8- > - There are no alternatives configured to switch libwbclient to use > SSSD's version (Ubuntu packaging of Samba doesn't really know that > there could be an alternative implementation of libwbclient) > > So you Samba wouldn't be able to use the libwbclient provided by SSSD > directly without special tricks or rebuilding. > > Furthermore, - Samba in Ubuntu 15.10 is built with Heimdal Kerberos, SSSD is > built > with MIT Kerberos. When you enroll Ubuntu 15.10 client into FreeIPA, > it configures /etc/krb5.conf according to use of MIT Kerberos, > including default ccache location to be in the kernel keyring: > -8<-8<-8<- > root at u1510:~# cat /etc/krb5.conf|grep default_ccache_name > default_ccache_name = KEYRING:persistent:%{uid} > ->8->8->8- > > This means that Samba will not be able to see default credentials cache > as set up by SSSD for the user. Also, if you change default_ccache_name > to be somewhere on file system, like FILE:/tmp/krb5cc_%{uid}, MIT > Kerberos has some differences in the internal format of the credentials > cache and applications compiled against Heimdal kerberos library will > not be able to see some of the extended details in that ccache. While > Heimdal and MIT Kerberos are mostly compatible on the wire, there are no > promises of compatibility here for the credentials caches beyond the > basics. > > Also, libldap is built against Heimdal in Ubuntu 15.10. This means that > whenever SSSD starts using some advanced features provided by MIT > Kerberos, LDAP libraries might fail to pick them up for SASL GSSAPI > authentication. In most cases this would probably work fine but for > cases like using kernel keyring it would fail miserably as well. > > So, really, there are issues with packaging that you might overcome by > doing manual work of symlinking proper libraries like we did in Fedora > in coordination between Samba and SSSD packages, but things still might > not work unless you downgrade a common base to features supported by > both Heimdal and MIT Kerberos. There are also practical issues of SSSD's > ldap helper loading both MIT and Heimdal Kerberos code in the same > process instance -- which is a disaster to happen when a function with > the same name from one library is called on a structure allocated by > another library. > > A proper solution would be to get Canonical more involved into the work > we do with move of Samba to use MIT Kerberos for Samba AD as lack of MIT > Kerberos support in Samba AD is what forces Debian and Ubuntu to stick > to Heimdal (and Fedora to abstain from packaging Samba AD flavor for > several years to avoid using Heimdal instead of MIT Kerberos). Until > that happens, using Fedora/CentOS/RHEL is a better choice. > > -- > / Alexander Bokovoy From abokovoy at redhat.com Thu Dec 31 08:52:45 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 31 Dec 2015 10:52:45 +0200 Subject: [Freeipa-users] Samba Authentication progres In-Reply-To: References: <20151230153849.GA24668@redhat.com> Message-ID: <20151231085245.GD24668@redhat.com> On Wed, 30 Dec 2015, Matt . wrote: >He Alexander! > >I saw your post some time form some time ago on your G+ page and I see >you guys are really making a lot of progres, there is a lot todo, but >it's great, really! > >What you say is right, but I thought this was fixed by the newer SSSD >package from 1.12.2+ or so, need to check that out. I did the check on 15.10+updates, so no, there is no change. And why would it be if both Samba and SSSD packages need to be actively changed, as well as libldap needs to be updated, and so on. >For the moment I cannot move to CentOS for this machine, I can >actually add another VM for Samba with CentOS, but also here I had an >issue in the past, CentOS 7 and IPA 4. > >Which version should be working, so Distro (I prefer CentOS), IPA, >SSSD and Samba ? CentOS 7/RHEL 7/Fedora 22+ should work fine with Kerberos just like John said. -- / Alexander Bokovoy From brian.topping at gmail.com Wed Dec 23 07:28:41 2015 From: brian.topping at gmail.com (Brian Topping) Date: Wed, 23 Dec 2015 00:28:41 -0700 Subject: [Freeipa-users] Failed upgrade to 4.2 via RHEL 7.2 Message-ID: <611D1200-92B8-4F2B-B8FC-110F7BA51FC5@gmail.com> Greetings all! Thanks for all the continued work on FreeIPA! :) I saw that 4.2 made it to RHEL 7.2 and upgraded. Unfortunately, the system did not come up cleanly. It seems to be some problem with the DNS server: > [root at ipa01 ~]# systemctl status named-pkcs11 > ? named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native PKCS#11 > Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service; disabled; vendor preset: disabled) > Active: failed (Result: exit-code) since Wed 2015-12-23 01:56:37 EST; 4s ago > Process: 16506 ExecStart=/usr/sbin/named-pkcs11 -u named $OPTIONS (code=exited, status=1/FAILURE) > Process: 16503 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z /etc/named.conf; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS) > > Dec 23 01:56:37 ipa01.example.com named-pkcs11[16509]: GSSAPI client step 2 > Dec 23 01:56:37 ipa01.example.com named-pkcs11[16509]: LDAP error: Invalid credentials: SASL(-14): authorization failure: security flags do not match required: bind to LDAP server failed > Dec 23 01:56:37 ipa01.example.com named-pkcs11[16509]: couldn't establish connection in LDAP connection pool: permission denied > Dec 23 01:56:37 ipa01.example.com named-pkcs11[16509]: dynamic database 'ipa' configuration failed: permission denied > Dec 23 01:56:37 ipa01.example.com named-pkcs11[16509]: loading configuration: permission denied > Dec 23 01:56:37 ipa01.example.com named-pkcs11[16509]: exiting (due to fatal error) > Dec 23 01:56:37 ipa01.example.com systemd[1]: named-pkcs11.service: control process exited, code=exited status=1 > Dec 23 01:56:37 ipa01.example.com systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11. > Dec 23 01:56:37 ipa01.example.com systemd[1]: Unit named-pkcs11.service entered failed state. > Dec 23 01:56:37 ipa01.example.com systemd[1]: named-pkcs11.service failed. https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart provides some good information. After manually starting 389, I was able to confirm that the LDAP credentials are able to retrieve the DNS tree with: > [root at ipa01 ~]# ldapsearch -H 'ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket' -Y GSSAPI -b 'cn=dns,dc=example,dc=com' I was also able to confirm that I the named.keytab file is correct: > [root at ipa01 ~]# kinit -k -t /etc/named.keytab DNS/ipa01.example.com > [root at ipa01 ~]# klist > Ticket cache: KEYRING:persistent:0:krb_ccache_th1WCcV > Default principal: DNS/ipa01.example.com at EXAMPLE.COM > > Valid starting Expires Service principal > 12/23/2015 02:07:14 12/24/2015 02:07:14 krbtgt/EXAMPLE.COM at EXAMPLE.COM I have disabled unencrypted binds to 389, but I read somewhere this evening this should not be an issue since passwords were being sent and the STARTTLS is always being used. https://fedorahosted.org/freeipa/ticket/5232 seems to be related here, but I did the install on a healthy server, so I can't imagine that it's the same. I also don't see any recovery techniques listed here or in the issue that it links to at https://bugzilla.redhat.com/show_bug.cgi?id=1254412 . I searched the list archives for this error and came up empty. The versions I have are as follows: > bind-license-9.9.4-29.el7_2.1.noarch > bind-libs-lite-9.9.4-29.el7_2.1.x86_64 > bind-utils-9.9.4-29.el7_2.1.x86_64 > bind-pkcs11-libs-9.9.4-29.el7_2.1.x86_64 > bind-dyndb-ldap-8.0-1.el7.x86_64 > bind-pkcs11-utils-9.9.4-29.el7_2.1.x86_64 > bind-9.9.4-29.el7_2.1.x86_64 > bind-pkcs11-9.9.4-29.el7_2.1.x86_64 > bind-libs-9.9.4-29.el7_2.1.x86_64 > ipa-python-4.2.0-15.el7.centos.3.x86_64 > ipa-admintools-4.2.0-15.el7.centos.3.x86_64 > sssd-ipa-1.13.0-40.el7_2.1.x86_64 > ipa-client-4.2.0-15.el7.centos.3.x86_64 > ipa-server-dns-4.2.0-15.el7.centos.3.x86_64 > ipa-server-4.2.0-15.el7.centos.3.x86_64 > python-libipa_hbac-1.13.0-40.el7_2.1.x86_64 > libipa_hbac-1.13.0-40.el7_2.1.x86_64 I'm also attaching the ipaupgrade.log Hopefully I am missing something simple here. Can anyone help? Happy solstice! Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipaupgrade.log Type: application/octet-stream Size: 9188292 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From fvende.ext at orange.com Wed Dec 23 17:03:32 2015 From: fvende.ext at orange.com (fvende.ext at orange.com) Date: Wed, 23 Dec 2015 17:03:32 +0000 Subject: [Freeipa-users] FreeIPA 4.x + CentOS 6.4 Message-ID: <29287_1450890213_567AD3E5_29287_3990_1_1D24A0A1407AA6499AADBA43C8A73ED505A5C2@OPEXCNORM63.corporate.adroot.infra.ftgroup> Hi, Do you know the compatibility between the different "FreeIPA 4" versions and CentOS 6.4, please ? I have tried to get the information but I don't have a clear response to this question. Thanks in advance, Best regards, Fran?ois Xavier VENDE _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen at jochen.org Sun Dec 27 16:39:11 2015 From: jochen at jochen.org (Jochen Hein) Date: Sun, 27 Dec 2015 17:39:11 +0100 Subject: [Freeipa-users] Cockpit integration part I - Single Sign On Message-ID: <83poxr4zio.fsf@echidna.jochen.org> Hi, here is what I did on my system - may be helpful to others as well. Cockpit: enable Single-Sign-On with FreeIPA =========================================== I wanted to use SSO to access the Cockpit already installed on my freeipa server. Upstream documentation is on http://cockpit-project.org/guide/latest/sso.html, so we only add some remarks here. Upstream: ,---- | There must be a valid Kerberos host key for the server in the | /etc/krb5.keytab file. It may be necessary to create a kerberos | service principal and update the keytab if it is not | present. Depending on your domain type different service names are | required: | | Active Directory HOST/server.example.com at EXAMPLE.COM | IPA and MIT HTTP/server.example.com at EXAMPLE.COM `---- This has already happened - apache on my server uses the service HTTP/server.example.com at EXAMPLE.COM, but the service is not present in the server keytab. So we need to add the service principal there. If we just generate a new keytab, we invalidate the keytab used by apache. So we need to only retrieve the keytab, not regenerate it. This is only possible after we allowed the retrieval of the keytab for either the admin principal, the host principal or some users/host groups. Here we go for the host principal: # kinit admin # ipa service-allow-retrieve-keytab HTTP/freeipa.jochen.org at JOCHEN.ORG --hosts=freeipa.jochen.org Finally we retrieve the service keytab into /etc/krb5.keytab: # ipa-getkeytab -r -s freeipa.jochen.org -p HTTP/freeipa.jochen.org at JOCHEN.ORG -k /etc/krb5.keytab After that Single Sign On works as expected. Jochen -- The only problem with troubleshooting is that the trouble shoots back. From jochen at jochen.org Sun Dec 27 16:43:32 2015 From: jochen at jochen.org (Jochen Hein) Date: Sun, 27 Dec 2015 17:43:32 +0100 Subject: [Freeipa-users] Cockpit Integration part II - SSL certificates Message-ID: <83lh8f4zbf.fsf@echidna.jochen.org> Hi, Right now cockpit still uses a locally created TLS certificate, that should be changed to a IPA issued certificate. What I understood is that a certificate is for a host (e.g. ipa.example.com), so apache and cockpit should use the same certificate. Is that understanding correct? So this is what I did: # cp cert8.db key3.db secmod.db pwdfile.txt /tmp/ # cd /tmp # pk12util -o keys.p12 -n 'Server-Cert' -d . -k /etc/httpd/alias/pwdfile.txt # openssl pkcs12 -in keys.p12 -out freeipa.key -nodes -clcerts # cp freeipa.key /etc/cockpit/ws-certs.d/freeipa.cert # systemctl restart cockpit.service Now Cockpit and apache use the same certificate, but the cockpit certificate is not tracked by certmonger. Any idea how that could work? Jochen -- The only problem with troubleshooting is that the trouble shoots back. From ernestodiazmiranda at gmail.com Tue Dec 29 21:48:47 2015 From: ernestodiazmiranda at gmail.com (Ernesto Diaz Miranda) Date: Tue, 29 Dec 2015 21:48:47 +0000 (UTC) Subject: [Freeipa-users] Failed to start Identity, Policy, Audit References: <54F4B68B.9090502@redhat.com> Message-ID: Are you checked the DNS or /etc/hosts file?