Re: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account

[Jakub Hrozek]

On Wed, Dec 07, 2016 at 06:19:06PM +, James Harrison wrote:
> Hi all,
> 
> I am trying to authenticate an ubuntu Precise (12.06) fully patched system. 
> Its enrolled into a FreeIPA server. The following trace is the output of 
> syslog auth sssd/*.log and full debug (-ddd) from the sshd service.
> 
> I am getting a PAM error at the end of the procedure. Also I cant seem to 
> authenticate against the public ssh key from the id override user.
> 
> I appreciate any help you can send my way.
> 
> Best regards,
> 
> James Harrison
> Below is more information
> 
> 
> root@jamesprecise:~# kinit x_james.harrison@AD.DOMAIN.LOCAL
> Password for x_james.harrison@AD.DOMAIN.LOCAL:
> 
> root@jamesprecise:~# klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: x_james.harrison@AD.DOMAIN.LOCAL
> 
> Valid starting Expires    Service principal
> 07/12/16 17:56:30  08/12/16 03:56:30  krbtgt/AD.DOMAIN.LOCAL@AD.DOMAIN.LOCAL
>     renew until 08/12/16 17:56:23
> 
> root@jamesprecise:~# id x_james.harrison@AD.DOMAIN.LOCAL
> uid=1039812876(x_james.harrison@ad.domain.local) 
> gid=1039812876(x_james.harrison@ad.domain.local) 
> groups=1039812876(x_james.harrison@ad.domain.local)

HBAC denied the login, which is probably related to the supplementary
groups not being resolved. This ancient SSSD version doesn't support
returning supplementary groups unless you log in -- during the login
attempt, the PAC responder should be able to decode the group
memberships from the PAC and store the groups.

So I'd look if the PAC responder is enabled and running and see if the
krb5_child resolves the SIDs during password authentication (or if PAC
responder is contacted during password-less authentication).

> root@pul-lv-ipa-02 ~]# ipa  idoverrideuser-show External_AD_views 
> x_james.harrison@ad.domain.local
>   Anchor to override: x_james.harrison@ad.domain.local
>   User login: x_james.harrison
>   Login shell: /bin/bash
>   SSH public key: ssh-rsa
>   
> B3NzaC1yc2EDAQABAAABAQDK1pj2U7H9olLs1xKmcmZVEBMWpaHjxF2LttsdfqfQxm810qMru/WsvzHqu0m5Ugu0FYsPxRLQrAEB8WPsPoh5Y0q5qYPgm5aDOZZEXfCPyuRwdQ+XLfQJ3gnGjW4r/XLEiNVpO9eKsFs0ifspNAJ1n7h40rlHlOIqV/z8Omg6XnFBh9dIfiXtpYDOxe+512RpjtHE98s+NfIpUTT7MGNLHB5o/DqFXEJPH7Pp1bKwxWNvfCb5a71vcE695dQ31QYVYwpSwFmFogewgpV/OCb+S4SUdUq1xg0fmkhYr3d4UXFr91MDimyOBWk9Aai7NkOHPszmHJp
>   JamesHarrison

Overrides are not supported with this version.

> 
> 
> Here are the software versions:
> 
> root@jamesprecise:# dpkg -l | grep -i freeipa
> ii  freeipa-client 3.3.4-0ubuntu3.1~precise0.1
>     FreeIPA centralized identity framework -- client
> ii  libipa-hbac0   1.11.5-1ubuntu3~precise1   
>     FreeIPA HBAC Evaluator library
> ii  python-freeipa 3.3.4-0ubuntu3.1~precise0.1
>     FreeIPA centralized identity framework -- python modules
> ii  python-libipa-hbac 1.11.5-1ubuntu3~precise1   
>     Python bindings for the FreeIPA HBAC Evaluator library
> 
> root@jamesprecise:# dpkg -l | grep -i openssh-server
> ii  openssh-server 1:5.9p1-5ubuntu1.10
>     secure shell (SSH) server, for secure access from remote machines
> 
> 
> root@jamesprecise:/var/log# dpkg -l | grep -i sssd
> ii  libsss-idmap0  1.11.5-1ubuntu3~precise1   
>     ID mapping library for SSSD
> ii  sssd   1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- metapackage
> ii  sssd-ad    1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- Active Directory back end
> ii  sssd-ad-common 1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- PAC responder
> ii  sssd-common    1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- common files
> ii  sssd-ipa   1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- IPA back end
> ii  sssd-krb5  1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- Kerberos back end
> ii  sssd-krb5-common   1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- Kerberos helpers
> ii  sssd-ldap  1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- LDAP back end
> ii  sssd-proxy 1.11.5-1ubuntu3~precise1   
>     System Security Services Daemon -- proxy back end
> ii  sudo   1.8.9p5-1ubuntu1.1~sssd1   
>     Provide limited super user privileges to specific users

All is all, I would suggest to upgrade to something more recent..

-- 
Manage your subscription for the Freeipa-users mailing list:

[Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account

[James Harrison]

Hi all,

I am trying to authenticate an ubuntu Precise (12.06) fully patched system. Its 
enrolled into a FreeIPA server. The following trace is the output of syslog 
auth sssd/*.log and full debug (-ddd) from the sshd service.

I am getting a PAM error at the end of the procedure. Also I cant seem to 
authenticate against the public ssh key from the id override user.

I appreciate any help you can send my way.

Best regards,

James Harrison
Below is more information


root@jamesprecise:~# kinit x_james.harrison@AD.DOMAIN.LOCAL
Password for x_james.harrison@AD.DOMAIN.LOCAL:

root@jamesprecise:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: x_james.harrison@AD.DOMAIN.LOCAL

Valid starting Expires    Service principal
07/12/16 17:56:30  08/12/16 03:56:30  krbtgt/AD.DOMAIN.LOCAL@AD.DOMAIN.LOCAL
    renew until 08/12/16 17:56:23

root@jamesprecise:~# id x_james.harrison@AD.DOMAIN.LOCAL
uid=1039812876(x_james.harrison@ad.domain.local) 
gid=1039812876(x_james.harrison@ad.domain.local) 
groups=1039812876(x_james.harrison@ad.domain.local)

root@pul-lv-ipa-02 ~]# ipa  idoverrideuser-show External_AD_views 
x_james.harrison@ad.domain.local
  Anchor to override: x_james.harrison@ad.domain.local
  User login: x_james.harrison
  Login shell: /bin/bash
  SSH public key: ssh-rsa
  
B3NzaC1yc2EDAQABAAABAQDK1pj2U7H9olLs1xKmcmZVEBMWpaHjxF2LttsdfqfQxm810qMru/WsvzHqu0m5Ugu0FYsPxRLQrAEB8WPsPoh5Y0q5qYPgm5aDOZZEXfCPyuRwdQ+XLfQJ3gnGjW4r/XLEiNVpO9eKsFs0ifspNAJ1n7h40rlHlOIqV/z8Omg6XnFBh9dIfiXtpYDOxe+512RpjtHE98s+NfIpUTT7MGNLHB5o/DqFXEJPH7Pp1bKwxWNvfCb5a71vcE695dQ31QYVYwpSwFmFogewgpV/OCb+S4SUdUq1xg0fmkhYr3d4UXFr91MDimyOBWk9Aai7NkOHPszmHJp
  JamesHarrison


Here are the software versions:

root@jamesprecise:# dpkg -l | grep -i freeipa
ii  freeipa-client 3.3.4-0ubuntu3.1~precise0.1  
  FreeIPA centralized identity framework -- client
ii  libipa-hbac0   1.11.5-1ubuntu3~precise1 
  FreeIPA HBAC Evaluator library
ii  python-freeipa 3.3.4-0ubuntu3.1~precise0.1  
  FreeIPA centralized identity framework -- python modules
ii  python-libipa-hbac 1.11.5-1ubuntu3~precise1 
  Python bindings for the FreeIPA HBAC Evaluator library

root@jamesprecise:# dpkg -l | grep -i openssh-server
ii  openssh-server 1:5.9p1-5ubuntu1.10  
  secure shell (SSH) server, for secure access from remote machines


root@jamesprecise:/var/log# dpkg -l | grep -i sssd
ii  libsss-idmap0  1.11.5-1ubuntu3~precise1 
  ID mapping library for SSSD
ii  sssd   1.11.5-1ubuntu3~precise1 
  System Security Services Daemon -- metapackage
ii  sssd-ad    1.11.5-1ubuntu3~precise1 
  System Security Services Daemon -- Active Directory back end
ii  sssd-ad-common 1.11.5-1ubuntu3~precise1 
  System Security Services Daemon -- PAC responder
ii  sssd-common    1.11.5-1ubuntu3~precise1 
  System Security Services Daemon -- common files
ii  sssd-ipa   1.11.5-1ubuntu3~precise1 
  System Security Services Daemon -- IPA back end
ii  sssd-krb5  1.11.5-1ubuntu3~precise1 
  System Security Services Daemon -- Kerberos back end
ii  sssd-krb5-common   1.11.5-1ubuntu3~precise1 
  System Security Services Daemon -- Kerberos helpers
ii  sssd-ldap  1.11.5-1ubuntu3~precise1 
  System Security Services Daemon -- LDAP back end
ii  sssd-proxy 1.11.5-1ubuntu3~precise1 
  System Security Services Daemon -- proxy back end
ii  sudo   1.8.9p5-1ubuntu1.1~sssd1 
  Provide limited super user privileges to specific users

Ubuntu PPAs:
root@jamesprecise:~# ls -l /etc/apt/sources.list.d/
total 16
-rw-r--r-- 1 root root 65 Dec  7 08:48 freeipa-ppa-precise.list
-rw-r--r-- 1 root root 61 Dec  7 08:48 ppa_freeipa_ppa_precise.list
-rw-r--r-- 1 root root 62 Dec  7 08:48 ppa_sssd_updates_precise.list
-rw-r--r-- 1 root root 66 Dec  7 08:48 sssd-updates-precise.list

cat /etc/pam.d/common-session
session    [default=1]    pam_permit.so
session    requisite    pam_deny.so
session    required    pam_permit.so
session optional    pam_umask.so
session    required    pam_mkhomedir.so umask=0022 
skel=/etc/skel
session    required    pam_unix.so
session    optional    pam_sss.so
session    [success=ok default=ignore]    pam_ldap.so minimum_uid=1000
root@jamesprecise:~#

root@jamesprecise:~# cat /etc/pam.d/common-auth
auth    [success=3 default=ignore]    pam_unix.so nullok_secure
auth    [success=2 

Re: [Freeipa-users] Certificates missing

[Jochen Hein]

Jochen Hein  writes:

> I'm unsure if it is related to ticket 6397...

It seems it was. CentOS 7.3/CR had new packages today and both problems
are fixed for me. Thanks!

Jochen

-- 
The only problem with troubleshooting is that the trouble shoots back.

-- 
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] Certificates missing (was: Re: Services missing in web-ui)

[Jochen Hein]

I'm unsure if it is related to ticket 6397...

Pavel Vomacka  writes:

> it is caused by missing canonical name on services which were created
> in older versions of FreeIPA. Fixed ticket here:
> https://fedorahosted.org/freeipa/ticket/6397 .

Symptom:
In the web UI on 4.3 on Fedora 24 I have 43 certificates, 
on the 4.4 replica on CentOS 7.3(CR) I see only 16 certificates.

System history:
Old master is 4.3, upgraded from 4.2. Both replicas are new
with CentOS. Yesterday I moved the CA from 4.3 to a 4.4 IDM.
After that I created a certificate for a new service principal.
I can see the new certificate I can see in both web UIs.

Analysis:
Looking at the ipa cli tool, cert-find is consistent with the web UI:

4.3:
-
Number of entries returned 43
-

4.4:
--
Anzahl der zurückgegebenen Einträge 16
--

Looking at both LDAP servers, I do find the same number of entries.
I looked at ou=ca,ou=requests,o=ipaca.
So replications seems to work fine (and ipa-replica-manage confirms it).

Right now I have two guesses:

My system is hit with https://fedorahosted.org/freeipa/ticket/6397
I do have some certificates for services, and some for hosts.
So my hope would be that updated packages might fix it.
But analysing the certificates in the web UI is futil:

- On CentOS(freeipa 4.4) the certificate list in web UI only displays
  serial number, subject, issuing CA(empty), and status(empty).
  That's not quite correct. In the certificate list I can not select
  a certificate and can get more details...

  4.3 has only serial number, subject, and status, but with valid values.
  I can click on the serial number and get more details about the
  certficate.

  Since I can't see all services in 4.4 due to ticket 6397
  more analysis is hard.

- using "ipa cert-show --all" on 4.4 has more infos about the
  certificates, but on 4.3 it doesn't show more info. 

So right now I'm somewhat stuck how to proceed further.  4.3 seems
to be ok, so I hesitate to update the fredora system to 25 (with IPA 4.4).

I didn't find the files from #6397 to manually apply the patch,
so I'm more or less stuck.  Any ideas?

Jochen

-- 
The only problem with troubleshooting is that the trouble shoots back.

-- 
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] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts

[Chris Dagdigian]

Our problem is largely solved but we are using some "do not use in 
production!" settings so I wanted to both recap our solution and ask 
some follow up questions.


Our setup:
-
 - FreeIPA 4.2 running on CentOS-7 in AWS VPC
 - Edge-case split DNS setup. Our cloud clients are "company-aws.org" 
while IPA is "company-ipa.org" realm/domain
 - Massive need to authenticate against AD Forest COMPANY.COM which 
includes a ton of child domains (NAFTA.COMPANY.COM, etc.)


Problem
---
- AD users are recognized and can be enumerated as long as I use 
usern...@nafta.company.com

- "su - " works as root to become the AD user
- All methods that require password check (SSH login mainly) failed

The breakthrough was the advice from Sumit to add the 
ldap_user_principal and subdomain_inherit settings. The core problem on 
our end seemed to be issues with having the AD user UPN get sorted out. 
Something was failing when u...@nafta.company.com was shortened to 
u...@company.com and we saw the recurring error about " ... UPN is quite 
different ... "  in the sssd domain logs.



Solution (Server Side)
-
In /etc/sssd/sssd.conf:
 ldap_user_principal = nosuchattr
 subdomain_inherit = ldap_user_principal
 krb5_validate = false


Solution (IPA client side)

In /etc/sssd/sssd.conf:
 krb5_validate = false


I think the main problem is obvious. Even Sumit was clear to state that 
"krb5_validate = false" should be used for testing only.


However if we remove that setting password checking breaks.


So the basic "what next question" for the experts is:


1. Do we chase down whatever config error we have that requires 
krb5_validate=false ?
2. Or do we assume that that problem is related to the UPN problem and 
related AD-across-child-domains that appear to be resolved in IPA-4.4? I 
keep getting the sense that massive AD-related things have been improved 
recently in 4.3 and 4.4


My gut feeling is that it is our odd UPN issue that is breaking things 
so rather than bend over backwards to try to figure out why 
krb5_validate=false on our IPA-4.2 setup I'm sort of leaning towards 
trying to go for an upgrade to IPA-4.4 and hope that whatever issue 
forced us to disable krb5_validate is resolved in the new updates.


Am I being stupid (again?)  Obviously the krb5_validate=false setting 
needs to be fixed. Just not sure if I should work on a fix within 4.2 or 
move to 4.4 and see if it gets resolved as part of other changes.



Regards,
Chris






--
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] Let's Encrypt Install: Made a bit of install progress, next error

[Joseph Flynn]

Man, I feel silly.  I thought i had that set earlier by using the network
setup during the install.  Maybe different distributions handle that
differently.  I have it corrected via your suggestion Martin Thanks you!!

To the next stage...  Seems like partial success. Is there another step
needed to install the cert that appears to have been created in my home
directory?

[image: Inline image 1]
IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /home/jjflynn22/0001_chain.pem. Your cert will expire on
   2017-03-07. To obtain a new or tweaked version of this certificate
   in the future, simply run certbot again. To non-interactively renew
   *all* of your certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:https://eff.org/donate-le

certutil:  unable to open "/root/ipa-le/_cert.pem" for reading (-5950,
2).








On Wed, Dec 7, 2016 at 10:56 AM, Martin Basti  wrote:

> Please make sure you use `hostnamectl set-hostname FQDN` to set all
> hostnames on system (static, tentaive, current )
> Martin
>
> On 07.12.2016 16:52, Joseph Flynn wrote:
>
> Damn, I thought I already fixed that but didn't.  Hold while I rerun...
> I bet that was it.
>
> On Wed, Dec 7, 2016 at 10:50 AM, Martin Basti  wrote:
>
>> What does `hostname` command return?
>>
>> On 07.12.2016 16:37, Joseph Flynn wrote:
>>
>> Sorry, I wasn't clear in my earlier subject line.  This is related to the
>> Lets Encrypt installation.
>>
>> I tried to pull some more relevant items from the log below.  I don't
>> actually see all of the elements of my FQDN (ipa-a.kkgpitt.org) only
>> references to the host (ipa-a) in the log, but am not sure what a good log
>> should include.
>>
>> Thanks for any assistance,
>> Joe
>>
>>
>> On Tue, Dec 6, 2016 at 4:15 PM, Joseph Flynn  wrote:
>>
>>> Volunteers,
>>>
>>> I moved over to a Fedora VM which was way more difficult than it should
>>> be.  All kinds of problems with Guest Additions and I ended up having to
>>> run server mode with no GUI.  Now I run an Ubuntu VM from which I ssh into
>>> my Fedora VM.  Anyway...
>>>
>>> The install made it a further step than before.  I get a quick blue
>>> screen pop up at the end then an error saying:
>>> [image: Inline image 1]
>>>
>>> An unexpected error occurred:
 The request message was malformed :: DNS name does not have enough
 labels
 Please see the logfiles in /var/log/letsencrypt for more details.

>>>
>>> When I run the cert checker util I get this
>>> https://www.sslshopper.com/ssl-checker.html#hostname=ipa-a.kkgpitt.org
>>>
>>> Full log below.
>>>
>>> Any suggestions?  Is it not pulling my proper hostname?
>>>
>>> Thanks,
>>> Joe
>>>
>>>
>>>
>>>
>>>
>>> [jjflynn22@ipa-a ~]$ cat /etc/hosts
>>> 192.168.1.211 ipa-a.kkgpitt.org ipa-a
>>> 127.0.0.1   localhost localhost.localdomain localhost4
>>> localhost4.localdomain4
>>> ::1 localhost localhost.localdomain localhost6
>>> localhost6.localdomain6
>>>
>>>
>>>
>>>
>>> [jjflynn22@ipa-a ~]$ sudo cat /var/log/letsencrypt/letsencrypt.log
>>> [sudo] password for jjflynn22:
>>> 2016-12-06 20:57:43,982:DEBUG:certbot.main:Root logging level set at 20
>>> 2016-12-06 20:57:43,983:INFO:certbot.main:Saving debug log to
>>> /var/log/letsencrypt/letsencrypt.log
>>> 2016-12-06 20:57:43,991:DEBUG:certbot.main:certbot version: 0.9.3
>>> 2016-12-06 20:57:43,991:DEBUG:certbot.main:Arguments: ['--standalone',
>>> '--csr', '/root/ipa-le/httpd-csr.der', '--email', 'xx...@gmail.com',
>>> '--agree-tos']
>>> 2016-12-06 20:57:43,992:DEBUG:certbot.main:Discovered plugins:
>>> PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#nu
>>> ll,PluginEntryPoint#manual,PluginEntryPoint#standalone)
>>> 2016-12-06 20:57:43,995:DEBUG:certbot.plugins.selection:Requested
>>> authenticator standalone and installer None
>>> 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Single
>>> candidate plugin: * standalone
>>> Description: Spin up a temporary webserver
>>> Interfaces: IAuthenticator, IPlugin
>>> Entry point: standalone = certbot.plugins.standalone:Authenticator
>>> Initialized: >> 0x7fc3dc6fccd0>
>>> Prep: True
>>> 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Selected
>>> authenticator >> 0x7fc3dc6fccd0> and installer None
>>> 2016-12-06 20:57:44,115:DEBUG:certbot.main:Picked account:
>>> 
>>> 2016-12-06 20:57:44,116:DEBUG:root:Sending GET request to
>>> https://acme-v01.api.letsencrypt.org/directory. args: (), kwargs: {}
>>> 2016-12-06 
>>> 20:57:44,119:INFO:requests.packages.urllib3.connectionpool:Starting
>>> new HTTPS connection (1): acme-v01.api.letsencrypt.org
>>> 2016-12-06 20:57:44,500:DEBUG:requests.packages.urllib3.connectionpool:"GET
>>> /directory HTTP/1.1" 200 280
>>> 2016-12-06 

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Petr Spacek]

On 7.12.2016 14:57, Brian Candler wrote:
> On 07/12/2016 08:58, freeIPA users list wrote:
>> On ke, 07 joulu 2016, List dedicated to discussions about use, configuration
>> and deployment of the IPA server. wrote:
>>> I know the Quick Start Guide and Deployment Recommendations cover this in
>>> depth, but there are still some ambiguities.
>>>
>>> I'm trying to figure out if a company like us, lautus.net should use a DNS
>>> subdomain like ipa.lautus.net for the IPA domain, or not.
>> It is really depending on your deployment details.
>>
>> If you already have some other Kerberized environment in place and you
>> are not going to replace it by FreeIPA, then you need to make sure that
>> new FreeIPA deployment would not conflict with the existing one.
> Or if you think there's a chance you might want to add another Kerberized
> environment later (e.g. "ad.lautus.net")
> 
>>
>>> should continue to be hosted by DNS servers elsewhere that delegate say,
>>> ipa.lautus.net to FreeIPA.
> The question of whether you host ipa.lautus.net DNS (or indeed lautus.net DNS)
> in FreeIPA is a different issue.
> 
> If you're happy with your existing DNS infrastructure, then you can either
> delegate ipa.lautus.net to your FreeIPA servers (with NS records); or run
> FreeIPA without DNS, and simply import the ipa.lautus.net SRV records directly
> into the lautus.net domain.
> 
> Having FreeIPA host the ipa.lautus.net domain means these SRV records are
> populated automatically, but it's not really that hard to add them to an
> existing DNS service.
> 
> OTOH, if you *don't* already have a good authoritative internal DNS service
> with a UI that you like, then you might want to use FreeIPA for this anyway.
> You can easily create extra zones in FreeIPA.
> 
> I would be a bit wary about putting FreeIPA servers out on the public Internet
> though. For one thing, the default config is an open resolver (which you can
> tighten easily enough). I also have a deep distrust of Java, but maybe that's
> just me.

Speaking of DNS, it is just BIND. Configure it accordingly and you should be 
find.

Please note that FreeIPA DNS is not intended as general-purpose DNS:
http://www.freeipa.org/page/DNS#Initial_Considerations

It is tailored for FreeIPA use-cases and might lack special features.


>>> But on the other hand the same doc is full of examples where a Kerberos
>>> realm like EXAMPLE.COM (instead of IPA.EXAMPLE.COM) is used, i.e example
>>> 2.2. of secion 2.3.4. But the same guide also says that the Kerberos realm
>>> should be the same as the ipa DNS domain, just uppercased. So example 2.2.
>>> implies that example.com is running their DNS domain on FreeIPA, for
>>> everything, not just for IPA SRV and TXT entries.
> The Kerberos realm always has a corresponding DNS domain, so realm
> IPA.LAUTUS.NET has a corresponding DNS domain "ipa.lautus.net".
> 
> But with FreeIPA you can still manage hosts called foo.lautus.net or
> bar.int.lautus.net. At worst you'd have some extra [domain_realm] mappings in
> krb5.conf

Yes. Ideally you will be able to add _kerberos TXT records to relevant DNS
domains so explicit mapping will not be necessary.

I will have a look how we can clarify the guide to make this less confusing...

> 
> (Aside: Active Directory is much more fussy, and basically doesn't work if the
> hosts don't have hostnames within the same DNS domain as their kerberos realm
> - and indeed have reverse DNS as well as forward)
> 
>>
>>> And when ipa-client-install is run on somehost.lautus.net, it also defaults
>>> to LAUTUS.NET for Kerberos domain, as if the default expectation is that
>>> your toplevel company DNS name would be your kerberos domain.
> But you can override that.
> 
>>
>>
>>> And when I install a trial IPA server on host ipa-server-1.lautus.net using
>>> "ipa-server-install --setup-dns --realm IPA.LAUTUS.NET --domain
>>> ipa.lautus.net --forwarder=8.8.8.8", and then look at the DNS Zones  in the
>>> Web UI, I see not only ipa.lautus.net, but also lautus, with record "@ NS
>>> ipa-server-1.lautus.net". In other words the IPA server defaults to
>>> thinking it owns the domain above ipa.lautus.net too. Which goes against
>>> 2.3.1 above.
> Interesting. What does "ipa dnszone-find --pkey-only" show?
> 
> It seems like it's created an authoritative zone both for the server's own
> domain (lautus.net if the server is xxx.lautus.net) as well as the realm's
> domain (ipa.lautus.net)
> 
> I don't know why it's doing that. Now I've checked with another system here:
> the hostname is "ipa-1.int.example.com" and the realm is "ipa.example.com",
> and you're right, it is authoritative for both:
> 
>   Zone name: int.example.com.
>   Zone name: ipa.example.com.
> 
> This isn't what I wanted. The int.example.com domain is hosted externally and
> I didn't want to override it. Right now it's hiding all names in
> int.example.com that it doesn't know about.
> 
> I would expect that it's possible to remove this zone, but I'd need to 

Re: [Freeipa-users] Let's Encrypt Install: Made a bit of install progress, next error

[Martin Basti]

Please make sure you use `hostnamectl set-hostname FQDN` to set all 
hostnames on system (static, tentaive, current )


Martin

On 07.12.2016 16:52, Joseph Flynn wrote:
Damn, I thought I already fixed that but didn't. Hold while I 
rerun...   I bet that was it.


On Wed, Dec 7, 2016 at 10:50 AM, Martin Basti > wrote:


What does `hostname` command return?


On 07.12.2016 16:37, Joseph Flynn wrote:

Sorry, I wasn't clear in my earlier subject line.  This is
related to the Lets Encrypt installation.

I tried to pull some more relevant items from the log below.  I
don't actually see all of the elements of my FQDN
(ipa-a.kkgpitt.org ) only references to
the host (ipa-a) in the log, but am not sure what a good log
should include.

Thanks for any assistance,
Joe


On Tue, Dec 6, 2016 at 4:15 PM, Joseph Flynn > wrote:

Volunteers,

I moved over to a Fedora VM which was way more difficult than
it should be.  All kinds of problems with Guest Additions and
I ended up having to run server mode with no GUI.  Now I run
an Ubuntu VM from which I ssh into my Fedora VM.  Anyway...

The install made it a further step than before.  I get a
quick blue screen pop up at the end then an error saying:
Inline image 1

An unexpected error occurred:
The request message was malformed :: DNS name does not
have enough labels
Please see the logfiles in /var/log/letsencrypt for more
details.


When I run the cert checker util I get this
https://www.sslshopper.com/ssl-checker.html#hostname=ipa-a.kkgpitt.org



Full log below.

Any suggestions?  Is it not pulling my proper hostname?

Thanks,
Joe





[jjflynn22@ipa-a ~]$ cat /etc/hosts
192.168.1.211ipa-a.kkgpitt.org  ipa-a
127.0.0.1   localhost localhost.localdomain localhost4
localhost4.localdomain4
::1 localhost localhost.localdomain localhost6
localhost6.localdomain6




[jjflynn22@ipa-a ~]$ sudo cat
/var/log/letsencrypt/letsencrypt.log
[sudo] password for jjflynn22:
2016-12-06 20:57:43,982:DEBUG:certbot.main:Root logging level
set at 20
2016-12-06 20:57:43,983:INFO:certbot.main:Saving debug log to
/var/log/letsencrypt/letsencrypt.log
2016-12-06 20:57:43,991:DEBUG:certbot.main:certbot version: 0.9.3
2016-12-06 20:57:43,991:DEBUG:certbot.main:Arguments:
['--standalone', '--csr', '/root/ipa-le/httpd-csr.der',
'--email', 'xx...@gmail.com ',
'--agree-tos']
2016-12-06 20:57:43,992:DEBUG:certbot.main:Discovered
plugins:

PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone)
2016-12-06
20:57:43,995:DEBUG:certbot.plugins.selection:Requested
authenticator standalone and installer None
2016-12-06
20:57:44,019:DEBUG:certbot.plugins.selection:Single candidate
plugin: * standalone
Description: Spin up a temporary webserver
Interfaces: IAuthenticator, IPlugin
Entry point: standalone =
certbot.plugins.standalone:Authenticator
Initialized: http://certbot.plugins.standalone.Au>thenticator object at
0x7fc3dc6fccd0>
Prep: True
2016-12-06
20:57:44,019:DEBUG:certbot.plugins.selection:Selected
authenticator http://certbot.plugins.standalone.Au>thenticator object at
0x7fc3dc6fccd0> and installer None
2016-12-06 20:57:44,115:DEBUG:certbot.main:Picked account:

2016-12-06 20:57:44,116:DEBUG:root:Sending GET request to
https://acme-v01.api.letsencrypt.org/directory
. args: (),
kwargs: {}
2016-12-06
20:57:44,119:INFO:requests.packages.urllib3.connectionpool:Starting
new HTTPS connection (1): acme-v01.api.letsencrypt.org

2016-12-06 20:57:44,500:DEBUG:requests.pa
ckages.urllib3.connectionpool:"GET
/directory HTTP/1.1" 200 280
2016-12-06 20:57:44,506:DEBUG:root:Received .
Headers: {'Content-Length': '280', 'Expires': 'Tue, 06 Dec
2016 20:57:46 GMT', 'Boulder-Request-Id':
'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0',
'Strict-Transport-Security': 'max-age=604800', 'Server':
'nginx', 'Connection': 'keep-alive', 'Pragma': 'no-cache',
'Cache-Control': 'max-age=0, no-cache, 

Re: [Freeipa-users] Let's Encrypt Install: Made a bit of install progress, next error

[Joseph Flynn]

Damn, I thought I already fixed that but didn't.  Hold while I rerun...   I
bet that was it.

On Wed, Dec 7, 2016 at 10:50 AM, Martin Basti  wrote:

> What does `hostname` command return?
>
> On 07.12.2016 16:37, Joseph Flynn wrote:
>
> Sorry, I wasn't clear in my earlier subject line.  This is related to the
> Lets Encrypt installation.
>
> I tried to pull some more relevant items from the log below.  I don't
> actually see all of the elements of my FQDN (ipa-a.kkgpitt.org) only
> references to the host (ipa-a) in the log, but am not sure what a good log
> should include.
>
> Thanks for any assistance,
> Joe
>
>
> On Tue, Dec 6, 2016 at 4:15 PM, Joseph Flynn  wrote:
>
>> Volunteers,
>>
>> I moved over to a Fedora VM which was way more difficult than it should
>> be.  All kinds of problems with Guest Additions and I ended up having to
>> run server mode with no GUI.  Now I run an Ubuntu VM from which I ssh into
>> my Fedora VM.  Anyway...
>>
>> The install made it a further step than before.  I get a quick blue
>> screen pop up at the end then an error saying:
>> [image: Inline image 1]
>>
>> An unexpected error occurred:
>>> The request message was malformed :: DNS name does not have enough labels
>>> Please see the logfiles in /var/log/letsencrypt for more details.
>>>
>>
>> When I run the cert checker util I get this
>> https://www.sslshopper.com/ssl-checker.html#hostname=ipa-a.kkgpitt.org
>>
>> Full log below.
>>
>> Any suggestions?  Is it not pulling my proper hostname?
>>
>> Thanks,
>> Joe
>>
>>
>>
>>
>>
>> [jjflynn22@ipa-a ~]$ cat /etc/hosts
>> 192.168.1.211 ipa-a.kkgpitt.org ipa-a
>> 127.0.0.1   localhost localhost.localdomain localhost4
>> localhost4.localdomain4
>> ::1 localhost localhost.localdomain localhost6
>> localhost6.localdomain6
>>
>>
>>
>>
>> [jjflynn22@ipa-a ~]$ sudo cat /var/log/letsencrypt/letsencrypt.log
>> [sudo] password for jjflynn22:
>> 2016-12-06 20:57:43,982:DEBUG:certbot.main:Root logging level set at 20
>> 2016-12-06 20:57:43,983:INFO:certbot.main:Saving debug log to
>> /var/log/letsencrypt/letsencrypt.log
>> 2016-12-06 20:57:43,991:DEBUG:certbot.main:certbot version: 0.9.3
>> 2016-12-06 20:57:43,991:DEBUG:certbot.main:Arguments: ['--standalone',
>> '--csr', '/root/ipa-le/httpd-csr.der', '--email', 'xx...@gmail.com',
>> '--agree-tos']
>> 2016-12-06 20:57:43,992:DEBUG:certbot.main:Discovered plugins:
>> PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#
>> null,PluginEntryPoint#manual,PluginEntryPoint#standalone)
>> 2016-12-06 20:57:43,995:DEBUG:certbot.plugins.selection:Requested
>> authenticator standalone and installer None
>> 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Single candidate
>> plugin: * standalone
>> Description: Spin up a temporary webserver
>> Interfaces: IAuthenticator, IPlugin
>> Entry point: standalone = certbot.plugins.standalone:Authenticator
>> Initialized: > 0x7fc3dc6fccd0>
>> Prep: True
>> 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Selected
>> authenticator > 0x7fc3dc6fccd0> and installer None
>> 2016-12-06 20:57:44,115:DEBUG:certbot.main:Picked account:
>> 
>> 2016-12-06 20:57:44,116:DEBUG:root:Sending GET request to
>> https://acme-v01.api.letsencrypt.org/directory. args: (), kwargs: {}
>> 2016-12-06 
>> 20:57:44,119:INFO:requests.packages.urllib3.connectionpool:Starting
>> new HTTPS connection (1): acme-v01.api.letsencrypt.org
>> 2016-12-06 20:57:44,500:DEBUG:requests.packages.urllib3.connectionpool:"GET
>> /directory HTTP/1.1" 200 280
>> 2016-12-06 20:57:44,506:DEBUG:root:Received . Headers:
>> {'Content-Length': '280', 'Expires': 'Tue, 06 Dec 2016 20:57:46 GMT',
>> 'Boulder-Request-Id': 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0',
>> 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx',
>> 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control':
>> 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT',
>> 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json',
>> 'Replay-Nonce': 'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}. Content:
>> '{\n  "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",\n
>> "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",\n
>> "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",\n
>> "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert
>> "\n}'
>> 2016-12-06 20:57:44,506:DEBUG:acme.client:Received response > [200]> (headers: {'Content-Length': '280', 'Expires': 'Tue, 06 Dec 2016
>> 20:57:46 GMT', 'Boulder-Request-Id': 
>> 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0',
>> 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx',
>> 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control':
>> 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT',
>> 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json',
>> 'Replay-Nonce': 

Re: [Freeipa-users] Let's Encrypt Install: Made a bit of install progress, next error

[Martin Basti]

What does `hostname` command return?


On 07.12.2016 16:37, Joseph Flynn wrote:
Sorry, I wasn't clear in my earlier subject line.  This is related to 
the Lets Encrypt installation.


I tried to pull some more relevant items from the log below.  I don't 
actually see all of the elements of my FQDN (ipa-a.kkgpitt.org 
) only references to the host (ipa-a) in the 
log, but am not sure what a good log should include.


Thanks for any assistance,
Joe


On Tue, Dec 6, 2016 at 4:15 PM, Joseph Flynn > wrote:


Volunteers,

I moved over to a Fedora VM which was way more difficult than it
should be.  All kinds of problems with Guest Additions and I ended
up having to run server mode with no GUI.  Now I run an Ubuntu VM
from which I ssh into my Fedora VM. Anyway...

The install made it a further step than before.  I get a quick
blue screen pop up at the end then an error saying:
Inline image 1

An unexpected error occurred:
The request message was malformed :: DNS name does not have
enough labels
Please see the logfiles in /var/log/letsencrypt for more details.


When I run the cert checker util I get this
https://www.sslshopper.com/ssl-checker.html#hostname=ipa-a.kkgpitt.org



Full log below.

Any suggestions?  Is it not pulling my proper hostname?

Thanks,
Joe





[jjflynn22@ipa-a ~]$ cat /etc/hosts
192.168.1.211ipa-a.kkgpitt.org  ipa-a
127.0.0.1   localhost localhost.localdomain localhost4
localhost4.localdomain4
::1 localhost localhost.localdomain localhost6
localhost6.localdomain6




[jjflynn22@ipa-a ~]$ sudo cat /var/log/letsencrypt/letsencrypt.log
[sudo] password for jjflynn22:
2016-12-06 20:57:43,982:DEBUG:certbot.main:Root logging level set
at 20
2016-12-06 20:57:43,983:INFO:certbot.main:Saving debug log to
/var/log/letsencrypt/letsencrypt.log
2016-12-06 20:57:43,991:DEBUG:certbot.main:certbot version: 0.9.3
2016-12-06 20:57:43,991:DEBUG:certbot.main:Arguments:
['--standalone', '--csr', '/root/ipa-le/httpd-csr.der', '--email',
'xx...@gmail.com ', '--agree-tos']
2016-12-06 20:57:43,992:DEBUG:certbot.main:Discovered plugins:

PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone)
2016-12-06 20:57:43,995:DEBUG:certbot.plugins.selection:Requested
authenticator standalone and installer None
2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Single
candidate plugin: * standalone
Description: Spin up a temporary webserver
Interfaces: IAuthenticator, IPlugin
Entry point: standalone = certbot.plugins.standalone:Authenticator
Initialized: 
Prep: True
2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Selected
authenticator  and installer None
2016-12-06 20:57:44,115:DEBUG:certbot.main:Picked account:

2016-12-06 20:57:44,116:DEBUG:root:Sending GET request to
https://acme-v01.api.letsencrypt.org/directory
. args: (), kwargs: {}
2016-12-06
20:57:44,119:INFO:requests.packages.urllib3.connectionpool:Starting
new HTTPS connection (1): acme-v01.api.letsencrypt.org

2016-12-06
20:57:44,500:DEBUG:requests.packages.urllib3.connectionpool:"GET
/directory HTTP/1.1" 200 280
2016-12-06 20:57:44,506:DEBUG:root:Received .
Headers: {'Content-Length': '280', 'Expires': 'Tue, 06 Dec 2016
20:57:46 GMT', 'Boulder-Request-Id':
'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0',
'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx',
'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control':
'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016
20:57:46 GMT', 'X-Frame-Options': 'DENY', 'Content-Type':
'application/json', 'Replay-Nonce':
'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}. Content: '{\n 
"new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz

",\n
"new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert
",\n
"new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg
",\n
"revoke-cert":
"https://acme-v01.api.letsencrypt.org/acme/revoke-cert
"\n}'
2016-12-06 20:57:44,506:DEBUG:acme.client:Received response
 (headers: {'Content-Length': '280', 'Expires':
'Tue, 06 Dec 2016 20:57:46 GMT', 'Boulder-Request-Id':

[Freeipa-users] Let's Encrypt Install: Made a bit of install progress, next error

[Joseph Flynn]

Sorry, I wasn't clear in my earlier subject line.  This is related to the
Lets Encrypt installation.

I tried to pull some more relevant items from the log below.  I don't
actually see all of the elements of my FQDN (ipa-a.kkgpitt.org) only
references to the host (ipa-a) in the log, but am not sure what a good log
should include.

Thanks for any assistance,
Joe


On Tue, Dec 6, 2016 at 4:15 PM, Joseph Flynn  wrote:

> Volunteers,
>
> I moved over to a Fedora VM which was way more difficult than it should
> be.  All kinds of problems with Guest Additions and I ended up having to
> run server mode with no GUI.  Now I run an Ubuntu VM from which I ssh into
> my Fedora VM.  Anyway...
>
> The install made it a further step than before.  I get a quick blue screen
> pop up at the end then an error saying:
> [image: Inline image 1]
>
> An unexpected error occurred:
>> The request message was malformed :: DNS name does not have enough labels
>> Please see the logfiles in /var/log/letsencrypt for more details.
>>
>
> When I run the cert checker util I get this
> https://www.sslshopper.com/ssl-checker.html#hostname=ipa-a.kkgpitt.org
>
> Full log below.
>
> Any suggestions?  Is it not pulling my proper hostname?
>
> Thanks,
> Joe
>
>
>
>
>
> [jjflynn22@ipa-a ~]$ cat /etc/hosts
> 192.168.1.211 ipa-a.kkgpitt.org ipa-a
> 127.0.0.1   localhost localhost.localdomain localhost4
> localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6
> localhost6.localdomain6
>
>
>
>
> [jjflynn22@ipa-a ~]$ sudo cat /var/log/letsencrypt/letsencrypt.log
> [sudo] password for jjflynn22:
> 2016-12-06 20:57:43,982:DEBUG:certbot.main:Root logging level set at 20
> 2016-12-06 20:57:43,983:INFO:certbot.main:Saving debug log to
> /var/log/letsencrypt/letsencrypt.log
> 2016-12-06 20:57:43,991:DEBUG:certbot.main:certbot version: 0.9.3
> 2016-12-06 20:57:43,991:DEBUG:certbot.main:Arguments: ['--standalone',
> '--csr', '/root/ipa-le/httpd-csr.der', '--email', 'xx...@gmail.com',
> '--agree-tos']
> 2016-12-06 20:57:43,992:DEBUG:certbot.main:Discovered plugins:
> PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#null,
> PluginEntryPoint#manual,PluginEntryPoint#standalone)
> 2016-12-06 20:57:43,995:DEBUG:certbot.plugins.selection:Requested
> authenticator standalone and installer None
> 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Single candidate
> plugin: * standalone
> Description: Spin up a temporary webserver
> Interfaces: IAuthenticator, IPlugin
> Entry point: standalone = certbot.plugins.standalone:Authenticator
> Initialized:  0x7fc3dc6fccd0>
> Prep: True
> 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Selected
> authenticator  0x7fc3dc6fccd0> and installer None
> 2016-12-06 20:57:44,115:DEBUG:certbot.main:Picked account:  7446b15565eb5a2fc5850f3ad97dc6dc)>
> 2016-12-06 20:57:44,116:DEBUG:root:Sending GET request to
> https://acme-v01.api.letsencrypt.org/directory. args: (), kwargs: {}
> 2016-12-06 20:57:44,119:INFO:requests.packages.urllib3.connectionpool:Starting
> new HTTPS connection (1): acme-v01.api.letsencrypt.org
> 2016-12-06 20:57:44,500:DEBUG:requests.packages.urllib3.connectionpool:"GET
> /directory HTTP/1.1" 200 280
> 2016-12-06 20:57:44,506:DEBUG:root:Received . Headers:
> {'Content-Length': '280', 'Expires': 'Tue, 06 Dec 2016 20:57:46 GMT',
> 'Boulder-Request-Id': 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0',
> 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx',
> 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control':
> 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT',
> 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json',
> 'Replay-Nonce': 'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}. Content:
> '{\n  "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",\n
> "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",\n
> "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",\n
> "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert"\n}'
> 2016-12-06 20:57:44,506:DEBUG:acme.client:Received response  [200]> (headers: {'Content-Length': '280', 'Expires': 'Tue, 06 Dec 2016
> 20:57:46 GMT', 'Boulder-Request-Id': 
> 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0',
> 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx',
> 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control':
> 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT',
> 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json',
> 'Replay-Nonce': 'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}): '{\n
> "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",\n
> "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",\n
> "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",\n
> "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert"\n}'
> 2016-12-06 20:57:44,506:DEBUG:certbot.client:CSR:
> 

Re: [Freeipa-users] What should the --hostname option do?

[Rob Crittenden]

Martin Basti wrote:
> 
> 
> On 07.12.2016 15:21, Rob Crittenden wrote:
>> Martin Basti wrote:
>>>
>>> On 07.12.2016 08:48, List dedicated to discussions about use,
>>> configuration and deployment of the IPA server. wrote:
 Hello,

 the --hostname option to the installer currently modifies the hostname
 of the machine. In some environments, namely in unprivileged
 containers, that operation is not denied. In some cases, it is
 possible to change the FQDN of the container from outside, for example
 with docker run's -h option. However, in some environments, namely in
 OpenShift, there is not such possibility.

 I have found out that disabling the change by turning /bin/hostnamectl
 and /usr/bin/domainname makes ipa-server-install pass while the server
 gets configured with the hostname specified as the parameter to
 --hostname option so it does not seem to be essential for the FQDN to
 change. Of course, some operations might no longer work, like ssh to
 the FreeIPA machine as sshd would need to be set with
 GSSAPIStrictAcceptorCheck no.

 I wonder if either change of the --hostname semantics, or some new
 option would be useful, to specify the hostname to be used by the
 FreeIPA software while not touching the configuration of the hostname
 for the machine.

>>> I agree that --hostname options should not touch system's hostname, I
>>> don't see reason why application installer should change system
>>> hostname.
>> It was done for sanity because a staggering number of users it seems
>> don't properly set their hostname.
> 
> Then we should have checks and prevent installation, but this needs
> proper design and must cover containers, AWS, etc. to count with various
> scenarios.
> 
>>
>>> I'd start with deprecating current behavior of this option in next
>>> release
>> IMHO it is a pretty significant change of behavior.
> True, so as mentioned later, rather just deprecate this option.

Would be hard to do. Think about something like puppet, it would need to
become version-aware.

> 
>>
>>> As you mentioned we need find what cases can be broken when we will use
>>> different local and external hostname, but anyway we have do this for
>>> containers.
>> Agreed. Something needs to happen, I'm just not convinced it should
>> happen in --hostname. I generally oppose new options but one might be
>> warranted in this case to handle things.
> 
> Maybe --external-hostname or so, noted, we will cover it in design.
> 
>>
>> rob
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] What should the --hostname option do?

[Martin Basti]

On 07.12.2016 15:21, Rob Crittenden wrote:

Martin Basti wrote:


On 07.12.2016 08:48, List dedicated to discussions about use,
configuration and deployment of the IPA server. wrote:

Hello,

the --hostname option to the installer currently modifies the hostname
of the machine. In some environments, namely in unprivileged
containers, that operation is not denied. In some cases, it is
possible to change the FQDN of the container from outside, for example
with docker run's -h option. However, in some environments, namely in
OpenShift, there is not such possibility.

I have found out that disabling the change by turning /bin/hostnamectl
and /usr/bin/domainname makes ipa-server-install pass while the server
gets configured with the hostname specified as the parameter to
--hostname option so it does not seem to be essential for the FQDN to
change. Of course, some operations might no longer work, like ssh to
the FreeIPA machine as sshd would need to be set with
GSSAPIStrictAcceptorCheck no.

I wonder if either change of the --hostname semantics, or some new
option would be useful, to specify the hostname to be used by the
FreeIPA software while not touching the configuration of the hostname
for the machine.


I agree that --hostname options should not touch system's hostname, I
don't see reason why application installer should change system hostname.

It was done for sanity because a staggering number of users it seems
don't properly set their hostname.


Then we should have checks and prevent installation, but this needs 
proper design and must cover containers, AWS, etc. to count with various 
scenarios.





I'd start with deprecating current behavior of this option in next release

IMHO it is a pretty significant change of behavior.

True, so as mentioned later, rather just deprecate this option.




As you mentioned we need find what cases can be broken when we will use
different local and external hostname, but anyway we have do this for
containers.

Agreed. Something needs to happen, I'm just not convinced it should
happen in --hostname. I generally oppose new options but one might be
warranted in this case to handle things.


Maybe --external-hostname or so, noted, we will cover it in design.



rob


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts

[Chris Dagdigian]

Confirmed that adding the following to /etc/sssd/ssd.conf on the SERVER 
fixed SSH password checks on the server itself!


ldap_user_principal = nosuchattr
subdomain_inherit = ldap_user_principal

The core problem does appear to be the "... UPN is quite different" 
error when we try to login as u...@nafta.company.org which then gets 
shortened to u...@company.org. It's hard to read the volume of 
debug_level 10 logs but it's clear that it's getting hung up with 
principals when talking to the remote AD servers.


I can now login to the IPA server with my standard AD credentials which 
has been impossible until just now.


However no luck on IPA clients. Can you confirm that the above sssd.conf 
workaround is for the IPA server only as the thread you linked to 
indicates or is this a change I should push down to clients? I'm going 
to build some fresh clients just in case.


And knowing that this workaround seems to be getting close to totally 
resolving our issue would you recommend IPA-4.4 for our environment 
where we have lots of AD trusts in play combined with DNS-DOMAIN 
differences between the IPA realm and the managed clients? Or is it 
better to stick with the workaround settings + the IPA-4.2 release that 
comes with CentOS/RHEL-7?


Thanks!

Chris


Sumit Bose wrote:

Both authentications where successful against the backend. For the logs
it looks like you use an alternative domain suffix on the AD side so
that all user if other domains in the forest can use the forest root
suffix as realm, in the user principal (u...@nafta.company.org  ->
u...@company.org).

I would expect that there are messages like "UPN used in the request
...differ by more than just the case." in the domain log at 'TueDec  6
19:57:11'  and 'TueDec  6 19:57:14'.

If that's the case updating to4.4  would help because in this release
IPA can forward the enterprise principals properly and SSSD will not
reject the changed principal because sSSD will be aware of the change.

But there are workarounds to make it work with your version as well,
please see e.g. the suggestion from
https://www.redhat.com/archives/freeipa-users/2016-May/msg00205.html  .


--
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] What should the --hostname option do?

[Rob Crittenden]

Martin Basti wrote:
> 
> 
> On 07.12.2016 08:48, List dedicated to discussions about use,
> configuration and deployment of the IPA server. wrote:
>> Hello,
>>
>> the --hostname option to the installer currently modifies the hostname
>> of the machine. In some environments, namely in unprivileged
>> containers, that operation is not denied. In some cases, it is
>> possible to change the FQDN of the container from outside, for example
>> with docker run's -h option. However, in some environments, namely in
>> OpenShift, there is not such possibility.
>>
>> I have found out that disabling the change by turning /bin/hostnamectl
>> and /usr/bin/domainname makes ipa-server-install pass while the server
>> gets configured with the hostname specified as the parameter to
>> --hostname option so it does not seem to be essential for the FQDN to
>> change. Of course, some operations might no longer work, like ssh to
>> the FreeIPA machine as sshd would need to be set with
>> GSSAPIStrictAcceptorCheck no.
>>
>> I wonder if either change of the --hostname semantics, or some new
>> option would be useful, to specify the hostname to be used by the
>> FreeIPA software while not touching the configuration of the hostname
>> for the machine.
>>
> 
> I agree that --hostname options should not touch system's hostname, I
> don't see reason why application installer should change system hostname.

It was done for sanity because a staggering number of users it seems
don't properly set their hostname.

> I'd start with deprecating current behavior of this option in next release

IMHO it is a pretty significant change of behavior.

> As you mentioned we need find what cases can be broken when we will use
> different local and external hostname, but anyway we have do this for
> containers.

Agreed. Something needs to happen, I'm just not convinced it should
happen in --hostname. I generally oppose new options but one might be
warranted in this case to handle things.

rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Brian Candler]

On 07/12/2016 08:58, freeIPA users list wrote:
On ke, 07 joulu 2016, List dedicated to discussions about use, 
configuration and deployment of the IPA server. wrote:
I know the Quick Start Guide and Deployment Recommendations cover 
this in

depth, but there are still some ambiguities.

I'm trying to figure out if a company like us, lautus.net should use 
a DNS

subdomain like ipa.lautus.net for the IPA domain, or not.

It is really depending on your deployment details.

If you already have some other Kerberized environment in place and you
are not going to replace it by FreeIPA, then you need to make sure that
new FreeIPA deployment would not conflict with the existing one.
Or if you think there's a chance you might want to add another 
Kerberized environment later (e.g. "ad.lautus.net")





should continue to be hosted by DNS servers elsewhere that delegate say,
ipa.lautus.net to FreeIPA.
The question of whether you host ipa.lautus.net DNS (or indeed 
lautus.net DNS) in FreeIPA is a different issue.


If you're happy with your existing DNS infrastructure, then you can 
either delegate ipa.lautus.net to your FreeIPA servers (with NS 
records); or run FreeIPA without DNS, and simply import the 
ipa.lautus.net SRV records directly into the lautus.net domain.


Having FreeIPA host the ipa.lautus.net domain means these SRV records 
are populated automatically, but it's not really that hard to add them 
to an existing DNS service.


OTOH, if you *don't* already have a good authoritative internal DNS 
service with a UI that you like, then you might want to use FreeIPA for 
this anyway. You can easily create extra zones in FreeIPA.


I would be a bit wary about putting FreeIPA servers out on the public 
Internet though. For one thing, the default config is an open resolver 
(which you can tighten easily enough). I also have a deep distrust of 
Java, but maybe that's just me.






But on the other hand the same doc is full of examples where a Kerberos
realm like EXAMPLE.COM (instead of IPA.EXAMPLE.COM) is used, i.e example
2.2. of secion 2.3.4. But the same guide also says that the Kerberos 
realm
should be the same as the ipa DNS domain, just uppercased. So example 
2.2.

implies that example.com is running their DNS domain on FreeIPA, for
everything, not just for IPA SRV and TXT entries.
The Kerberos realm always has a corresponding DNS domain, so realm 
IPA.LAUTUS.NET has a corresponding DNS domain "ipa.lautus.net".


But with FreeIPA you can still manage hosts called foo.lautus.net or 
bar.int.lautus.net. At worst you'd have some extra [domain_realm] 
mappings in krb5.conf


(Aside: Active Directory is much more fussy, and basically doesn't work 
if the hosts don't have hostnames within the same DNS domain as their 
kerberos realm - and indeed have reverse DNS as well as forward)




And when ipa-client-install is run on somehost.lautus.net, it also 
defaults

to LAUTUS.NET for Kerberos domain, as if the default expectation is that
your toplevel company DNS name would be your kerberos domain.

But you can override that.




And when I install a trial IPA server on host ipa-server-1.lautus.net 
using

"ipa-server-install --setup-dns --realm IPA.LAUTUS.NET --domain
ipa.lautus.net --forwarder=8.8.8.8", and then look at the DNS Zones  
in the
Web UI, I see not only ipa.lautus.net, but also lautus, with record 
"@ NS

ipa-server-1.lautus.net". In other words the IPA server defaults to
thinking it owns the domain above ipa.lautus.net too. Which goes against
2.3.1 above.

Interesting. What does "ipa dnszone-find --pkey-only" show?

It seems like it's created an authoritative zone both for the server's 
own domain (lautus.net if the server is xxx.lautus.net) as well as the 
realm's domain (ipa.lautus.net)


I don't know why it's doing that. Now I've checked with another system 
here: the hostname is "ipa-1.int.example.com" and the realm is 
"ipa.example.com", and you're right, it is authoritative for both:


  Zone name: int.example.com.
  Zone name: ipa.example.com.

This isn't what I wanted. The int.example.com domain is hosted 
externally and I didn't want to override it. Right now it's hiding all 
names in int.example.com that it doesn't know about.


I would expect that it's possible to remove this zone, but I'd need to 
test that doesn't stop other hosts called xxx.int.example.com from joining.



Yes and no. What you see with "@ NS ..." is a glue record -- you are
supposed to have a glue record for IPA domain in the upstream domain,
this is how domain delegation works in DNS world.
Aside: technically that's not a glue record. A glue record is an A or 
 record when the NS record points to a host within the subdomain 
which is being delegated. It is to solve the chicken-and-egg situation 
of how to contact a nameserver for a domain before you've contacted a 
nameserver for the domain.


In your case, if you already have working DNS for lautus.net, then you 
don't want FreeIPA to be authoritative for 

Re: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts

[Chris Dagdigian]

Sumit,

Thank you so much for your assistance and eyeballs on the massive 
logset. I've repeatedly found the level of support on this list to be 
fantastic. Some day I'll have enough hands-on experience to repay in 
kind ...


We do actually use a different domain for the clients:

Our clients are "company-aws.org" while being managed by 
"company-idm.org" and talking to AD forests and many child domains in 
"company.org".


It's a fairly hairy setup driven mostly by "above my pay grade" distrust 
of IaaS cloud environments like AWS VPCs combined with existing use of 
Kerberos that we don't want to break. Hence putting IDM/IPA in a 
separate domain and realm altogether.


I actually DID see the "UPN used in the request .. differ" error 
messages all over the place.


I will try the workaround linked to below and report back.

Follow-up on the 4.4 release:

For people using CentOS/RHEL 7.x is it recommended to use  IPA 4.4 code 
in production? Our needs are pretty simple once you get beyond the 
complex AD environment - we just need simple SSH password authentication 
and a bit of RBAC feature for a small to midsize cloud footprint.  I'm 
guessing that running 4.4 if we have passwords working would not be all 
that risky for us. It really does seem like a large amount of recent IPA 
development has focused on AD integration so I'm actually fairly 
interested and motivated to step up from our 4.2 version.


Regards,
Chris


Sumit Bose wrote:


Both authentications where successful against the backend. For the logs
it looks like you use an alternative domain suffix on the AD side so
that all user if other domains in the forest can use the forest root
suffix as realm, in the user principal (u...@nafta.company.org  ->
u...@company.org).

I would expect that there are messages like "UPN used in the request
...differ by more than just the case." in the domain log at 'TueDec  6
19:57:11'  and 'TueDec  6 19:57:14'.

If that's the case updating to4.4  would help because in this release
IPA can forward the enterprise principals properly and SSSD will not
reject the changed principal because sSSD will be aware of the change.

But there are workarounds to make it work with your version as well,
please see e.g. the suggestion from
https://www.redhat.com/archives/freeipa-users/2016-May/msg00205.html  .

HTH

bye,
Sumit


--
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] Still unclear about relation between IPA DNS domain and company DNS domain.

[Pieter Nagel]

Thanks, that helps a lot.

Yes and no. What you see with "@ NS ..." is a glue record -- you are
> supposed to have a glue record for IPA domain in the upstream domain,
> this is how domain delegation works in DNS world.


Except what i saw was the other way around. The FreeIPA server has an
NSrecord claiming that it is authoritative the parent domain, but its
parent domain is hosted at dnsmadeeasy:

~ dig @8.8.8.8  -t NS lautus.net
lautus.net. 86399 IN NS ns15.dnsmadeeasy.com.
~ dig @8.8.8.8  -t NS ipa.lautus.net
ipa.lautus.net. 86399 IN NS ipa-hetzner-cpt4-01.lautus.net.

But as far as the FreeIPA DNS is concerned, it is authoritative for
everything:

~ dig @ipa-hetzner-cpt4-01.lautus.net  -t NS lautus.net
lautus.net. 86400 IN NS ipa-hetzner-cpt4-01.lautus.net.
~ dig @ipa-hetzner-cpt4-01.lautus.net  -t NS ipa.lautus.net
ipa.lautus.net. 86400 IN NS ipa-hetzner-cpt4-01.lautus.net.







-- 
Pieter Nagel
Lautus Solutions (Pty) Ltd
Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng
0832587540
-- 
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] Loss of initial master in multi master setup

[Neal Harrington | i-Neda Ltd]

> From: Rob Crittenden 
> Martin Babinsky wrote:
> > On 12/01/2016 01:28 PM, Neal Harrington | i-Neda Ltd wrote:
> >> Hi IPA Gurus,
> >>
> >>
> >> I had a 3 site multi master IPA replication setup (1 office and 2
> >> datacentres) with 2 IPA servers at each site. Each server was
> >> replicating successfully to 3 other servers (the other local site
> >> server and one server at each of the two remote sites). Everything is
> >> running on the default packages from CentOS 7.2 and each server is a
> >> full replica (ipa-replica-install
> >> /var/lib/ipa/replica-info-id-myserver.fqdn.com.gpg  --setup-ca
> >> --setup-dns --mkhomedir --forwarder 8.8.8.8)
> >>
> >>
> >> Everything was ticking over nicely until we had notice that the
> >> office site was moving on short notice.
> >>
> >>
> >> I successfully created IPA servers at the new site, setup replication
> >> again between the new office and the two datacentres that were to
> >> remain online, tested and everything worked as expected -
> >> unfortunately in the rush I did not have time to properly retire the
> >> IPA servers in the old office.
> >>
> >>
> >> The problem this has caused is that I only ever created users in one
> >> of the IPA servers in the original office - so only those servers
> >> have a DNA range and I am now unable to create new users on the active
> servers.
> >> The original office servers are still in the IPA replication and
> >> powered on but offline so potential split brain?
> >>
> >>
> >> I now have two things I would like to know before proceeding:
> >>
> >>   * Is the best fix here to force remove the original IPA servers and
> >> manually add a new dna range significantly different from the
> >> original to avoid overlaps?
> >>   * Is there anything else I should check? I can't see any issues
> >> however did not notice the DNA range until I tried to create a user.
> >>
> >> Any pointers greatly appreciated.
> >>
> >>
> >> Thanks,
> >>
> >> Neal.
> >>
> >>
> >>
> >>
> >>
> >>
> >
> > Hi Neal,
> >
> > If you already disconnected/decomissioned the old masters then I thnk
> > the best you can do is option a, i.e. re-set DNA ranges on replicas to
> > new values while avioding overlap with old ranges.
> >
> > We have an upstream document[1] describing the procedure. Hope it
> helps.
> >
> > Also make sure that you migrated CA renewal and CRL master
> > responsibilities to the new replicas, otherwise you may get problems
> > with expiring certificates which are really hard to solve. See the
> > following guide for details. [2]
> >
> > [1] http://www.freeipa.org/page/V3/Recover_DNA_Ranges
> > [2]
> >
> http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_
> Master
> >
> 
> You may want to look at this too, http://blog-rcritten.rhcloud.com/?p=50
> 
> rob

Hi Rob & Martin,

Thanks for the pointers, I am now able to create new users on different servers 
- however everything to do with replication seems to be failing.

I have changed my replication from a mesh to a long chain and run 
"ipa-replica-manage -v re-initialize --from " and the same for 
ipa-csreplica-manage along the chain which succeeds (and any passwords/user 
creation etc I have done at the start of the chain is pulled through) however 
replication fails immediately after. I was hoping that re-initializing the 
chain like this would flush out any "bad" entries - probably wishful thinking.

"Ipa-replica-manage -v list" only shows servers in the chain. 
"Ipa-replica-manage list-ruv" did show the two original servers which I lost 
connection to and I removed those which successfully removed them from all 
servers so that part of replication seems to be working. When I do an LDAP 
search I still see those old masters though (and also see one previously 
retired server with two different ID's - blue-auth01). Will I need to manually 
delete these? (example search and output below)

Apart from manually deleting the dead servers from LDAP, what else should I do 
to get replication working again? I'm watching for the CentOS 7.3 release to be 
able to upgrade to IPA 4.3 as I've seen a few posts about the better handling 
of replication etc in that version. In the meantime the errors log (copy below) 
indicates I need to re-initialize which I've done several times without any 
improvement.

Thanks in advance,
Neal.

[root@office-auth04 ~]# ldapsearch -h $(hostname -f)  -D "cn=directory manager" 
-W  -b "o=ipaca" 
"(&(objectclass=nstombstone)(nsUniqueId=---))" 
nscpentrywsi
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base 

Re: [Freeipa-users] Services missing in web-ui

[Pavel Vomacka]

I'm glad that you found it, and I'm sorry, I should have attached the BZ 
in the first mail.



On 12/07/2016 01:26 PM, Troels Hansen wrote:

Sorry. Didn't see this.

https://bugzilla.redhat.com/show_bug.cgi?id=1387782



- On Dec 7, 2016, at 12:43 PM, Troels Hansen  wrote:

Looks great..Pavel, as a RedHat internal, should I create
a ticket to have this fixed in the RedHat version, or does it
already have a internal Red Hat bugzilla case?


- On Dec 7, 2016, at 11:58 AM, Pavel Vomacka
 wrote:

Hello,

it is caused by missing canonical name on services which were
created in older versions of FreeIPA. Fixed ticket here:
https://fedorahosted.org/freeipa/ticket/6397 .

On 12/07/2016 11:48 AM, Fujisan wrote:

And with Firefox 50.0.2.

F.

On Wed, Dec 7, 2016 at 11:46 AM, Fujisan
> wrote:

I have the same issue with version 4.4.2

$ rpm -qa|grep freeipa
freeipa-server-4.4.2-1.fc25.x86_64
freeipa-python-compat-4.4.2-1.fc25.noarch
freeipa-server-common-4.4.2-1.fc25.noarch
freeipa-common-4.4.2-1.fc25.no
arch
freeipa-server-trust-ad-4.4.2-1.fc25.x86_64
freeipa-client-4.4.2-1.fc25.x86_64
freeipa-client-common-4.4.2-1.fc25.noarch


​F.​


On Wed, Dec 7, 2016 at 11:13 AM, Troels Hansen
> wrote:

I have a strange issue in IPA 4.4.0-12 (RHEL 7.3)


Navigating to Identity -> Services reveals 5
services. 2 cifs, 2 dogtag and one empty line...

cifs/host1.domain@REALM
cifs/host2.domain@REALM
dogtag/ipa01.domain@REALM
dogtag/ipa02.domain@REALM



However, from CLI everything looks OK:

# ipa service-find
---
11 services matched
---
Principal name: ldap/ipa02.domain@REALM
Principal alias: ldap/ipa02.domain@REALM
Certificate: ...
...


Keytab: True

Principal name: ldap/ipa01.domain@REALM
Principal alias: ldap/ipa01.domain@REALM
Certificate: ...
...


Keytab: True

Principal name: HTTP/ipa02.domain@REALM
Principal alias: HTTP/ipa02.domain@REALM
Certificate: 
...



Keytab: True

Principal name: cifs/rhellxudv01.domain@REALM
Principal alias: cifs/rhellxudv01.domain@REALM
Keytab: True



Principal name: cifs/ipa02.domain@REALM
Principal alias: cifs/ipa02.domain@REALM
Keytab: True



Principal name: nfs/profil01.domain@REALM
Principal alias: nfs/profil01.domain@REALM
Keytab: True



Principal name: cifs/ipa01.domain@REALM
Principal alias: cifs/ipa01.domain@REALM
Keytab: True

Principal name: dogtag/ipa02.domain@REALM
Principal alias: dogtag/ipa02.domain@REALM
Keytab: True



Principal name: dogtag/ipa01.domain@REALM
Principal alias: dogtag/ipa01.domain@REALM
Keytab: True



Principal name: cifs/rhellxudv02.domain@REALM
Principal alias: cifs/rhellxudv02.domain@REALM
Keytab: True



Principal name: HTTP/ipa01.domain@REALM
Principal alias: HTTP/ipa01.domain@REALM
Certificate: ..
..
Keytab: True



-
Number of entries returned 11
-




(some lines truncated.)


s... somsthing must be disrupting the view in
web-ui,


Tried in Chrome 43 and IE 11


Looking at what gets requested by the browser at
/ipa/session/json I can see in the json that it
gets the correct content:


result: {count: 11, result: [,…], summary: "11
   

Re: [Freeipa-users] Services missing in web-ui

[Troels Hansen]

Sorry. Didn't see this. 

https://bugzilla.redhat.com/show_bug.cgi?id=1387782 

- On Dec 7, 2016, at 12:43 PM, Troels Hansen  wrote: 

> Looks great.. Pavel, as a RedHat internal, should I create a ticket to 
> have
> this fixed in the RedHat version, or does it already have a internal Red Hat
> bugzilla case?

> - On Dec 7, 2016, at 11:58 AM, Pavel Vomacka  wrote:

>> Hello,

>> it is caused by missing canonical name on services which were created in 
>> older
>> versions of FreeIPA. Fixed ticket here:
>> https://fedorahosted.org/freeipa/ticket/6397 .
>> On 12/07/2016 11:48 AM, Fujisan wrote:

>>> And with Firefox 50.0.2.

>>> F.

>>> On Wed, Dec 7, 2016 at 11:46 AM, Fujisan < fujisa...@gmail.com > wrote:

 I have the same issue with version 4.4.2

 $ rpm -qa|grep freeipa
 freeipa-server-4.4.2-1.fc25.x86_64
 freeipa-python-compat-4.4.2-1.fc25.noarch
 freeipa-server-common-4.4.2-1.fc25.noarch
 freeipa-common-4.4.2-1.fc25.no arch
 freeipa-server-trust-ad-4.4.2-1.fc25.x86_64
 freeipa-client-4.4.2-1.fc25.x86_64
 freeipa-client-common-4.4.2-1.fc25.noarch

 ​F.​

 On Wed, Dec 7, 2016 at 11:13 AM, Troels Hansen < t...@casalogic.dk > wrote:

> I have a strange issue in IPA 4.4.0-12 (RHEL 7.3)

> Navigating to Identity -> Services reveals 5 services. 2 cifs, 2 dogtag 
> and one
> empty line...

> cifs/host1.domain@REALM
> cifs/host2.domain@REALM
> dogtag/ipa01.domain@REALM
> dogtag/ipa02.domain@REALM

> However, from CLI everything looks OK:

> # ipa service-find
> ---
> 11 services matched
> ---
> Principal name: ldap/ipa02.domain@REALM
> Principal alias: ldap/ipa02.domain@REALM
> Certificate: ...
> ...

> Keytab: True

> Principal name: ldap/ipa01.domain@REALM
> Principal alias: ldap/ipa01.domain@REALM
> Certificate: ...
> ...

> Keytab: True

> Principal name: HTTP/ipa02.domain@REALM
> Principal alias: HTTP/ipa02.domain@REALM
> Certificate: 
> ...

> Keytab: True

> Principal name: cifs/rhellxudv01.domain@REALM
> Principal alias: cifs/rhellxudv01.domain@REALM
> Keytab: True

> Principal name: cifs/ipa02.domain@REALM
> Principal alias: cifs/ipa02.domain@REALM
> Keytab: True

> Principal name: nfs/profil01.domain@REALM
> Principal alias: nfs/profil01.domain@REALM
> Keytab: True

> Principal name: cifs/ipa01.domain@REALM
> Principal alias: cifs/ipa01.domain@REALM
> Keytab: True

> Principal name: dogtag/ipa02.domain@REALM
> Principal alias: dogtag/ipa02.domain@REALM
> Keytab: True

> Principal name: dogtag/ipa01.domain@REALM
> Principal alias: dogtag/ipa01.domain@REALM
> Keytab: True

> Principal name: cifs/rhellxudv02.domain@REALM
> Principal alias: cifs/rhellxudv02.domain@REALM
> Keytab: True

> Principal name: HTTP/ipa01.domain@REALM
> Principal alias: HTTP/ipa01.domain@REALM
> Certificate: ..
> ..
> Keytab: True

> -
> Number of entries returned 11
> -

> (some lines truncated.)

> s... somsthing must be disrupting the view in web-ui,

> Tried in Chrome 43 and IE 11

> Looking at what gets requested by the browser at /ipa/session/json I can 
> see in
> the json that it gets the correct content:

> result: {count: 11, result: [,…], summary: "11 services matched", 
> truncated:
> false}
> count: 11
> result: [,…]
> 0: {dn:
> "krbprincipalname=cifs/rhellxudv01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
> 1: {dn:
> "krbprincipalname=dogtag/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
> 2: {dn:
> "krbprincipalname=nfs/profil01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
> 3: {dn:
> "krbprincipalname=cifs/rhellxudv02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
> 4: {dn:
> "krbprincipalname=dogtag/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
> 5: {dn:
> "krbprincipalname=HTTP/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
> 6: {dn:
> "krbprincipalname=cifs/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
> 7: {dn:
> "krbprincipalname=cifs/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
> 8: {dn:
> "krbprincipalname=ldap/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
> 9: {dn:
> "krbprincipalname=HTTP/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
> 10: {dn:
> "krbprincipalname=ldap/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
> summary: "11 services matched"
> truncated: false

> So this is obviously only a web-ui problem, but I can't see what causes 
> the
> problem?

> --
> Manage your 

Re: [Freeipa-users] Services missing in web-ui

[Troels Hansen]

Looks great.. Pavel, as a RedHat internal, should I create a ticket to have 
this fixed in the RedHat version, or does it already have a internal Red Hat 
bugzilla case? 

- On Dec 7, 2016, at 11:58 AM, Pavel Vomacka  wrote: 

> Hello,

> it is caused by missing canonical name on services which were created in older
> versions of FreeIPA. Fixed ticket here:
> https://fedorahosted.org/freeipa/ticket/6397 .
> On 12/07/2016 11:48 AM, Fujisan wrote:

>> And with Firefox 50.0.2.

>> F.

>> On Wed, Dec 7, 2016 at 11:46 AM, Fujisan < fujisa...@gmail.com > wrote:

>>> I have the same issue with version 4.4.2

>>> $ rpm -qa|grep freeipa
>>> freeipa-server-4.4.2-1.fc25.x86_64
>>> freeipa-python-compat-4.4.2-1.fc25.noarch
>>> freeipa-server-common-4.4.2-1.fc25.noarch
>>> freeipa-common-4.4.2-1.fc25.no arch
>>> freeipa-server-trust-ad-4.4.2-1.fc25.x86_64
>>> freeipa-client-4.4.2-1.fc25.x86_64
>>> freeipa-client-common-4.4.2-1.fc25.noarch

>>> ​F.​

>>> On Wed, Dec 7, 2016 at 11:13 AM, Troels Hansen < t...@casalogic.dk > wrote:

 I have a strange issue in IPA 4.4.0-12 (RHEL 7.3)

 Navigating to Identity -> Services reveals 5 services. 2 cifs, 2 dogtag 
 and one
 empty line...

 cifs/host1.domain@REALM
 cifs/host2.domain@REALM
 dogtag/ipa01.domain@REALM
 dogtag/ipa02.domain@REALM

 However, from CLI everything looks OK:

 # ipa service-find
 ---
 11 services matched
 ---
 Principal name: ldap/ipa02.domain@REALM
 Principal alias: ldap/ipa02.domain@REALM
 Certificate: ...
 ...

 Keytab: True

 Principal name: ldap/ipa01.domain@REALM
 Principal alias: ldap/ipa01.domain@REALM
 Certificate: ...
 ...

 Keytab: True

 Principal name: HTTP/ipa02.domain@REALM
 Principal alias: HTTP/ipa02.domain@REALM
 Certificate: 
 ...

 Keytab: True

 Principal name: cifs/rhellxudv01.domain@REALM
 Principal alias: cifs/rhellxudv01.domain@REALM
 Keytab: True

 Principal name: cifs/ipa02.domain@REALM
 Principal alias: cifs/ipa02.domain@REALM
 Keytab: True

 Principal name: nfs/profil01.domain@REALM
 Principal alias: nfs/profil01.domain@REALM
 Keytab: True

 Principal name: cifs/ipa01.domain@REALM
 Principal alias: cifs/ipa01.domain@REALM
 Keytab: True

 Principal name: dogtag/ipa02.domain@REALM
 Principal alias: dogtag/ipa02.domain@REALM
 Keytab: True

 Principal name: dogtag/ipa01.domain@REALM
 Principal alias: dogtag/ipa01.domain@REALM
 Keytab: True

 Principal name: cifs/rhellxudv02.domain@REALM
 Principal alias: cifs/rhellxudv02.domain@REALM
 Keytab: True

 Principal name: HTTP/ipa01.domain@REALM
 Principal alias: HTTP/ipa01.domain@REALM
 Certificate: ..
 ..
 Keytab: True

 -
 Number of entries returned 11
 -

 (some lines truncated.)

 s... somsthing must be disrupting the view in web-ui,

 Tried in Chrome 43 and IE 11

 Looking at what gets requested by the browser at /ipa/session/json I can 
 see in
 the json that it gets the correct content:

 result: {count: 11, result: [,…], summary: "11 services matched", 
 truncated:
 false}
 count: 11
 result: [,…]
 0: {dn:
 "krbprincipalname=cifs/rhellxudv01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 1: {dn:
 "krbprincipalname=dogtag/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 2: {dn:
 "krbprincipalname=nfs/profil01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 3: {dn:
 "krbprincipalname=cifs/rhellxudv02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 4: {dn:
 "krbprincipalname=dogtag/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 5: {dn:
 "krbprincipalname=HTTP/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 6: {dn:
 "krbprincipalname=cifs/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 7: {dn:
 "krbprincipalname=cifs/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 8: {dn:
 "krbprincipalname=ldap/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 9: {dn:
 "krbprincipalname=HTTP/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 10: {dn:
 "krbprincipalname=ldap/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 summary: "11 services matched"
 truncated: false

 So this is obviously only a web-ui problem, but I can't see what causes 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

> --
> Pavel^3 Vomacka

-- 

Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 

T (+45) 70 20 10 63 

M (+45) 

Re: [Freeipa-users] Services missing in web-ui

[Pavel Vomacka]

Hello,

it is caused by missing canonical name on services which were created in 
older versions of FreeIPA. Fixed ticket here: 
https://fedorahosted.org/freeipa/ticket/6397 .


On 12/07/2016 11:48 AM, Fujisan wrote:

And with Firefox 50.0.2.

F.

On Wed, Dec 7, 2016 at 11:46 AM, Fujisan > wrote:


I have the same issue with version 4.4.2

$ rpm -qa|grep freeipa
freeipa-server-4.4.2-1.fc25.x86_64
freeipa-python-compat-4.4.2-1.fc25.noarch
freeipa-server-common-4.4.2-1.fc25.noarch
freeipa-common-4.4.2-1.fc25.no
arch
freeipa-server-trust-ad-4.4.2-1.fc25.x86_64
freeipa-client-4.4.2-1.fc25.x86_64
freeipa-client-common-4.4.2-1.fc25.noarch


​F.​


On Wed, Dec 7, 2016 at 11:13 AM, Troels Hansen > wrote:

I have a strange issue in IPA 4.4.0-12 (RHEL 7.3)


Navigating to Identity -> Services reveals 5 services. 2 cifs,
2 dogtag and one empty line...

cifs/host1.domain@REALM
cifs/host2.domain@REALM
dogtag/ipa01.domain@REALM
dogtag/ipa02.domain@REALM



However, from CLI everything looks OK:

# ipa service-find
---
11 services matched
---
Principal name: ldap/ipa02.domain@REALM
Principal alias: ldap/ipa02.domain@REALM
Certificate: ...
...


Keytab: True

Principal name: ldap/ipa01.domain@REALM
Principal alias: ldap/ipa01.domain@REALM
Certificate: ...
...


Keytab: True

Principal name: HTTP/ipa02.domain@REALM
Principal alias: HTTP/ipa02.domain@REALM
Certificate: 
...



Keytab: True

Principal name: cifs/rhellxudv01.domain@REALM
Principal alias: cifs/rhellxudv01.domain@REALM
Keytab: True



Principal name: cifs/ipa02.domain@REALM
Principal alias: cifs/ipa02.domain@REALM
Keytab: True



Principal name: nfs/profil01.domain@REALM
Principal alias: nfs/profil01.domain@REALM
Keytab: True



Principal name: cifs/ipa01.domain@REALM
Principal alias: cifs/ipa01.domain@REALM
Keytab: True

Principal name: dogtag/ipa02.domain@REALM
Principal alias: dogtag/ipa02.domain@REALM
Keytab: True



Principal name: dogtag/ipa01.domain@REALM
Principal alias: dogtag/ipa01.domain@REALM
Keytab: True



Principal name: cifs/rhellxudv02.domain@REALM
Principal alias: cifs/rhellxudv02.domain@REALM
Keytab: True



Principal name: HTTP/ipa01.domain@REALM
Principal alias: HTTP/ipa01.domain@REALM
Certificate: ..
..
Keytab: True



-
Number of entries returned 11
-




(some lines truncated.)


s... somsthing must be disrupting the view in web-ui,


Tried in Chrome 43 and IE 11


Looking at what gets requested by the browser at
/ipa/session/json I can see in the json that it gets the
correct content:


result: {count: 11, result: [,…], summary: "11 services
matched", truncated: false}
count: 11
result: [,…]
0: {dn:

"krbprincipalname=cifs/rhellxudv01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
1: {dn:

"krbprincipalname=dogtag/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
2: {dn:

"krbprincipalname=nfs/profil01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
3: {dn:

"krbprincipalname=cifs/rhellxudv02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
4: {dn:

"krbprincipalname=dogtag/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
5: {dn:

"krbprincipalname=HTTP/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
6: {dn:

"krbprincipalname=cifs/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
7: {dn:

"krbprincipalname=cifs/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
8: {dn:

"krbprincipalname=ldap/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
9: {dn:

"krbprincipalname=HTTP/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
10: {dn:

"krbprincipalname=ldap/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
summary: "11 services matched"
truncated: false



So this is obviously only a web-ui problem, but I can't see
what causes the problem?


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Services missing in web-ui

[Fujisan]

And with Firefox 50.0.2.

F.

On Wed, Dec 7, 2016 at 11:46 AM, Fujisan  wrote:

> I have the same issue with version 4.4.2
>
> $ rpm -qa|grep freeipa
> freeipa-server-4.4.2-1.fc25.x86_64
> freeipa-python-compat-4.4.2-1.fc25.noarch
> freeipa-server-common-4.4.2-1.fc25.noarch
> freeipa-common-4.4.2-1.fc25.noarch
> freeipa-server-trust-ad-4.4.2-1.fc25.x86_64
> freeipa-client-4.4.2-1.fc25.x86_64
> freeipa-client-common-4.4.2-1.fc25.noarch
>
>
> ​F.​
>
>
> On Wed, Dec 7, 2016 at 11:13 AM, Troels Hansen  wrote:
>
>> I have a strange issue in IPA 4.4.0-12 (RHEL 7.3)
>>
>>
>> Navigating to Identity -> Services reveals 5 services. 2 cifs, 2 dogtag
>> and one empty line...
>>
>> cifs/host1.domain@REALM
>> cifs/host2.domain@REALM
>> dogtag/ipa01.domain@REALM
>> dogtag/ipa02.domain@REALM
>>
>>
>>
>> However, from CLI everything looks OK:
>>
>> # ipa service-find
>> ---
>> 11 services matched
>> ---
>> Principal name: ldap/ipa02.domain@REALM
>> Principal alias: ldap/ipa02.domain@REALM
>> Certificate: ...
>> ...
>>
>>
>> Keytab: True
>>
>> Principal name: ldap/ipa01.domain@REALM
>> Principal alias: ldap/ipa01.domain@REALM
>> Certificate: ...
>> ...
>>
>>
>> Keytab: True
>>
>> Principal name: HTTP/ipa02.domain@REALM
>> Principal alias: HTTP/ipa02.domain@REALM
>> Certificate: 
>> ...
>>
>>
>>
>> Keytab: True
>>
>> Principal name: cifs/rhellxudv01.domain@REALM
>> Principal alias: cifs/rhellxudv01.domain@REALM
>> Keytab: True
>>
>>
>>
>> Principal name: cifs/ipa02.domain@REALM
>> Principal alias: cifs/ipa02.domain@REALM
>> Keytab: True
>>
>>
>>
>> Principal name: nfs/profil01.domain@REALM
>> Principal alias: nfs/profil01.domain@REALM
>> Keytab: True
>>
>>
>>
>> Principal name: cifs/ipa01.domain@REALM
>> Principal alias: cifs/ipa01.domain@REALM
>> Keytab: True
>>
>> Principal name: dogtag/ipa02.domain@REALM
>> Principal alias: dogtag/ipa02.domain@REALM
>> Keytab: True
>>
>>
>>
>> Principal name: dogtag/ipa01.domain@REALM
>> Principal alias: dogtag/ipa01.domain@REALM
>> Keytab: True
>>
>>
>>
>> Principal name: cifs/rhellxudv02.domain@REALM
>> Principal alias: cifs/rhellxudv02.domain@REALM
>> Keytab: True
>>
>>
>>
>> Principal name: HTTP/ipa01.domain@REALM
>> Principal alias: HTTP/ipa01.domain@REALM
>> Certificate: ..
>> ..
>> Keytab: True
>>
>>
>>
>> -
>> Number of entries returned 11
>> -
>>
>>
>>
>>
>> (some lines truncated.)
>>
>>
>> s... somsthing must be disrupting the view in web-ui,
>>
>>
>> Tried in Chrome 43 and IE 11
>>
>>
>> Looking at what gets requested by the browser at /ipa/session/json I can
>> see in the json that it gets the correct content:
>>
>>
>> result: {count: 11, result: [,…], summary: "11 services matched",
>> truncated: false}
>> count: 11
>> result: [,…]
>> 0: {dn: "krbprincipalname=cifs/rhellxudv01.domain@REALM,cn=services,
>> cn=accounts,dc=domain",…}
>> 1: {dn: "krbprincipalname=dogtag/ipa01.domain@REALM,cn=services,cn=a
>> ccounts,dc=domain",…}
>> 2: {dn: "krbprincipalname=nfs/profil01.domain@REALM,cn=services,cn=a
>> ccounts,dc=domain",…}
>> 3: {dn: "krbprincipalname=cifs/rhellxudv02.domain@REALM,cn=services,
>> cn=accounts,dc=domain",…}
>> 4: {dn: "krbprincipalname=dogtag/ipa02.domain@REALM,cn=services,cn=a
>> ccounts,dc=domain",…}
>> 5: {dn: "krbprincipalname=HTTP/ipa01.domain@REALM,cn=services,cn=acc
>> ounts,dc=domain",…}
>> 6: {dn: "krbprincipalname=cifs/ipa02.domain@REALM,cn=services,cn=acc
>> ounts,dc=domain",…}
>> 7: {dn: "krbprincipalname=cifs/ipa01.domain@REALM,cn=services,cn=acc
>> ounts,dc=domain",…}
>> 8: {dn: "krbprincipalname=ldap/ipa01.domain@REALM,cn=services,cn=acc
>> ounts,dc=domain",…}
>> 9: {dn: "krbprincipalname=HTTP/ipa02.domain@REALM,cn=services,cn=acc
>> ounts,dc=domain",…}
>> 10: {dn: "krbprincipalname=ldap/ipa02.domain@REALM,cn=services,cn=acc
>> ounts,dc=domain",…}
>> summary: "11 services matched"
>> truncated: false
>>
>>
>>
>> So this is obviously only a web-ui problem, but I can't see what causes
>> 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
>>
>
>
-- 
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] Services missing in web-ui

[Fujisan]

I have the same issue with version 4.4.2

$ rpm -qa|grep freeipa
freeipa-server-4.4.2-1.fc25.x86_64
freeipa-python-compat-4.4.2-1.fc25.noarch
freeipa-server-common-4.4.2-1.fc25.noarch
freeipa-common-4.4.2-1.fc25.noarch
freeipa-server-trust-ad-4.4.2-1.fc25.x86_64
freeipa-client-4.4.2-1.fc25.x86_64
freeipa-client-common-4.4.2-1.fc25.noarch


​F.​


On Wed, Dec 7, 2016 at 11:13 AM, Troels Hansen  wrote:

> I have a strange issue in IPA 4.4.0-12 (RHEL 7.3)
>
>
> Navigating to Identity -> Services reveals 5 services. 2 cifs, 2 dogtag
> and one empty line...
>
> cifs/host1.domain@REALM
> cifs/host2.domain@REALM
> dogtag/ipa01.domain@REALM
> dogtag/ipa02.domain@REALM
>
>
>
> However, from CLI everything looks OK:
>
> # ipa service-find
> ---
> 11 services matched
> ---
> Principal name: ldap/ipa02.domain@REALM
> Principal alias: ldap/ipa02.domain@REALM
> Certificate: ...
> ...
>
>
> Keytab: True
>
> Principal name: ldap/ipa01.domain@REALM
> Principal alias: ldap/ipa01.domain@REALM
> Certificate: ...
> ...
>
>
> Keytab: True
>
> Principal name: HTTP/ipa02.domain@REALM
> Principal alias: HTTP/ipa02.domain@REALM
> Certificate: 
> ...
>
>
>
> Keytab: True
>
> Principal name: cifs/rhellxudv01.domain@REALM
> Principal alias: cifs/rhellxudv01.domain@REALM
> Keytab: True
>
>
>
> Principal name: cifs/ipa02.domain@REALM
> Principal alias: cifs/ipa02.domain@REALM
> Keytab: True
>
>
>
> Principal name: nfs/profil01.domain@REALM
> Principal alias: nfs/profil01.domain@REALM
> Keytab: True
>
>
>
> Principal name: cifs/ipa01.domain@REALM
> Principal alias: cifs/ipa01.domain@REALM
> Keytab: True
>
> Principal name: dogtag/ipa02.domain@REALM
> Principal alias: dogtag/ipa02.domain@REALM
> Keytab: True
>
>
>
> Principal name: dogtag/ipa01.domain@REALM
> Principal alias: dogtag/ipa01.domain@REALM
> Keytab: True
>
>
>
> Principal name: cifs/rhellxudv02.domain@REALM
> Principal alias: cifs/rhellxudv02.domain@REALM
> Keytab: True
>
>
>
> Principal name: HTTP/ipa01.domain@REALM
> Principal alias: HTTP/ipa01.domain@REALM
> Certificate: ..
> ..
> Keytab: True
>
>
>
> -
> Number of entries returned 11
> -
>
>
>
>
> (some lines truncated.)
>
>
> s... somsthing must be disrupting the view in web-ui,
>
>
> Tried in Chrome 43 and IE 11
>
>
> Looking at what gets requested by the browser at /ipa/session/json I can
> see in the json that it gets the correct content:
>
>
> result: {count: 11, result: [,…], summary: "11 services matched",
> truncated: false}
> count: 11
> result: [,…]
> 0: {dn: "krbprincipalname=cifs/rhellxudv01.domain@REALM,cn=services,
> cn=accounts,dc=domain",…}
> 1: {dn: "krbprincipalname=dogtag/ipa01.domain@REALM,cn=services,cn=
> accounts,dc=domain",…}
> 2: {dn: "krbprincipalname=nfs/profil01.domain@REALM,cn=services,cn=
> accounts,dc=domain",…}
> 3: {dn: "krbprincipalname=cifs/rhellxudv02.domain@REALM,cn=services,
> cn=accounts,dc=domain",…}
> 4: {dn: "krbprincipalname=dogtag/ipa02.domain@REALM,cn=services,cn=
> accounts,dc=domain",…}
> 5: {dn: "krbprincipalname=HTTP/ipa01.domain@REALM,cn=services,cn=acc
> ounts,dc=domain",…}
> 6: {dn: "krbprincipalname=cifs/ipa02.domain@REALM,cn=services,cn=acc
> ounts,dc=domain",…}
> 7: {dn: "krbprincipalname=cifs/ipa01.domain@REALM,cn=services,cn=acc
> ounts,dc=domain",…}
> 8: {dn: "krbprincipalname=ldap/ipa01.domain@REALM,cn=services,cn=acc
> ounts,dc=domain",…}
> 9: {dn: "krbprincipalname=HTTP/ipa02.domain@REALM,cn=services,cn=acc
> ounts,dc=domain",…}
> 10: {dn: "krbprincipalname=ldap/ipa02.domain@REALM,cn=services,cn=acc
> ounts,dc=domain",…}
> summary: "11 services matched"
> truncated: false
>
>
>
> So this is obviously only a web-ui problem, but I can't see what causes
> 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
>
-- 
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] Services missing in web-ui

[Troels Hansen]

I have a strange issue in IPA 4.4.0-12 (RHEL 7.3) 




Navigating to Identity -> Services reveals 5 services. 2 cifs, 2 dogtag and one 
empty line... 

cifs/host1.domain@REALM 
cifs/host2.domain@REALM 
dogtag/ipa01.domain@REALM 
dogtag/ipa02.domain@REALM 







However, from CLI everything looks OK: 

# ipa service-find 
--- 
11 services matched 
--- 
Principal name: ldap/ipa02.domain@REALM 
Principal alias: ldap/ipa02.domain@REALM 
Certificate: ... 
... 


Keytab: True 

Principal name: ldap/ipa01.domain@REALM 
Principal alias: ldap/ipa01.domain@REALM 
Certificate: ... 
... 


Keytab: True 

Principal name: HTTP/ipa02.domain@REALM 
Principal alias: HTTP/ipa02.domain@REALM 
Certificate:  
... 







Keytab: True 

Principal name: cifs/rhellxudv01.domain@REALM 
Principal alias: cifs/rhellxudv01.domain@REALM 
Keytab: True 





Principal name: cifs/ipa02.domain@REALM 
Principal alias: cifs/ipa02.domain@REALM 
Keytab: True 





Principal name: nfs/profil01.domain@REALM 
Principal alias: nfs/profil01.domain@REALM 
Keytab: True 





Principal name: cifs/ipa01.domain@REALM 
Principal alias: cifs/ipa01.domain@REALM 
Keytab: True 

Principal name: dogtag/ipa02.domain@REALM 
Principal alias: dogtag/ipa02.domain@REALM 
Keytab: True 





Principal name: dogtag/ipa01.domain@REALM 
Principal alias: dogtag/ipa01.domain@REALM 
Keytab: True 





Principal name: cifs/rhellxudv02.domain@REALM 
Principal alias: cifs/rhellxudv02.domain@REALM 
Keytab: True 





Principal name: HTTP/ipa01.domain@REALM 
Principal alias: HTTP/ipa01.domain@REALM 
Certificate: .. 
.. 
Keytab: True 







- 
Number of entries returned 11 
- 










(some lines truncated.) 



s... somsthing must be disrupting the view in web-ui, 


Tried in Chrome 43 and IE 11 




Looking at what gets requested by the browser at /ipa/session/json I can see in 
the json that it gets the correct content: 





result: {count: 11, result: [,…], summary: "11 services matched", truncated: 
false} 
count: 11 
result: [,…] 
0: {dn: 
"krbprincipalname=cifs/rhellxudv01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 
1: {dn: 
"krbprincipalname=dogtag/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 
2: {dn: 
"krbprincipalname=nfs/profil01.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 
3: {dn: 
"krbprincipalname=cifs/rhellxudv02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 
4: {dn: 
"krbprincipalname=dogtag/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…}
 
5: {dn: 
"krbprincipalname=HTTP/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…} 
6: {dn: 
"krbprincipalname=cifs/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…} 
7: {dn: 
"krbprincipalname=cifs/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…} 
8: {dn: 
"krbprincipalname=ldap/ipa01.domain@REALM,cn=services,cn=accounts,dc=domain",…} 
9: {dn: 
"krbprincipalname=HTTP/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…} 
10: {dn: 
"krbprincipalname=ldap/ipa02.domain@REALM,cn=services,cn=accounts,dc=domain",…} 
summary: "11 services matched" 
truncated: false 







So this is obviously only a web-ui problem, but I can't see what causes 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] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts

[Sumit Bose]

On Tue, Dec 06, 2016 at 03:17:33PM -0500, List dedicated to discussions about 
use, configuration and deployment of the IPA server. wrote:
> 
> Appreciate the assistance!
> 
> Is there a better debug level balance than 10 for this sort of situation?
> The domain logs were several hundred MBs by the time I started looking for
> useful info if there is a different level I can use that would better at
> producing actionable error/log messages I'll gladly switch ...
> 
> 
> List dedicated to discussions about use, configuration and deployment of the
> IPA server. wrote:
> > > (Tue Dec  6 15:36:48 2016) [[sssd[krb5_child[4005 [main] (0x0400):
> > > >  krb5_child started.
> > > >  (Tue Dec  6 15:36:48 2016) [[sssd[krb5_child[4005 [unpack_buffer]
> > > >  (0x1000): total buffer size: [158]
> > > >  (Tue Dec  6 15:36:48 2016) [[sssd[krb5_child[4005 [unpack_buffer]
> > > >  (0x0100): cmd [241] uid [1843770609] gid [1843770609] validate [false]
> > > >  enterprise principal [false] offline [true] UPN [u...@company.org]
> > 
> >^^^
> > 
> > The backend switch to offline mode, please send the SSSD domain logs
> > around this time as well. If possible please start about 5 minutes
> > earlier.
> > 
> > bye,
> > Sumit
> 
> I searched through the massive SSSD domain logs and had trouble finding the
> right area so here are the lines surrounding my own username when I tried to
> authenticate via SSH using AD credentials:
> 
> 
...
> 
...
> [sss_krb5_expire_callback_func] (0x2000): exp_time: [2742397]
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406 [get_and_save_tgt]
> (0x0100): TGT validation is disabled.
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406
> [sss_get_ccache_name_for_principal] (0x4000): Location:
> [KEYRING:persistent:1843770609]
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406
> [sss_get_ccache_name_for_principal] (0x4000): tmp_ccname:
> [KEYRING:persistent:1843770609:krb_ccache_OVBc5zF]
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406 [create_ccache]
> (0x4000): Initializing ccache of type [KEYRING]
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406 [create_ccache]
> (0x4000): CC supports switch
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406 [create_ccache]
> (0x4000): returning: 0
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406
> [safe_remove_old_ccache_file] (0x0400): New and old ccache file are the
> same, none will be deleted.
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406 [k5c_send_data]
> (0x0200): Received error code 0
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406
> [pack_response_packet] (0x2000): response packet size: [144]
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406 [k5c_send_data]
> (0x4000): Response sent.
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406 [main] (0x0400):
> krb5_child completed successfully
...
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417
> [sss_krb5_expire_callback_func] (0x2000): exp_time: [2742394]
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417 [get_and_save_tgt]
> (0x0100): TGT validation is disabled.
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417
> [sss_get_ccache_name_for_principal] (0x4000): Location:
> [KEYRING:persistent:1843770609]
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417
> [sss_get_ccache_name_for_principal] (0x4000): tmp_ccname:
> [KEYRING:persistent:1843770609:krb_ccache_OVBc5zF]
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417 [create_ccache]
> (0x4000): Initializing ccache of type [KEYRING]
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417 [create_ccache]
> (0x4000): CC supports switch
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417 [create_ccache]
> (0x4000): returning: 0
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417
> [safe_remove_old_ccache_file] (0x0400): New and old ccache file are the
> same, none will be deleted.
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417 [k5c_send_data]
> (0x0200): Received error code 0
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417
> [pack_response_packet] (0x2000): response packet size: [144]
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417 [k5c_send_data]
> (0x4000): Response sent.
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417 [main] (0x0400):
> krb5_child completed successfully
> 
> 

Both authentications where successful against the backend. For the logs
it looks like you use an alternative domain suffix on the AD side so
that all user if other domains in the forest can use the forest root
suffix as realm, in the user principal (u...@nafta.company.org ->
u...@company.org).

I would expect that there are messages like "UPN used in the request
...differ by more than just the case." in the domain log at 'Tue Dec  6
19:57:11' and 'Tue Dec  6 19:57:14'.

If that's the case updating to 4.4 would help because in this release
IPA can forward the enterprise 

Re: [Freeipa-users] What should the --hostname option do?

[Martin Basti]

On 07.12.2016 08:48, List dedicated to discussions about use, 
configuration and deployment of the IPA server. wrote:

Hello,

the --hostname option to the installer currently modifies the hostname
of the machine. In some environments, namely in unprivileged
containers, that operation is not denied. In some cases, it is
possible to change the FQDN of the container from outside, for example
with docker run's -h option. However, in some environments, namely in
OpenShift, there is not such possibility.

I have found out that disabling the change by turning /bin/hostnamectl
and /usr/bin/domainname makes ipa-server-install pass while the server
gets configured with the hostname specified as the parameter to
--hostname option so it does not seem to be essential for the FQDN to
change. Of course, some operations might no longer work, like ssh to
the FreeIPA machine as sshd would need to be set with
GSSAPIStrictAcceptorCheck no.

I wonder if either change of the --hostname semantics, or some new
option would be useful, to specify the hostname to be used by the
FreeIPA software while not touching the configuration of the hostname
for the machine.



I agree that --hostname options should not touch system's hostname, I 
don't see reason why application installer should change system hostname.


I'd start with deprecating current behavior of this option in next release

As you mentioned we need find what cases can be broken when we will use 
different local and external hostname, but anyway we have do this for 
containers.


Martin^2

--
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] Reverting anonymous posting

[Simo Sorce]

Enough people complained they cannot cope with the change I made
recently.
So I am reverting this change and will try to find a better solution for
the spam issue the list user's are subject to.

Thanks for your understanding,
Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[freeIPA users list]

On ke, 07 joulu 2016, List dedicated to discussions about use, configuration 
and deployment of the IPA server. wrote:

I know the Quick Start Guide and Deployment Recommendations cover this in
depth, but there are still some ambiguities.

I'm trying to figure out if a company like us, lautus.net should use a DNS
subdomain like ipa.lautus.net for the IPA domain, or not.

It is really depending on your deployment details.

If you already have some other Kerberized environment in place and you
are not going to replace it by FreeIPA, then you need to make sure that
new FreeIPA deployment would not conflict with the existing one.

This is the rule dictated by the way how Kerberos realms are organized
and particularly so for Active Directory deployments as that one has
even more serious limitations towards what can be part of the Active
Directory domain/forest structure.


On the one hand 2.3.1 of the Linux Domain Identity, Authentication, and
Policy Guide says "The integrated DNS server provided by IdM is not
designed to be used as a general-purpose DNS server. It only supports
features related to IdM deployment and maintenance". OK, so lautus.net
should continue to be hosted by DNS servers elsewhere that delegate say,
ipa.lautus.net to FreeIPA.

You definitely can use IPA DNS server for the purpose of hosting your
primary DNS servers if all features provided by IPA DNS server cover
your needs. As I said, it really depends on your specific deployment
considerations. The guide is trying to hint that all things that ISC
BIND supports aren't necessarily will be working in the IPA version --
like a split-horizon feature -- so it is not a general-purpose DNS
server in that sense.


But on the other hand the same doc is full of examples where a Kerberos
realm like EXAMPLE.COM (instead of IPA.EXAMPLE.COM) is used, i.e example
2.2. of secion 2.3.4. But the same guide also says that the Kerberos realm
should be the same as the ipa DNS domain, just uppercased. So example 2.2.
implies that example.com is running their DNS domain on FreeIPA, for
everything, not just for IPA SRV and TXT entries.

It assumes for the most of configurations that you are setting up
FreeIPA as the only Kerberos environment, thus talking about
EXAMPLE.COM.


And when ipa-client-install is run on somehost.lautus.net, it also defaults
to LAUTUS.NET for Kerberos domain, as if the default expectation is that
your toplevel company DNS name would be your kerberos domain.

Yes, as with *any* decent Kerberos implementation.


And when I install a trial IPA server on host ipa-server-1.lautus.net using
"ipa-server-install --setup-dns --realm IPA.LAUTUS.NET --domain
ipa.lautus.net --forwarder=8.8.8.8", and then look at the DNS Zones  in the
Web UI, I see not only ipa.lautus.net, but also lautus, with record "@ NS
ipa-server-1.lautus.net". In other words the IPA server defaults to
thinking it owns the domain above ipa.lautus.net too. Which goes against
2.3.1 above.

Yes and no. What you see with "@ NS ..." is a glue record -- you are
supposed to have a glue record for IPA domain in the upstream domain,
this is how domain delegation works in DNS world.


The docs say I should manually add SRV records to a parent DNS domain like
lautus.net if IPA does not manage that with integrated DNS. But then what's
the point of the integrated DNS, if the docs say the integrated DNS is not
supposed to be used as a general-purpose DNS server? In that case,
everybody is always gonna need to manually add SRV records every time they
add a IPA replication peer anyway, unless they run their company DNS on the
integrated DNS server, which the docs seem to discourage?

See above.

--
/ 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

[Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[List dedicated to discussions about use, configuration and deployment of the IPA server.]

I know the Quick Start Guide and Deployment Recommendations cover this in
depth, but there are still some ambiguities.

I'm trying to figure out if a company like us, lautus.net should use a DNS
subdomain like ipa.lautus.net for the IPA domain, or not.

On the one hand 2.3.1 of the Linux Domain Identity, Authentication, and
Policy Guide says "The integrated DNS server provided by IdM is not
designed to be used as a general-purpose DNS server. It only supports
features related to IdM deployment and maintenance". OK, so lautus.net
should continue to be hosted by DNS servers elsewhere that delegate say,
ipa.lautus.net to FreeIPA.

But on the other hand the same doc is full of examples where a Kerberos
realm like EXAMPLE.COM (instead of IPA.EXAMPLE.COM) is used, i.e example
2.2. of secion 2.3.4. But the same guide also says that the Kerberos realm
should be the same as the ipa DNS domain, just uppercased. So example 2.2.
implies that example.com is running their DNS domain on FreeIPA, for
everything, not just for IPA SRV and TXT entries.

And when ipa-client-install is run on somehost.lautus.net, it also defaults
to LAUTUS.NET for Kerberos domain, as if the default expectation is that
your toplevel company DNS name would be your kerberos domain.

And when I install a trial IPA server on host ipa-server-1.lautus.net using
"ipa-server-install --setup-dns --realm IPA.LAUTUS.NET --domain
ipa.lautus.net --forwarder=8.8.8.8", and then look at the DNS Zones  in the
Web UI, I see not only ipa.lautus.net, but also lautus, with record "@ NS
ipa-server-1.lautus.net". In other words the IPA server defaults to
thinking it owns the domain above ipa.lautus.net too. Which goes against
2.3.1 above.

The docs say I should manually add SRV records to a parent DNS domain like
lautus.net if IPA does not manage that with integrated DNS. But then what's
the point of the integrated DNS, if the docs say the integrated DNS is not
supposed to be used as a general-purpose DNS server? In that case,
everybody is always gonna need to manually add SRV records every time they
add a IPA replication peer anyway, unless they run their company DNS on the
integrated DNS server, which the docs seem to discourage?

-- 
Pieter Nagel
Lautus Solutions (Pty) Ltd
Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng
0832587540
-- 
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