Re: [Freeipa-users] FreeIPA mail object to use in 3rd party tool
Hi all I am fighting this exact problem too. We had setup Jira, integrated to FreeIPA with the option Internal Directory with LDAP Authentication, using anonymous bind. This integration path means that when a FreeIPA user attempts to logon to Jira with his FreeIPA Credentials, his user is replicated from FreeIPA to the Jira user directory. https://confluence.atlassian.com/display/JIRA/Connecting+to+an+Internal +Directory+with+LDAP+Authentication While this allows FreeIPA users to successfully log in to Jira, the user was replicated without email, which renders Jira as useful as a chocolate teepot. Alexanders's reply prompted me to go back to basics. So I fired up Apache Directory Studio, and the command line to do some ldapsearchs, to see what was returned. This should then guide me how to configure the JIRA / FreeIPA integration. Query 1: Anonymous bind, filter is uid = bilbo [root@xxx-ldap ~]# ldapsearch -x -h localhost -p 389 -b dc=my,dc=silly,dc=example,dc=com (uid=bilbo) # extended LDIF # # LDAPv3 # base dc=my,dc=silly,dc=example,dc=com with scope subtree # filter: (uid=bilbo) # requesting: ALL # # bilbo, users, compat, my.ch.example.com dn: uid=bilbo,cn=users,cn=compat,dc=my,dc=silly,dc=example,dc=com cn: bilbo bagins objectClass: posixAccount objectClass: top gidNumber: 1175800010 gecos: bilbo bagins uidNumber: 1175800010 loginShell: /bin/sh homeDirectory: /home/bilbo uid: bilbo # bilbo, users, accounts, my.ch.example.com dn: uid=bilbo,cn=users,cn=accounts,dc=my,dc=silly,dc=example,dc=com displayName: bilbo bagins cn: bilbo bagins objectClass: ipaobject objectClass: person objectClass: top objectClass: ipasshuser objectClass: inetorgperson objectClass: sambaSAMAccount objectClass: organizationalperson objectClass: krbticketpolicyaux objectClass: krbprincipalaux objectClass: inetuser objectClass: posixaccount objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh initials: bb gecos: bilbo bagins homeDirectory: /home/bilbo uid: bilbo givenName: bilbo sn: bagins uidNumber: 1175800010 gidNumber: 1175800010 # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 This returns 2 replies, inc one from the compat tree, as suggested by Alexander. Note however, neither reply has the mail attribute! // Query 2: Anonymous bind, filtered on objectClass = inetorgperson AND uid = bilbo (This is probably close to the JiRA query, which includes inetorgperson) [root@xxx-ldap ~]# ldapsearch -x -h localhost -p 389 -b dc=my,dc=silly,dc=example,dc=com ((objectClass=inetorgperson)(uid=bilbo)) # extended LDIF # # LDAPv3 # base dc=my,dc=silly,dc=example,dc=com with scope subtree # filter: ((objectClass=inetorgperson)(uid=bilbo)) # requesting: ALL # # bilbo, users, accounts, my.ch.example.com dn: uid=bilbo,cn=users,cn=accounts,dc=my,dc=silly,dc=example,dc=com displayName: bilbo bagins cn: bilbo bagins objectClass: ipaobject objectClass: person objectClass: top objectClass: ipasshuser objectClass: inetorgperson objectClass: sambaSAMAccount objectClass: organizationalperson objectClass: krbticketpolicyaux objectClass: krbprincipalaux objectClass: inetuser objectClass: posixaccount objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh initials: bb gecos: bilbo bagins homeDirectory: /home/bilbo uid: bilbo givenName: bilbo sn: bagins uidNumber: 1175800010 gidNumber: 1175800010 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 This now returns 1 record, from users, accounts, but still no mail attribute // Ah! me thinks - what about a search with user and password? Does this get us something different? Query 3: same as query 2, but no longer anonymous: [root@xxx-ldap ~]# ldapsearch -x -D uid=bilbo,cn=users,cn=accounts,dc=my,dc=silly,dc=example,dc=com -W -h localhost -p 389 -b dc=my,dc=silly,dc=example,dc=com ((objectClass=inetorgperson)(uid=bilbo)) Enter LDAP Password: # extended LDIF # # LDAPv3 # base dc=my,dc=silly,dc=example,dc=com with scope subtree # filter: ((objectClass=inetorgperson)(uid=bilbo)) # requesting: ALL # # bilbo, users, accounts, my.ch.example.com dn: uid=bilbo,cn=users,cn=accounts,dc=my,dc=silly,dc=example,dc=com displayName: bilbo bagins cn: bilbo bagins objectClass: ipaobject objectClass: person objectClass: top objectClass: ipasshuser objectClass: inetorgperson objectClass: sambaSAMAccount objectClass: organizationalperson objectClass: krbticketpolicyaux objectClass: krbprincipalaux objectClass: inetuser objectClass: posixaccount objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh initials: bb gecos: bilbo bagins homeDirectory: /home/bilbo uid: bilbo mail: l...@ch.example.com krbPrincipalName: bi...@my.silly.example.com givenName: bilbo
Re: [Freeipa-users] DNS forwarder first does not fallback to local
On 29.6.2015 13:16, Matt . wrote: Hi, The zones are on both servers, just not all records are, this has a reason. One server is maintained by a script, the other one only forwards to it if needed. The idea is that it does a local lookup, when it doesn't find the record locally, it forwards to it's forwarder to see if it has an answer. I thought this was working but isn't and following your table it should. I'm sorry but I do not understand. Could you please give us specific examples? - what data you have in what zones and on what server - what is your forwarding configuration - what is the result you get - what is the expected result Also, please add output from command: $ rpm -q bind-dyndb-ldap bind ipa-server Thanks. What are my options ? We will see once I understand your requirement :-) Petr^2 Spacek 2015-06-29 11:20 GMT+02:00 Petr Spacek pspa...@redhat.com: On 27.6.2015 19:06, Matt . wrote: Hi All, When I add a forwarder with policy to forward first, there is only forwarder and not a fallback to local when the record doesn't exist on the forward server. When I remove the forwardserver, the local lookup works great again. Is this known to 3.0 servers or has it been a bug or am I doing somethin wrong ? Forwarders in FreeIPA behave in the same way as in BIND 9.9 and the behavior you describe seems to be okay. The behavior is summarized in a nice table here: http://www.freeipa.org/page/V4/Forward_zones#Use_Cases In other words, there is no thing like 'look into this zone and look into that zone if the first zone does not contain an answer'. Such behavior would break the very basic principle of DNS - division to independent, self-contained zones. What are you trying to achieve? What is the use-case? Please note that in FreeIPA 4.1 zones with non-empty 'forwarders' attribute were automatically configured as forward zones. The split to pure forward and master zones happened in FreeIPA 4.1. -- Petr^2 Spacek -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] DNS forwarder first does not fallback to local
Hi Petr, Yes I understand why this is not possible. The idea was to have a managed DNS server from scripting and one for other usage by clients who only need to know about the unknown records on Server1, this as it should forward most and only do specific local lookups. Your subdomain solution might be something if I want to go this way. Thanks! Matt 2015-06-29 15:37 GMT+02:00 Petr Spacek pspa...@redhat.com: On 29.6.2015 14:07, Matt . wrote: Hi Petr, Bot servers have zone: domain.tld Server1 (192.168.1.1) has: domain.tld foo A 192.168.1.10 bar A 192.168.1.20 Server2 (192.168.2.1) has: domain.tld candy A 192.168.2.100 I have a forward first on Server1 to the IP of Server2 So when my DNS server on my client is 192.168.1.1 and I do a nslookup candy.domain.tld it should not lookup locally but on the forward (Server2). But when I lookup foo.domain.tld it should get a reply of Server1 Okay, now I understand it. It is not possible now and it will likely never be possible because it breaks the basic principles of DNS. You are expected to have one set of servers which are authoritative for a given zone and this set of servers should synchronized databases among each other. If you really want to split responsibility for different records to multiple servers then you should create sub-domains and do proper delegation for sub-domains. For example, server 1 might be authoritative for zone domain.tld. This domain can contain delegation to server2 for names candy.domain.tld and so on. I hope this helps. Petr^2 Spacek rpm -q bind-dyndb-ldap bind ipa-server bind-dyndb-ldap-2.3-6.el6_6.x86_64 bind-9.8.2-0.30.rc1.el6_6.3.x86_64 ipa-server-3.0.0-42.el6.centos.x86_64 It would also be great if this is possible between IPA 3 and 4. Thanks for your help so far! Cheers, Matt 2015-06-29 13:44 GMT+02:00 Petr Spacek pspa...@redhat.com: On 29.6.2015 13:16, Matt . wrote: Hi, The zones are on both servers, just not all records are, this has a reason. One server is maintained by a script, the other one only forwards to it if needed. The idea is that it does a local lookup, when it doesn't find the record locally, it forwards to it's forwarder to see if it has an answer. I thought this was working but isn't and following your table it should. I'm sorry but I do not understand. Could you please give us specific examples? - what data you have in what zones and on what server - what is your forwarding configuration - what is the result you get - what is the expected result Also, please add output from command: $ rpm -q bind-dyndb-ldap bind ipa-server Thanks. What are my options ? We will see once I understand your requirement :-) Petr^2 Spacek 2015-06-29 11:20 GMT+02:00 Petr Spacek pspa...@redhat.com: On 27.6.2015 19:06, Matt . wrote: Hi All, When I add a forwarder with policy to forward first, there is only forwarder and not a fallback to local when the record doesn't exist on the forward server. When I remove the forwardserver, the local lookup works great again. Is this known to 3.0 servers or has it been a bug or am I doing somethin wrong ? Forwarders in FreeIPA behave in the same way as in BIND 9.9 and the behavior you describe seems to be okay. The behavior is summarized in a nice table here: http://www.freeipa.org/page/V4/Forward_zones#Use_Cases In other words, there is no thing like 'look into this zone and look into that zone if the first zone does not contain an answer'. Such behavior would break the very basic principle of DNS - division to independent, self-contained zones. What are you trying to achieve? What is the use-case? Please note that in FreeIPA 4.1 zones with non-empty 'forwarders' attribute were automatically configured as forward zones. The split to pure forward and master zones happened in FreeIPA 4.1. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] UPN suffixes in AD trust
On Mon, Jun 29, 2015 at 11:24:00AM +0200, Giorgio Biacchi wrote: On 06/29/2015 10:30 AM, Sumit Bose wrote: On Mon, Jun 29, 2015 at 10:04:04AM +0200, Giorgio Biacchi wrote: On 06/26/2015 08:06 PM, Sumit Bose wrote: On Fri, Jun 26, 2015 at 04:34:05PM +0200, Giorgio Biacchi wrote: On 06/26/2015 02:38 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 07:00:34PM +0200, Giorgio Biacchi wrote: On 06/25/2015 05:44 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 04:29:37PM +0200, Giorgio Biacchi wrote: On 06/25/2015 02:10 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 01:06:22PM +0200, Giorgio Biacchi wrote: On 06/25/2015 12:56 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote: On 06/24/2015 06:45 PM, Sumit Bose wrote: On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote: Hi everybody, I established a bidirectional trust between an IPA server (version 4.1.0 on CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), mydomain.local. Everything is working fine, and I'm able to authenticate and logon on a linux host joined to IPA server using AD credentials (username@mydomain.local). But active directory is configured with two more UPN suffixes (otherdomain.com and sub.otherdomain.com), and I cannot logon with credentials using alternative UPN (example: john@otherdomain.com). How can I make this possible? Another trust (ipa trust-add) with the same AD? Manual configuration of krb5 and/or sssd? Have you tried to login to an IPA client or the server? Please try with an IPA server first. If this does not work it would be nice if you can send the SSSD log files from the IPA server which are generated during the logon attempt. Please call 'sss_cache -E' before to invalidate all cached entries so that the logs will contain all needed calls to AD. Using UPN suffixes were added to the AD provider some time ago and the code is available in the IPA provider as well, but I guess no one has actually tried this before. bye, Sumit First of all let me say that i feel like I'm missing some config somewhere.. Changes tried in krb5.conf to support UPN suffixes didn't helped. I can only access the server vi ssh so I've attached the logs for a successful login for account1@mydomain.local and an unsuccessful login for accou...@otherdomain.com done via ssh. Bye and thanks for your help It looks like the request is not properly propagated to sub-domains (the trusted AD domain) but only send to the IPA domain. Would it be possible for you to run a test build of SSSD which might fix this? If yes, which version of SSSD are you currently using? Then I can prepare a test build with the patch on top of this version. bye, Sumit Hi, I'm using sssd 1.12.2 (sssd --version) on CentOS 7.1.1503 and I'm available for any test. Here's the packages version for sssd: sssd-common-1.12.2-58.el7_1.6.x86_64 sssd-krb5-1.12.2-58.el7_1.6.x86_64 python-sssdconfig-1.12.2-58.el7_1.6.noarch sssd-krb5-common-1.12.2-58.el7_1.6.x86_64 sssd-ipa-1.12.2-58.el7_1.6.x86_64 sssd-1.12.2-58.el7_1.6.x86_64 sssd-libwbclient-1.12.2-58.el7_1.6.x86_64 sssd-ad-1.12.2-58.el7_1.6.x86_64 sssd-ldap-1.12.2-58.el7_1.6.x86_64 sssd-common-pac-1.12.2-58.el7_1.6.x86_64 sssd-proxy-1.12.2-58.el7_1.6.x86_64 sssd-client-1.12.2-58.el7_1.6.x86_64 Please try the packages at http://koji.fedoraproject.org/koji/taskinfo?taskID=10210844 . bye, Sumit Hi, I've installed the new RPMs, now if I run on the server: id account1@mydomain.local id accou...@otherdomain.com id accou...@sub.otherdomain.com all the users are found but I'm still unable to log in via ssh with the accounts @otherdomain.com and @sub.otherdomain.com. In attachment the logs for unsuccessful login for user accou...@otherdomain.com. Bother, I forgot to add the fix to the pam responder as well, please try new packages from http://koji.fedoraproject.org/koji/taskinfo?taskID=10212212 . bye, Sumit Hi, I've updated all the packages but still no login. Logs follows. I found another issue in the logs which should be fixed by the build from http://koji.fedoraproject.org/koji/taskinfo?taskID=10217756 . Please send the sssd_pam log file as well it might contain more details about what goes wrong during authentication. bye, Sumit Hi, packages update, sssd and kerberos services restarted, cache flushed but still no login on the IPA server. As before, logs attached. I've also included the logs generated by the restart of sssd service because there were no logs in sssd_pam.log when trying to authenticate. Debug level is set to 6 in the sections: [domain/ipa.mydomain.local] [sssd] [nss] [pam] of /etc/sssd/sssd.conf, please tell me if this is enough or if I have to
Re: [Freeipa-users] DNS forwarder first does not fallback to local
On 29.6.2015 14:07, Matt . wrote: Hi Petr, Bot servers have zone: domain.tld Server1 (192.168.1.1) has: domain.tld foo A 192.168.1.10 bar A 192.168.1.20 Server2 (192.168.2.1) has: domain.tld candy A 192.168.2.100 I have a forward first on Server1 to the IP of Server2 So when my DNS server on my client is 192.168.1.1 and I do a nslookup candy.domain.tld it should not lookup locally but on the forward (Server2). But when I lookup foo.domain.tld it should get a reply of Server1 Okay, now I understand it. It is not possible now and it will likely never be possible because it breaks the basic principles of DNS. You are expected to have one set of servers which are authoritative for a given zone and this set of servers should synchronized databases among each other. If you really want to split responsibility for different records to multiple servers then you should create sub-domains and do proper delegation for sub-domains. For example, server 1 might be authoritative for zone domain.tld. This domain can contain delegation to server2 for names candy.domain.tld and so on. I hope this helps. Petr^2 Spacek rpm -q bind-dyndb-ldap bind ipa-server bind-dyndb-ldap-2.3-6.el6_6.x86_64 bind-9.8.2-0.30.rc1.el6_6.3.x86_64 ipa-server-3.0.0-42.el6.centos.x86_64 It would also be great if this is possible between IPA 3 and 4. Thanks for your help so far! Cheers, Matt 2015-06-29 13:44 GMT+02:00 Petr Spacek pspa...@redhat.com: On 29.6.2015 13:16, Matt . wrote: Hi, The zones are on both servers, just not all records are, this has a reason. One server is maintained by a script, the other one only forwards to it if needed. The idea is that it does a local lookup, when it doesn't find the record locally, it forwards to it's forwarder to see if it has an answer. I thought this was working but isn't and following your table it should. I'm sorry but I do not understand. Could you please give us specific examples? - what data you have in what zones and on what server - what is your forwarding configuration - what is the result you get - what is the expected result Also, please add output from command: $ rpm -q bind-dyndb-ldap bind ipa-server Thanks. What are my options ? We will see once I understand your requirement :-) Petr^2 Spacek 2015-06-29 11:20 GMT+02:00 Petr Spacek pspa...@redhat.com: On 27.6.2015 19:06, Matt . wrote: Hi All, When I add a forwarder with policy to forward first, there is only forwarder and not a fallback to local when the record doesn't exist on the forward server. When I remove the forwardserver, the local lookup works great again. Is this known to 3.0 servers or has it been a bug or am I doing somethin wrong ? Forwarders in FreeIPA behave in the same way as in BIND 9.9 and the behavior you describe seems to be okay. The behavior is summarized in a nice table here: http://www.freeipa.org/page/V4/Forward_zones#Use_Cases In other words, there is no thing like 'look into this zone and look into that zone if the first zone does not contain an answer'. Such behavior would break the very basic principle of DNS - division to independent, self-contained zones. What are you trying to achieve? What is the use-case? Please note that in FreeIPA 4.1 zones with non-empty 'forwarders' attribute were automatically configured as forward zones. The split to pure forward and master zones happened in FreeIPA 4.1. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] UPN suffixes in AD trust
On Mon, Jun 29, 2015 at 03:11:57PM +0200, Sumit Bose wrote: On Mon, Jun 29, 2015 at 11:24:00AM +0200, Giorgio Biacchi wrote: On 06/29/2015 10:30 AM, Sumit Bose wrote: On Mon, Jun 29, 2015 at 10:04:04AM +0200, Giorgio Biacchi wrote: On 06/26/2015 08:06 PM, Sumit Bose wrote: On Fri, Jun 26, 2015 at 04:34:05PM +0200, Giorgio Biacchi wrote: On 06/26/2015 02:38 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 07:00:34PM +0200, Giorgio Biacchi wrote: On 06/25/2015 05:44 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 04:29:37PM +0200, Giorgio Biacchi wrote: On 06/25/2015 02:10 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 01:06:22PM +0200, Giorgio Biacchi wrote: On 06/25/2015 12:56 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote: On 06/24/2015 06:45 PM, Sumit Bose wrote: On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote: Hi everybody, I established a bidirectional trust between an IPA server (version 4.1.0 on CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), mydomain.local. Everything is working fine, and I'm able to authenticate and logon on a linux host joined to IPA server using AD credentials (username@mydomain.local). But active directory is configured with two more UPN suffixes (otherdomain.com and sub.otherdomain.com), and I cannot logon with credentials using alternative UPN (example: john@otherdomain.com). How can I make this possible? Another trust (ipa trust-add) with the same AD? Manual configuration of krb5 and/or sssd? Have you tried to login to an IPA client or the server? Please try with an IPA server first. If this does not work it would be nice if you can send the SSSD log files from the IPA server which are generated during the logon attempt. Please call 'sss_cache -E' before to invalidate all cached entries so that the logs will contain all needed calls to AD. Using UPN suffixes were added to the AD provider some time ago and the code is available in the IPA provider as well, but I guess no one has actually tried this before. bye, Sumit First of all let me say that i feel like I'm missing some config somewhere.. Changes tried in krb5.conf to support UPN suffixes didn't helped. I can only access the server vi ssh so I've attached the logs for a successful login for account1@mydomain.local and an unsuccessful login for accou...@otherdomain.com done via ssh. Bye and thanks for your help It looks like the request is not properly propagated to sub-domains (the trusted AD domain) but only send to the IPA domain. Would it be possible for you to run a test build of SSSD which might fix this? If yes, which version of SSSD are you currently using? Then I can prepare a test build with the patch on top of this version. bye, Sumit Hi, I'm using sssd 1.12.2 (sssd --version) on CentOS 7.1.1503 and I'm available for any test. Here's the packages version for sssd: sssd-common-1.12.2-58.el7_1.6.x86_64 sssd-krb5-1.12.2-58.el7_1.6.x86_64 python-sssdconfig-1.12.2-58.el7_1.6.noarch sssd-krb5-common-1.12.2-58.el7_1.6.x86_64 sssd-ipa-1.12.2-58.el7_1.6.x86_64 sssd-1.12.2-58.el7_1.6.x86_64 sssd-libwbclient-1.12.2-58.el7_1.6.x86_64 sssd-ad-1.12.2-58.el7_1.6.x86_64 sssd-ldap-1.12.2-58.el7_1.6.x86_64 sssd-common-pac-1.12.2-58.el7_1.6.x86_64 sssd-proxy-1.12.2-58.el7_1.6.x86_64 sssd-client-1.12.2-58.el7_1.6.x86_64 Please try the packages at http://koji.fedoraproject.org/koji/taskinfo?taskID=10210844 . bye, Sumit Hi, I've installed the new RPMs, now if I run on the server: id account1@mydomain.local id accou...@otherdomain.com id accou...@sub.otherdomain.com all the users are found but I'm still unable to log in via ssh with the accounts @otherdomain.com and @sub.otherdomain.com. In attachment the logs for unsuccessful login for user accou...@otherdomain.com. Bother, I forgot to add the fix to the pam responder as well, please try new packages from http://koji.fedoraproject.org/koji/taskinfo?taskID=10212212 . bye, Sumit Hi, I've updated all the packages but still no login. Logs follows. I found another issue in the logs which should be fixed by the build from http://koji.fedoraproject.org/koji/taskinfo?taskID=10217756 . Please send the sssd_pam log file as well it might contain more details about what goes wrong during authentication. bye, Sumit Hi, packages update, sssd and kerberos services restarted, cache flushed but still no login on the IPA server. As before, logs attached. I've also included the logs generated by the restart of sssd service because there were no logs in
Re: [Freeipa-users] reverse lookup dns records in trust setup
On 29.6.2015 13:57, John Stein wrote: Hi, I have an AD and IdM server. AD domain - john.com IdM domain - linux.john.com each spans multiple netwrok segments, with some segments having both linux and windows machines. the IdM is configured to forward DNS requests to AD (forward first), and the AD is configured to forward requests in the linux.john.com domain to the IdM. However, I'm having a problem regarding reverse lookup zones. Where should they be so they can be accessed from both linux and windows machines? From DNS's point of view it does not matter, pick one side (AD or IPA) to host the reverse zone and configure delegation or forwarding on the other side. That is all you need if you are willing to update records manually. If I put them in IdM, how will the AD know which requests to forward to the IdM? Either properly configure delegation (if you have control over the parent zone) or add forwarder (only if you do not have control over parent zone - usual caveats for forwarding apply). It seems to me that I need to somehow register them at the AD, so the A record is in the IdM server and the PTR is in the AD. Is it possible to do it automatically, host/ principals from IPA Kerberos realm are generally not allowed to get tickets for AD realm so automatic update from IPA to AD is not possible. It might work the other way around (I did not test this): - Configure reverse zone in IPA - Configure delegation/forwarding in AD so all clients can properly resolve the reverse zone - Allow all clients to update their PTR records. Update policy like this might work: $ ipa dnszone-mod 2.0.192.in-addr.arpa. --update-policy='grant AD.EXAMPLE krb5-self * PTR; grant IPA.EXAMPLE krb5-self * PTR;' $ ipa dnszone-mod 2.0.192.in-addr.arpa. --dynamic-update=1 I would like to hear from you if this works in your environment or not. Thank you! -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA mail object to use in 3rd party tool
Hi As of a few minutes ago, we can now replicate FreeIPA users to JIRA, including the vital mail attribute! Note there are probably other solutions that work as well, but this is the one that works for us. Key points: a) Integration Style: Internal Directory with LDAP Authentication -- only those users that attempt to login are replicated, useful if your JIRA users are a subset of your FreeIPA users. b) LDAP Type = Generic LDAP -- JIRA does not yet have native FreeIPA Support. c) bind = via user / password -- we first tried anonymous bind (w/o user). While this replicated users and logins worked, the all important mail attribute was not replicated. d) as the password of the bind user is stored in plaintext in the jira db, make sure this is a limited user (member of the default ipa-users group is sufficient). e.g. don't use the Directory Manager user! e) ldap.user.filter=(objectclass=inetorgperson) ensures that replies DO NOT come from the compat tree (no mail attribute). We want replies from cn=users,cn=accounts, which does have the mail attribute Below is the config direct from the Jira database (of course we made the config changes via the Jira admin GUI, which has a nifty Test function. mysql select attribute_name, attribute_value from cwd_directory_attribute where directory_id = 10001; ++-+ | attribute_name | attribute_value | ++-+ | autoAddGroups | jira-users | | crowd.delegated.directory.auto.create.user | true | | crowd.delegated.directory.auto.update.user | true | | crowd.delegated.directory.importGroups | false | | crowd.delegated.directory.type | com.atlassian.crowd.directory.GenericLDAP | | ldap.basedn| dc=my,dc=silly,dc=example,dc=com| | ldap.external.id | uid | | ldap.group.description | description | | ldap.group.dn | | | ldap.group.filter | (objectclass=groupOfUniqueNames)| | ldap.group.name| cn | | ldap.group.objectclass | groupOfUniqueNames | | ldap.group.usernames | uniqueMember | | ldap.nestedgroups.disabled | true | | ldap.pagedresults | false | | ldap.pagedresults.size | 1000 | | ldap.password | x | | ldap.referral | false | | ldap.url | ldap://xxx-ldap.my.silly.example.com:389| | ldap.user.displayname | displayName | | ldap.user.dn | cn=accounts | | ldap.user.email| mail | | ldap.user.filter | (objectclass=inetorgperson) | | ldap.user.firstname| givenName | | ldap.user.group| memberOf | | ldap.user.lastname | sn | | ldap.user.objectclass | inetorgperson | | ldap.user.username | uid | | ldap.user.username.rdn | cn | | ldap.userdn| uid=,cn=users,cn=accounts,dc=my,dc=silly,dc=example,dc=com | | ldap.usermembership.use| false | | ldap.usermembership.use.for.groups | false | ++-+ @Martin K In an earlier thread on FreeIPA / JIRA integration you asked for contributions to a How to Article. I think the solution above could be the basis of such an article. Cheers Chris From: Christopher Lamb/Switzerland/IBM@IBMCH To: Alexander Bokovoy aboko...@redhat.com, markus@mc.ingenico.com Cc: freeipa-users@redhat.com Date: 29.06.2015 11:27 Subject:Re: [Freeipa-users] FreeIPA mail object to use in 3rd party tool Sent by:freeipa-users-boun...@redhat.com Hi all I am fighting this exact problem too. We had setup Jira, integrated to FreeIPA with the option Internal Directory with LDAP Authentication, using anonymous bind. This integration path means that when a FreeIPA user attempts to logon to Jira with his FreeIPA Credentials, his user is replicated from FreeIPA to the Jira user directory. https://confluence.atlassian.com/display/JIRA/Connecting+to+an+Internal +Directory+with+LDAP+Authentication While this allows FreeIPA users to successfully log in to Jira, the user was replicated without email, which renders Jira as useful as a chocolate
Re: [Freeipa-users] DNS forwarder first does not fallback to local
On 27.6.2015 19:06, Matt . wrote: Hi All, When I add a forwarder with policy to forward first, there is only forwarder and not a fallback to local when the record doesn't exist on the forward server. When I remove the forwardserver, the local lookup works great again. Is this known to 3.0 servers or has it been a bug or am I doing somethin wrong ? Forwarders in FreeIPA behave in the same way as in BIND 9.9 and the behavior you describe seems to be okay. The behavior is summarized in a nice table here: http://www.freeipa.org/page/V4/Forward_zones#Use_Cases In other words, there is no thing like 'look into this zone and look into that zone if the first zone does not contain an answer'. Such behavior would break the very basic principle of DNS - division to independent, self-contained zones. What are you trying to achieve? What is the use-case? Please note that in FreeIPA 4.1 zones with non-empty 'forwarders' attribute were automatically configured as forward zones. The split to pure forward and master zones happened in FreeIPA 4.1. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] reverse lookup dns records in trust setup
Hi, I have an AD and IdM server. AD domain - john.com IdM domain - linux.john.com each spans multiple netwrok segments, with some segments having both linux and windows machines. the IdM is configured to forward DNS requests to AD (forward first), and the AD is configured to forward requests in the linux.john.com domain to the IdM. However, I'm having a problem regarding reverse lookup zones. Where should they be so they can be accessed from both linux and windows machines? If I put them in IdM, how will the AD know which requests to forward to the IdM? It seems to me that I need to somehow register them at the AD, so the A record is in the IdM server and the PTR is in the AD. Is it possible to do it automatically, or am I supposed to configure the IdM server to create the A record upon client registration and the manually create the PTR record in AD? Is there another solution that eludes me? Thank you very much, John -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] DNS forwarder first does not fallback to local
Hi, The zones are on both servers, just not all records are, this has a reason. One server is maintained by a script, the other one only forwards to it if needed. The idea is that it does a local lookup, when it doesn't find the record locally, it forwards to it's forwarder to see if it has an answer. I thought this was working but isn't and following your table it should. What are my options ? Thanks, Matt 2015-06-29 11:20 GMT+02:00 Petr Spacek pspa...@redhat.com: On 27.6.2015 19:06, Matt . wrote: Hi All, When I add a forwarder with policy to forward first, there is only forwarder and not a fallback to local when the record doesn't exist on the forward server. When I remove the forwardserver, the local lookup works great again. Is this known to 3.0 servers or has it been a bug or am I doing somethin wrong ? Forwarders in FreeIPA behave in the same way as in BIND 9.9 and the behavior you describe seems to be okay. The behavior is summarized in a nice table here: http://www.freeipa.org/page/V4/Forward_zones#Use_Cases In other words, there is no thing like 'look into this zone and look into that zone if the first zone does not contain an answer'. Such behavior would break the very basic principle of DNS - division to independent, self-contained zones. What are you trying to achieve? What is the use-case? Please note that in FreeIPA 4.1 zones with non-empty 'forwarders' attribute were automatically configured as forward zones. The split to pure forward and master zones happened in FreeIPA 4.1. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] DNS forwarder first does not fallback to local
Hi Petr, Bot servers have zone: domain.tld Server1 (192.168.1.1) has: domain.tld foo A 192.168.1.10 bar A 192.168.1.20 Server2 (192.168.2.1) has: domain.tld candy A 192.168.2.100 I have a forward first on Server1 to the IP of Server2 So when my DNS server on my client is 192.168.1.1 and I do a nslookup candy.domain.tld it should not lookup locally but on the forward (Server2). But when I lookup foo.domain.tld it should get a reply of Server1 rpm -q bind-dyndb-ldap bind ipa-server bind-dyndb-ldap-2.3-6.el6_6.x86_64 bind-9.8.2-0.30.rc1.el6_6.3.x86_64 ipa-server-3.0.0-42.el6.centos.x86_64 It would also be great if this is possible between IPA 3 and 4. Thanks for your help so far! Cheers, Matt 2015-06-29 13:44 GMT+02:00 Petr Spacek pspa...@redhat.com: On 29.6.2015 13:16, Matt . wrote: Hi, The zones are on both servers, just not all records are, this has a reason. One server is maintained by a script, the other one only forwards to it if needed. The idea is that it does a local lookup, when it doesn't find the record locally, it forwards to it's forwarder to see if it has an answer. I thought this was working but isn't and following your table it should. I'm sorry but I do not understand. Could you please give us specific examples? - what data you have in what zones and on what server - what is your forwarding configuration - what is the result you get - what is the expected result Also, please add output from command: $ rpm -q bind-dyndb-ldap bind ipa-server Thanks. What are my options ? We will see once I understand your requirement :-) Petr^2 Spacek 2015-06-29 11:20 GMT+02:00 Petr Spacek pspa...@redhat.com: On 27.6.2015 19:06, Matt . wrote: Hi All, When I add a forwarder with policy to forward first, there is only forwarder and not a fallback to local when the record doesn't exist on the forward server. When I remove the forwardserver, the local lookup works great again. Is this known to 3.0 servers or has it been a bug or am I doing somethin wrong ? Forwarders in FreeIPA behave in the same way as in BIND 9.9 and the behavior you describe seems to be okay. The behavior is summarized in a nice table here: http://www.freeipa.org/page/V4/Forward_zones#Use_Cases In other words, there is no thing like 'look into this zone and look into that zone if the first zone does not contain an answer'. Such behavior would break the very basic principle of DNS - division to independent, self-contained zones. What are you trying to achieve? What is the use-case? Please note that in FreeIPA 4.1 zones with non-empty 'forwarders' attribute were automatically configured as forward zones. The split to pure forward and master zones happened in FreeIPA 4.1. -- Petr^2 Spacek -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] DNS forwarder first does not fallback to local
On 29.6.2015 16:10, Matt . wrote: Hi Petr, Yes I understand why this is not possible. The idea was to have a managed DNS server from scripting and one for other usage by clients who only need to know about the unknown records on Server1, this as it should forward most and only do specific local lookups. Your subdomain solution might be something if I want to go this way. I still do not understand the use case. Why not let scripts to modify records on one single server? -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] UPN suffixes in AD trust
On Mon, Jun 29, 2015 at 03:49:37PM +0200, Jakub Hrozek wrote: On Mon, Jun 29, 2015 at 03:11:57PM +0200, Sumit Bose wrote: On Mon, Jun 29, 2015 at 11:24:00AM +0200, Giorgio Biacchi wrote: On 06/29/2015 10:30 AM, Sumit Bose wrote: On Mon, Jun 29, 2015 at 10:04:04AM +0200, Giorgio Biacchi wrote: On 06/26/2015 08:06 PM, Sumit Bose wrote: On Fri, Jun 26, 2015 at 04:34:05PM +0200, Giorgio Biacchi wrote: On 06/26/2015 02:38 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 07:00:34PM +0200, Giorgio Biacchi wrote: On 06/25/2015 05:44 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 04:29:37PM +0200, Giorgio Biacchi wrote: On 06/25/2015 02:10 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 01:06:22PM +0200, Giorgio Biacchi wrote: On 06/25/2015 12:56 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote: On 06/24/2015 06:45 PM, Sumit Bose wrote: On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote: Hi everybody, I established a bidirectional trust between an IPA server (version 4.1.0 on CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), mydomain.local. Everything is working fine, and I'm able to authenticate and logon on a linux host joined to IPA server using AD credentials (username@mydomain.local). But active directory is configured with two more UPN suffixes (otherdomain.com and sub.otherdomain.com), and I cannot logon with credentials using alternative UPN (example: john@otherdomain.com). How can I make this possible? Another trust (ipa trust-add) with the same AD? Manual configuration of krb5 and/or sssd? Have you tried to login to an IPA client or the server? Please try with an IPA server first. If this does not work it would be nice if you can send the SSSD log files from the IPA server which are generated during the logon attempt. Please call 'sss_cache -E' before to invalidate all cached entries so that the logs will contain all needed calls to AD. Using UPN suffixes were added to the AD provider some time ago and the code is available in the IPA provider as well, but I guess no one has actually tried this before. bye, Sumit First of all let me say that i feel like I'm missing some config somewhere.. Changes tried in krb5.conf to support UPN suffixes didn't helped. I can only access the server vi ssh so I've attached the logs for a successful login for account1@mydomain.local and an unsuccessful login for accou...@otherdomain.com done via ssh. Bye and thanks for your help It looks like the request is not properly propagated to sub-domains (the trusted AD domain) but only send to the IPA domain. Would it be possible for you to run a test build of SSSD which might fix this? If yes, which version of SSSD are you currently using? Then I can prepare a test build with the patch on top of this version. bye, Sumit Hi, I'm using sssd 1.12.2 (sssd --version) on CentOS 7.1.1503 and I'm available for any test. Here's the packages version for sssd: sssd-common-1.12.2-58.el7_1.6.x86_64 sssd-krb5-1.12.2-58.el7_1.6.x86_64 python-sssdconfig-1.12.2-58.el7_1.6.noarch sssd-krb5-common-1.12.2-58.el7_1.6.x86_64 sssd-ipa-1.12.2-58.el7_1.6.x86_64 sssd-1.12.2-58.el7_1.6.x86_64 sssd-libwbclient-1.12.2-58.el7_1.6.x86_64 sssd-ad-1.12.2-58.el7_1.6.x86_64 sssd-ldap-1.12.2-58.el7_1.6.x86_64 sssd-common-pac-1.12.2-58.el7_1.6.x86_64 sssd-proxy-1.12.2-58.el7_1.6.x86_64 sssd-client-1.12.2-58.el7_1.6.x86_64 Please try the packages at http://koji.fedoraproject.org/koji/taskinfo?taskID=10210844 . bye, Sumit Hi, I've installed the new RPMs, now if I run on the server: id account1@mydomain.local id accou...@otherdomain.com id accou...@sub.otherdomain.com all the users are found but I'm still unable to log in via ssh with the accounts @otherdomain.com and @sub.otherdomain.com. In attachment the logs for unsuccessful login for user accou...@otherdomain.com. Bother, I forgot to add the fix to the pam responder as well, please try new packages from http://koji.fedoraproject.org/koji/taskinfo?taskID=10212212 . bye, Sumit Hi, I've updated all the packages but still no login. Logs follows. I found another issue in the logs which should be fixed by the build from http://koji.fedoraproject.org/koji/taskinfo?taskID=10217756 . Please send the sssd_pam log file as well it might contain more details about what goes wrong during authentication. bye, Sumit Hi, packages update, sssd and
[Freeipa-users] dirsrv access logs flooded from single connection id
Our dirsrv access logs on our freeipa master server are getting flooded with this: [29/Jun/2015:12:02:09 -0400] conn=215758 op=1355326784 SRCH base=cn=u2,cn=groups,cn=accounts,dc=ccr,dc=buffalo,dc=edu scope=0 filter=(objectClass=*) attrs=objectClass posixgroup cn userPassword gidNumber member ipaNTSecurityIdentifier modifyTimestamp entryusn uid [29/Jun/2015:12:08:08 -0400] conn=215758 op=1356545457 RESULT err=0 tag=101 nentries=0 etime=0 notes=P All from the same conn=215758. Logs get rotated every minute. logconv.pl is showing Searches: 265803(3322.54/sec) (199352.25/min) How can I figure out which ip address this query is coming from? Is there a way to fetch the ip using the connection id? conn=215758? Thanks in advance. --Andrew -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] DNS forwarder first does not fallback to local
Hi, Because it can happen that hostnames are used twice, but one for each network. This sounds a little bit odd, but it has something todo with hostnames that are needed, public names and internal names. But as both networks have their own DNS servers, some records are just not provisioned so need to be added manually to the non-managed server. 2015-06-29 17:11 GMT+02:00 Petr Spacek pspa...@redhat.com: On 29.6.2015 16:10, Matt . wrote: Hi Petr, Yes I understand why this is not possible. The idea was to have a managed DNS server from scripting and one for other usage by clients who only need to know about the unknown records on Server1, this as it should forward most and only do specific local lookups. Your subdomain solution might be something if I want to go this way. I still do not understand the use case. Why not let scripts to modify records on one single server? -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] DNS forwarder first does not fallback to local
On 29.6.2015 18:22, Matt . wrote: Hi, Because it can happen that hostnames are used twice, but one for each network. This sounds a little bit odd, but it has something todo with hostnames that are needed, public names and internal names. But as both networks have their own DNS servers, some records are just not provisioned so need to be added manually to the non-managed server. Okay, so you basically wants 'DNS views'. There is only once advice about that: Do not do that :-) I would highly recommend you to read and follow following articles: http://www.freeipa.org/page/Deployment_Recommendations#DNS http://www.freeipa.org/page/DNS#Internal-only_domains Sure, in already deployed network it is not easy but be assured that getting rid of DNS views/split-brain DNS it will save you a lot of headaches in the long term. I'm sorry for uncomforting answers... Petr Spacek @ Red Hat 2015-06-29 17:11 GMT+02:00 Petr Spacek pspa...@redhat.com: On 29.6.2015 16:10, Matt . wrote: Hi Petr, Yes I understand why this is not possible. The idea was to have a managed DNS server from scripting and one for other usage by clients who only need to know about the unknown records on Server1, this as it should forward most and only do specific local lookups. Your subdomain solution might be something if I want to go this way. I still do not understand the use case. Why not let scripts to modify records on one single server? -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] dirsrv access logs flooded from single connection id
On Mon, Jun 29, 2015 at 12:34:25PM -0400, Andrew E. Bruno wrote: On Mon, Jun 29, 2015 at 10:29:24AM -0600, Rich Megginson wrote: On 06/29/2015 10:13 AM, Andrew E. Bruno wrote: Our dirsrv access logs on our freeipa master server are getting flooded with this: [29/Jun/2015:12:02:09 -0400] conn=215758 op=1355326784 SRCH base=cn=u2,cn=groups,cn=accounts,dc=ccr,dc=buffalo,dc=edu scope=0 filter=(objectClass=*) attrs=objectClass posixgroup cn userPassword gidNumber member ipaNTSecurityIdentifier modifyTimestamp entryusn uid [29/Jun/2015:12:08:08 -0400] conn=215758 op=1356545457 RESULT err=0 tag=101 nentries=0 etime=0 notes=P All from the same conn=215758. Logs get rotated every minute. logconv.pl is showing Searches: 265803(3322.54/sec) (199352.25/min) How can I figure out which ip address this query is coming from? Is there a way to fetch the ip using the connection id? conn=215758? grep conn=215758 fd= /var/log/dirsrv/slapd-INST/access* Unfortunately, if it has been rotated away, you won't be able to get the information from the access log. No luck .. looks like it has been rotated away. Any other thoughts? Is it correct to assume this is all coming from a single host? My thinking is that if I can kill the query coming from the host that it would solve the problem. Found the host using tcpdump. Thanks again for the help, --Andrew -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] dirsrv access logs flooded from single connection id
On 06/29/2015 10:13 AM, Andrew E. Bruno wrote: Our dirsrv access logs on our freeipa master server are getting flooded with this: [29/Jun/2015:12:02:09 -0400] conn=215758 op=1355326784 SRCH base=cn=u2,cn=groups,cn=accounts,dc=ccr,dc=buffalo,dc=edu scope=0 filter=(objectClass=*) attrs=objectClass posixgroup cn userPassword gidNumber member ipaNTSecurityIdentifier modifyTimestamp entryusn uid [29/Jun/2015:12:08:08 -0400] conn=215758 op=1356545457 RESULT err=0 tag=101 nentries=0 etime=0 notes=P All from the same conn=215758. Logs get rotated every minute. logconv.pl is showing Searches: 265803(3322.54/sec) (199352.25/min) How can I figure out which ip address this query is coming from? Is there a way to fetch the ip using the connection id? conn=215758? grep conn=215758 fd= /var/log/dirsrv/slapd-INST/access* Unfortunately, if it has been rotated away, you won't be able to get the information from the access log. Thanks in advance. --Andrew -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] dirsrv access logs flooded from single connection id
On Mon, Jun 29, 2015 at 10:29:24AM -0600, Rich Megginson wrote: On 06/29/2015 10:13 AM, Andrew E. Bruno wrote: Our dirsrv access logs on our freeipa master server are getting flooded with this: [29/Jun/2015:12:02:09 -0400] conn=215758 op=1355326784 SRCH base=cn=u2,cn=groups,cn=accounts,dc=ccr,dc=buffalo,dc=edu scope=0 filter=(objectClass=*) attrs=objectClass posixgroup cn userPassword gidNumber member ipaNTSecurityIdentifier modifyTimestamp entryusn uid [29/Jun/2015:12:08:08 -0400] conn=215758 op=1356545457 RESULT err=0 tag=101 nentries=0 etime=0 notes=P All from the same conn=215758. Logs get rotated every minute. logconv.pl is showing Searches: 265803(3322.54/sec) (199352.25/min) How can I figure out which ip address this query is coming from? Is there a way to fetch the ip using the connection id? conn=215758? grep conn=215758 fd= /var/log/dirsrv/slapd-INST/access* Unfortunately, if it has been rotated away, you won't be able to get the information from the access log. No luck .. looks like it has been rotated away. Any other thoughts? Is it correct to assume this is all coming from a single host? My thinking is that if I can kill the query coming from the host that it would solve the problem. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] DNS forwarder first does not fallback to local
Hi Petr, No problem at all! I can remove/move things easily... but this splitbrain really makes these 2 networks standing on their own, which is what I need. Both are provisioned but not all the same. It gives me the flexibility we need, that's why it's not difficult to move, as it's flexible at the moment. Thanks again for the heads up! Matt 2015-06-29 18:26 GMT+02:00 Petr Spacek pspa...@redhat.com: On 29.6.2015 18:22, Matt . wrote: Hi, Because it can happen that hostnames are used twice, but one for each network. This sounds a little bit odd, but it has something todo with hostnames that are needed, public names and internal names. But as both networks have their own DNS servers, some records are just not provisioned so need to be added manually to the non-managed server. Okay, so you basically wants 'DNS views'. There is only once advice about that: Do not do that :-) I would highly recommend you to read and follow following articles: http://www.freeipa.org/page/Deployment_Recommendations#DNS http://www.freeipa.org/page/DNS#Internal-only_domains Sure, in already deployed network it is not easy but be assured that getting rid of DNS views/split-brain DNS it will save you a lot of headaches in the long term. I'm sorry for uncomforting answers... Petr Spacek @ Red Hat 2015-06-29 17:11 GMT+02:00 Petr Spacek pspa...@redhat.com: On 29.6.2015 16:10, Matt . wrote: Hi Petr, Yes I understand why this is not possible. The idea was to have a managed DNS server from scripting and one for other usage by clients who only need to know about the unknown records on Server1, this as it should forward most and only do specific local lookups. Your subdomain solution might be something if I want to go this way. I still do not understand the use case. Why not let scripts to modify records on one single server? -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Failed to start pki-tomcatd Service
Hello, I have a problem on a replica server running Centos 7.1 and ipa 4.1.0-18.el7.centos.3.x86_64 (last version) Ipa server doesn’t restart correctly (using systemctl restart ipa or reboot the whole server) : # ipactl status Directory Service: STOPPED Directory Service must be running in order to obtain status of other services ipa: INFO: The ipactl command was successful and I have to force the start process : # ipactl start -f 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 Forced start, ignoring pki-tomcatd Service, continuing normal operation Starting ipa-otpd Service ipa: INFO: The ipactl command was successful But, as you see the pki-tomcatd is unable to start. I started looking at /var/log/pki/pki-tomcat/localhost.2015-06-29.log and found this error : Jun 29, 2015 7:33:12 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [caProfileSubmit] in context with path [/ca] threw exception java.io.IOException: CS server is not ready to serve. at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:443) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:536) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at sun.reflect.GeneratedMethodAccessor31.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:536) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:249) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040) at
[Freeipa-users] 3rd party certificate for WebUI only
I setup IPA using the internal CA. I'd like to continue using this CA, however, I'd also like to allow authorized external browser users (who haven't imported our CA) to access the WebUI without receiving a warning. Is it possible to add a 3rd party certificate and CA such that it is only used for the WebUI using the instructions at http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP? Steve -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] username case sensitivity
On Fri, Jun 26, 2015 at 09:12:53PM -0400, Dmitri Pal wrote: On 05/18/2015 06:16 AM, Andy Thompson wrote: -Original Message- From: Jakub Hrozek [mailto:jhro...@redhat.com] Sent: Monday, May 18, 2015 4:07 AM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] username case sensitivity On Sun, May 17, 2015 at 10:26:45PM +, Andy Thompson wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Sunday, May 17, 2015 5:23 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] username case sensitivity On Fri, May 15, 2015 at 09:44:31PM +0200, Lukas Slebodnik wrote: On (15/05/15 17:27), Andy Thompson wrote: Is there a way to enforce case sensitivity for trusted AD users? I am trying to use username for ssh chroots and I can authenticated with any case combination of UsERname but if ssh is set to match on username then the chroot is not enforced and the user is dropped to their usual home directory. I found a case_sensitive option for sssd but it does not seem to have any affect. Running RHEL6.6 clients. IPA domain is by default case sensitive. So You will not change anything if you put case_sensitive = true into domain section of sssd.conf. But SSSD will create subdomains for each AD domain. It is different id_provider therefore different default values are used for subdomains and for AD provider it is case *insensitive* by default. Currently there's no way how to change it for subdomains (AD trusted domains) What are you using for the SSH matching? The way the case insensitiveness is implemented in SSSD is that all usernames are forcibly lowercased on output, so as long as SSH uses the standard NSS calls, you should be good with using the lowecase usernames.. They were initially all in lower case and working when I tested and finalized the setup. I passed the credentials off and they used mixed case and the match stopped working. What is they ? I guess not SSSD but grabbing the data directly from LDAP? The match clauses in the sshd config were set to use lower case names. It is using sssd, just a regular ipa client installation. If I logged in using USERName insetad of username, the match clause did not work. -andy Do we have any follow up on this thread? Have we closed the loop and filed a ticket. I had couple complains of the similar matter during Red Hat Summit. I seems that this is one of the emerging issues for the trust environments. I wonder if it's still an issue with 1.12.x and the Kerberos plugin Sumit wrote. Do we have a way to track these requests? Andy, if you have some test machines, could you give 6.7 a try? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] hesitate to deploy freeipa
On (26/06/15 10:10), Prasun Gera wrote: More importantly, ipa-client-install is just a thin configuration tool. If ipa-client-install is not available on your platform you can configure everything manually and it will work (as long as the client is standard-compliant). I.e. the client side is *in the worst case* (without ipa-client-install) equally hard to setup as for any home-made solution. Yes, on Ubuntu 12.04, the issue is probably more related to the script than the underlying packages, which I upgraded from their respective ppas. The most complete documentation for getting ipa running, ironically, comes from this bug report https://bugs.launchpad.net/ubuntu/+source/freeipa/+bug/1280215 which is marked as won't fix. (This affects 12.04 btw which is lts). On FreeNAS, it has to do with Hiemdal v/s MIT kerberos. https://bugs.pcbsd.org/issues/2147 SSSD on FreeBSD is compiled with MIT kerberos (/usr/local/*) and not with default Heimdal which is in standard paths. LS -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa sudden stop
On 30/06/15 05:17, Umarzuki Mochlis wrote: Every once in a week suddenly IPA service would failed and only realized when zimbra that using authentication with it failed during user log in. So I had to type in below commands one by one each time this happened. systemctl start dirsrv@DOMAIN-COM.service systemctl start krb5kdc.service systemctl start kadmin.service systemctl start ipa_memcached.service systemctl start httpd.service # cat /etc/redhat-release Fedora release 18 (Spherical Cow) # rpm -qa | grep freeipa freeipa-admintools-3.1.0-2.fc18.x86_64 freeipa-server-3.1.0-2.fc18.x86_64 freeipa-client-3.1.0-2.fc18.x86_64 freeipa-server-selinux-3.1.0-2.fc18.x86_64 freeipa-python-3.1.0-2.fc18.x86_64 I was told this this IPA server is a master IPA. I could not find crash log in /var/log/messages other then when I failed to start certain services or service ipa start Any idea where I should exactly be looking in to? Log messages attached. Hello! The issue seems quite annoying. Could you please provide more info? Do you have one freeipa master or more replicas? If not do you experience this issue only on one of them? According to the logs it looks like starting of pki-tomcatd fails and therefore ipactl start fails. Could you run # ipactl start -d and post its output? Also starting individual services is not a good idea as you can forget to start some (you actually did :-) -- David Kupka -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Unfamiliar message and crashes
Hello. What does message NSMMReplicationPlugin - agmt=cn=cloneAgreement1-host1.domain.com-pki-tomcat (host2:389): Unable to acquire replica: the replica instructed us to go into backoff mode. Will retry later. mean? A lot of these message appeared in error dirsrv log yesterday, and several crashes ns-slapd[31026]: segfault at 25 ip 7f7aa499c800 sp 7f7a4b7e14f0 error 4 in libslapd.so.0.0.0[7f7aa4948000+11c000] also noticed... Any thoughts, what to do? WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 ?? ? ? ? ? ??? ?? ???, ??? ??? ??. ? ? ? ??? ??, ??? ?? ? ??? ???-, ? ?. ?? ?? ??? ? ?, ?? ?, ?, ??? ??? ??? ?? ? ??? ??? ? ? ? ?. ?? ??? ? , ??, ??? ??? ?? ? ??? ?? ?? ? ? ? ? ??? ? ? ??. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- 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
