[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

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

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

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.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

-- 
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] can manage user access from Serial Console & only use local users in case cannot reach IPA server ?

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

On Wed, Dec 07, 2016 at 09:57:22AM +0700, List dedicated to discussions about 
use, configuration and deployment of the IPA server. wrote:
> Hi ,
> I'm just testing IPA on CentOS 6, login via ssh is woking fine.
> 
>I would like to try two steps but didnot find any documents-
> 1). can we manage user that access from serial interface.
> 2). in case IPA was failed, can we configure it to use local user

Note that sssd caches user lookups and even credential hashes, so
provided your user logged in at least once before, he would be able to
log in even during a server outage.

-- 
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] Mapping users from AD to IPA KDC

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

On 12/6/2016 3:37 PM, Alexander Bokovoy wrote:

On ti, 06 joulu 2016, TomK wrote:

On 12/5/2016 2:02 AM, Alexander Bokovoy wrote:

On su, 04 joulu 2016, TomK wrote:

Could not get much from logs and decided to start fresh.  When I run
this:

ipa trust-add --type=ad mds.xyz --admin Administrator --password

Trust works fine and id t...@mds.xyz returns a valid result.

However when I run the following on both masters on a fresh new setup:

ipa-adtrust-install --netbios-name=NIX -a ""
ipa trust-add --type=ad "mds.xyz" --trust-secret

and created a trust object in AD DC with the name of NIX and a
non-transitive trust, the above did NOT work.  I didn't get anything
by typing id t...@mds.xyz.  (I do not get an option for a Forest Trust
as the gif on this page suggests:
https://www.freeipa.org/page/Active_Directory_trust_setup .  Possibly
it's Server 2012 hence the difference in what's presented to me but
another reason is that the name I type for the trust can't resolve to
an IP for now: nix.mds.xyz . So I use NIX to match the bios name used
on the ipa-adtrust-install command above.  )

The shared secret case for one-way trust is known to be broken. When a
shared half is created on AD side first, it is marked as not yet valid
by Windows and currently we cannot perform validation of it from IPA
side. Validating it from AD side is not possible as well as we don't
provide all interfaces Windows would like to use.

And the fact you cannot see 'Forest Trust' type of the trust says also
that you have problems with reaching IPA masters from AD DC side for
probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and
UDP).

Nothing I tried in AD Trust creation allowed me to make one with type
Forest.  Just realm.  I recall I had a trust type of Forest but in
trying various options I lost how I did that.  Or perhaps I hadn't
payed attention and it got created indirectly as part of another
action I took.  The domain functional level I'm using is Windows
Server 2008. Using a lower value for testing.

This (inability to chose Forest trust type) simply means AD DC is unable
to probe IPA DC. You said below that SMB port towards IPA DC was closed.

Also make sure to remove incorrect trust from Windows side. While we are
removing a trust object named as our NetBIOS name, it only works for the
proper trusted domain/forests, not for wrong 'realm trust' type.



My IPA version is 4.2 right now.  It came with the CentOS 7.2.
Looking forward to 4.4.  Not sure when you plan to include it as part
of the latest CentOS base.  Indeed some ports were not open (445).
I've adjusted the firewall command accordingly for RHEL 7 / CentOS 7:

for KEY in $(echo "80/tcp 443/tcp 389/tcp 636/tcp 88/tcp 464/tcp
53/tcp 135/tcp 138/tcp 139/tcp 445/tcp 1024-1300/tcp 88/udp 464/udp
53/udp 123/udp 138/udp 139/udp 389/udp 445/udp"); do firewall-cmd
--zone=public --permanent --add-port=$KEY; done

[root@idmipa01 ~]# firewall-cmd --zone=public --list-all
public (default)
 interfaces:
 sources:
 services: dhcpv6-client ntp ssh
 ports: 443/tcp 80/tcp 464/tcp 138/tcp 88/udp 464/udp 445/tcp 88/tcp
135/tcp 123/udp 139/tcp 389/tcp 53/tcp 389/udp 1024-1300/tcp 445/udp
139/udp 138/udp 53/udp 636/tcp
 masquerade: no
 forward-ports:
 icmp-blocks:
 rich rules:

[root@idmipa01 ~]#

On Windows Side (The nslookup results were the same before the
firewall change however.):

Firewall changes cannot affect DNS as you already had DNS port open.


On the AD side, I added the SRV records for the second AD DC,
manually, since earlier there were no results printed on the AD DC
command line for the second AD DC, when I typed the command
_ldap._tcp.mds.xyz.

One additional question I had with the setup is in regards to the
failover.  I see the ipa_server entry in /etc/sssd/sssd.conf pointing
to two of the master IPA nodes.  Where can I find the additional
settings that control priority of the listed server or order they are
checked?

You need to look at SSSD manual pages: sssd-ipa and sssd-ldap, sections
FAILOVER and SERVICE DISCOVER.


What I ran to get the above is:

1) ipa-client-install --force-join -p admin -w ""
--fixed-primary --server=idmipa01.nix.mds.xyz
--server=idmipa02.nix.mds.xyz --domain=nix.mds.xyz --realm=NIX.MDS.XYZ -U
2) realm join mds.xyz

This is wrong. You have effectively joined this IPA client to AD and IPA
at the same time. It should not be done this way (read
http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain
for details).

Instead, you need to identify why the trust does not work properly.
Use tcpdump to intercept the traffic between your AD DCs and IPA DCs
while establishing the trust.

You can send the trace to me off-list.





Ok, let me take these away and get back to you.  ( On realm, thank you. 
Hadn't reviewed the changes it did fully before logging off. )


--
Cheers,
Tom K.
-

Living on earth is expensive, but it includes a 

[Freeipa-users] can manage user access from Serial Console & only use local users in case cannot reach IPA server ?

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

Hi ,
I'm just testing IPA on CentOS 6, login via ssh is woking fine.

   I would like to try two steps but didnot find any documents-
1). can we manage user that access from serial interface.
2). in case IPA was failed, can we configure it to use local user

Best Regards,
sjw
-- 
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] lowest-privilege method of checking for out of sync FreeIPA masters?

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

List dedicated to discussions about use, configuration and deployment of
the IPA server. wrote:
> Hello,
> 
> There's a method to check the replication status of FreeIPA masters by
> looking at objectClass=nsDS5ReplicationAgreement in the "cn=mapping
> tree,cn=config" part of LDAP.
> 
> Unfortunately that requires Directory Admin level privileges.
> 
> Is there a method to check those replication agreement details that uses
> a much lower privilege?  We'd like to add a replication test to our
> Zabbix monitoring system, and we don't want to use the directory admin
> user ID :)

Create a privilege containing the permission "Read Replication
Agreements", add that to a new role, and your user to that role and that
should do it.

rob

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

[Freeipa-users] Made a bit of install progress, next error

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

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: 
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':
'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:
CSR(file='/root/ipa-le/httpd-csr.der',
data='0\x82\x02x0\x82\x01`\x02\x01\x000\x101\x0e0\x0c\x06\x03U\x04\x03\x13\x05ipa-a0\x82\x01"0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\x03\x82\x01\x0f\x000\x82\x01\n\x02\x82\x01\x01\x00\xdau1L\xa6T\xc8\x93\xc0P\x93\xb3\xd2\xcb
\xe2PU\xf0\x94=\x1c\n\x1e\xe5\xfe\xed<\xfa\xb1d-\x92\xebeD\xb1\x0eq9\xf1\xfa\xb5p\xdc\x12qN\x96\x0b\x1f\x13\xab\xae

...

[Freeipa-users] lowest-privilege method of checking for out of sync FreeIPA masters?

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

Hello,

There's a method to check the replication status of FreeIPA masters by
looking at objectClass=nsDS5ReplicationAgreement in the "cn=mapping
tree,cn=config" part of LDAP.

Unfortunately that requires Directory Admin level privileges.

Is there a method to check those replication agreement details that uses a
much lower privilege?  We'd like to add a replication test to our Zabbix
monitoring system, and we don't want to use the directory admin user ID :)

Thanks!

Anthony Clark
-- 
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] Mapping users from AD to IPA KDC

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

On ti, 06 joulu 2016, TomK wrote:

On 12/5/2016 2:02 AM, Alexander Bokovoy wrote:

On su, 04 joulu 2016, TomK wrote:

Could not get much from logs and decided to start fresh.  When I run
this:

ipa trust-add --type=ad mds.xyz --admin Administrator --password

Trust works fine and id t...@mds.xyz returns a valid result.

However when I run the following on both masters on a fresh new setup:

ipa-adtrust-install --netbios-name=NIX -a ""
ipa trust-add --type=ad "mds.xyz" --trust-secret

and created a trust object in AD DC with the name of NIX and a
non-transitive trust, the above did NOT work.  I didn't get anything
by typing id t...@mds.xyz.  (I do not get an option for a Forest Trust
as the gif on this page suggests:
https://www.freeipa.org/page/Active_Directory_trust_setup .  Possibly
it's Server 2012 hence the difference in what's presented to me but
another reason is that the name I type for the trust can't resolve to
an IP for now: nix.mds.xyz . So I use NIX to match the bios name used
on the ipa-adtrust-install command above.  )

The shared secret case for one-way trust is known to be broken. When a
shared half is created on AD side first, it is marked as not yet valid
by Windows and currently we cannot perform validation of it from IPA
side. Validating it from AD side is not possible as well as we don't
provide all interfaces Windows would like to use.

And the fact you cannot see 'Forest Trust' type of the trust says also
that you have problems with reaching IPA masters from AD DC side for
probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and
UDP).
Nothing I tried in AD Trust creation allowed me to make one with type 
Forest.  Just realm.  I recall I had a trust type of Forest but in 
trying various options I lost how I did that.  Or perhaps I hadn't 
payed attention and it got created indirectly as part of another 
action I took.  The domain functional level I'm using is Windows 
Server 2008. Using a lower value for testing.

This (inability to chose Forest trust type) simply means AD DC is unable
to probe IPA DC. You said below that SMB port towards IPA DC was closed.

Also make sure to remove incorrect trust from Windows side. While we are
removing a trust object named as our NetBIOS name, it only works for the
proper trusted domain/forests, not for wrong 'realm trust' type.



My IPA version is 4.2 right now.  It came with the CentOS 7.2.  
Looking forward to 4.4.  Not sure when you plan to include it as part 
of the latest CentOS base.  Indeed some ports were not open (445).  
I've adjusted the firewall command accordingly for RHEL 7 / CentOS 7:


for KEY in $(echo "80/tcp 443/tcp 389/tcp 636/tcp 88/tcp 464/tcp 
53/tcp 135/tcp 138/tcp 139/tcp 445/tcp 1024-1300/tcp 88/udp 464/udp 
53/udp 123/udp 138/udp 139/udp 389/udp 445/udp"); do firewall-cmd 
--zone=public --permanent --add-port=$KEY; done


[root@idmipa01 ~]# firewall-cmd --zone=public --list-all
public (default)
 interfaces:
 sources:
 services: dhcpv6-client ntp ssh
 ports: 443/tcp 80/tcp 464/tcp 138/tcp 88/udp 464/udp 445/tcp 88/tcp 
135/tcp 123/udp 139/tcp 389/tcp 53/tcp 389/udp 1024-1300/tcp 445/udp 
139/udp 138/udp 53/udp 636/tcp

 masquerade: no
 forward-ports:
 icmp-blocks:
 rich rules:

[root@idmipa01 ~]#

On Windows Side (The nslookup results were the same before the 
firewall change however.):

Firewall changes cannot affect DNS as you already had DNS port open.

On the AD side, I added the SRV records for the second AD DC, 
manually, since earlier there were no results printed on the AD DC 
command line for the second AD DC, when I typed the command 
_ldap._tcp.mds.xyz.


One additional question I had with the setup is in regards to the 
failover.  I see the ipa_server entry in /etc/sssd/sssd.conf pointing 
to two of the master IPA nodes.  Where can I find the additional 
settings that control priority of the listed server or order they are 
checked?

You need to look at SSSD manual pages: sssd-ipa and sssd-ldap, sections
FAILOVER and SERVICE DISCOVER.


What I ran to get the above is:

1) ipa-client-install --force-join -p admin -w "" 
--fixed-primary --server=idmipa01.nix.mds.xyz 
--server=idmipa02.nix.mds.xyz --domain=nix.mds.xyz --realm=NIX.MDS.XYZ 
-U

2) realm join mds.xyz

This is wrong. You have effectively joined this IPA client to AD and IPA
at the same time. It should not be done this way (read
http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain
for details).

Instead, you need to identify why the trust does not work properly.
Use tcpdump to intercept the traffic between your AD DCs and IPA DCs
while establishing the trust.

You can send the trace to me off-list.



--
/ Alexander Bokovoy

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

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

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

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:



/var/log/sssd/sssd_DOMAIN.log  (Sanitized)
---
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[be_req_set_domain] (0x0400): Changing request domain from 
[company-idm.org] to [NAFTA.COMPANY.ORG]
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): 
Added timed event "ltdb_callback": 0x7f78cb39e850


(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): 
Added timed event "ltdb_timeout": 0x7f78cb3b7200


(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): 
Running timer event 0x7f78cb39e850 "ltdb_callback"


(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): 
Destroying timer event 0x7f78cb3b7200 "ltdb_timeout"


(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): 
Ending timer event 0x7f78cb39e850 "ltdb_callback"


(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[sdap_id_op_connect_step] (0x4000): reusing cached connection
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[sdap_id_op_connect_step] (0x4000): reusing cached connection
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in 
view [Default Trust View] with filter 
[(&(objectClass=ipaUserOverride)(uid=t859531))].
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[sdap_print_server] (0x2000): Searching 10.127.64.11
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with 
[(&(objectClass=ipaUserOverride)(uid=t859531))][cn=Default Trust 
View,cn=views,cn=accounts,dc=companyidm,dc=org].
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 118
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_op_add] 
(0x2000): New operation 118 timeout 60
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[sdap_process_result] (0x2000): Trace: sh[0x7f78cb2224a0], connected[1], 
ops[0x7f78cb39efa0], ldap[0x7f78cb1cfb40]
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no 
errmsg set
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[sdap_op_destructor] (0x2000): Operation 117 finished
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[ipa_get_ad_override_done] (0x4000): No override found with filter 
[(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-299502267-823518204-725345543-160433))].
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[sdap_id_op_destroy] (0x4000): releasing operation connection
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[sdap_id_op_destroy] (0x4000): releasing operation connection
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success 
(Success)
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[sdap_process_result] (0x2000): Trace: sh[0x7f78cb2224a0], connected[1], 
ops[0x7f78cb39efa0], ldap[0x7f78cb1cfb40]
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no 
errmsg set
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[sdap_op_destructor] (0x2000): Operation 118 finished
(Tue Dec  6 18:24:22 2016) [sssd[be[company-idm.org]]] 
[ipa_get_ad_override_done] (0x4000): No override found with filter 

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

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

On Tue, Dec 06, 2016 at 12:45:18PM -0500, List dedicated to discussions about 
use, configuration and deployment of the IPA server. wrote:
> 
> This is a new thread related to one I started today about upgrading FreeIPA
> software before continuing troubleshooting work ...
> 
> New post here so I don't pollute the other thread.
> 
> 
> 
> Looking for additional eyeballs or tips on this ongoing problem. The short
> summary
> is we can't check passwords for AD users.
> 
> SSSD is running in debug-10 mode and we have tons of logs
> 
> I've got 2 interesting things to trace down, would be interested in feedback
> on
> which may be best to concentrate on ...
> 
> 
> 1. In the SAMBA logs there are very clear and interesting "message=Cannot
> contact any KDC for realm 'COMPANY-IDM.ORG'"
> which seems very straightforward and interesting

you can ignore those, samba is not involved in the authentication.

> 
> 2. However the SSSD logs contain more worrisome messages about TGT ticket
> errors
> 
> 
> Should I concentrate on the samba logs that talk about being unable to find
> the KDC?
> That seems more straightforward at the moment.
> 
> 
> Thanks!
> 
> -Chris
> 
> 
> 
> 
> 
...
> (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

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

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

This is a new thread related to one I started today about upgrading 
FreeIPA software before continuing troubleshooting work ...


New post here so I don't pollute the other thread.



Looking for additional eyeballs or tips on this ongoing problem. The 
short summary

is we can't check passwords for AD users.

SSSD is running in debug-10 mode and we have tons of logs

I've got 2 interesting things to trace down, would be interested in 
feedback on

which may be best to concentrate on ...


1. In the SAMBA logs there are very clear and interesting 
"message=Cannot contact any KDC for realm 'COMPANY-IDM.ORG'"

which seems very straightforward and interesting

2. However the SSSD logs contain more worrisome messages about TGT 
ticket errors



Should I concentrate on the samba logs that talk about being unable to 
find the KDC?

That seems more straightforward at the moment.


Thanks!

-Chris





Basic IDM Setup
---

1. We run COMPANY-IDM.ORG as our IPA server and realm within AWS
2. We operate hosts as company-aws.org (basically IPA clients have 
different DNS domain) in AWS
3. COMPANY-IDM.ORG has 1-way trusts to many remote AD Forests at remote 
corporate sites including COMPANY.ORG




Situation
--
1. Lots of 1-way trusts to COMPANY.ORG via our COMPANY-IDM.ORG IPA server
2. We can enumerate AD users via "id " command
3. Groups, uid etc. all resolvable for AD users
4. As root we can "sudo - u...@nafta.company.org" and it works fine

but ...

5. Anything involving password checking fails (SSH and "sudo - user" as 
non-root)






IPA Server /etc/krb5.conf:

includedir /var/lib/sss/pubconf/krb5.include.d/

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = COMPANY-IDM.ORG
 dns_lookup_realm = true
 dns_lookup_kdc = true
 rdns = false
 ticket_lifetime = 24h
 forwardable = yes
 udp_preference_limit = 0
 default_ccache_name = KEYRING:persistent:%{uid}

[realms]
 COMPANY-IDM.ORG = {
  kdc = usaeilidmp001.company-idm.org:88
  master_kdc = usaeilidmp001.company-idm.org:88
  admin_server = usaeilidmp001.company-idm.org:749
  default_domain = company-idm.org
  pkinit_anchors = FILE:/etc/ipa/ca.crt
}

[dbmodules]
  COMPANY-IDM.ORG = {
db_library = ipadb.so
  }



IPA server /etc/sssd/sssd.conf
--
[domain/company-idm.org]
krb5_validate = false
debug_level = 10
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = company-idm.org
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = usaeilidmp001.company-idm.org
chpass_provider = ipa
ipa_server = usaeilidmp001.company-idm.org
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2

domains = company-idm.org
[nss]
memcache_timeout = 600
homedir_substring = /home

[pam]
debug_level = 10
[sudo]

[autofs]

[ssh]
debug_level = 10

[pac]

[ifp]





/var/log/sssd/krb5_child.log
-
Tue Dec  6 15:36:47 2016) [[sssd[krb5_child[4004 [tgt_req_child] 
(0x1000): Attempting to get a TGT
(Tue Dec  6 15:36:47 2016) [[sssd[krb5_child[4004 [get_and_save_tgt] 
(0x0400): Attempting kinit for realm [COMPANY.ORG]
(Tue Dec  6 15:36:47 2016) [[sssd[krb5_child[4004 
[sss_child_krb5_trace_cb] (0x4000): [4004] 1481038607.821494: Getting 
initial credentials for u...@company.org


(Tue Dec  6 15:36:47 2016) [[sssd[krb5_child[4004 
[sss_child_krb5_trace_cb] (0x4000): [4004] 1481038607.823470: Sending 
request (169 bytes) to COMPANY.ORG


(Tue Dec  6 15:36:48 2016) [[sssd[krb5_child[4004 
[sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.3566: Resolving 
hostname friawadsgc16.company.org.


(Tue Dec  6 15:36:48 2016) [[sssd[krb5_child[4004 
[sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.93116: Sending 
initial UDP request to dgram 15.141.1.63:88


(Tue Dec  6 15:36:48 2016) [[sssd[krb5_child[4004 
[sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.179995: Received 
answer (118 bytes) from dgram 15.141.1.63:88


(Tue Dec  6 15:36:48 2016) [[sssd[krb5_child[4004 
[sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.269806: Response 
was not from master KDC


(Tue Dec  6 15:36:48 2016) [[sssd[krb5_child[4004 
[sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.269869: Received 
error from KDC: -1765328316/Realm not local to KDC


(Tue Dec  6 15:36:48 2016) [[sssd[krb5_child[4004 
[sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.269902: Retrying 
AS request with master KDC


(Tue Dec  6 15:36:48 2016) [[sssd[krb5_child[4004 
[sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.269911: Getting 
initial credentials for u...@company.org


(Tue Dec  6 15:36:48 2016) [[sssd[krb5_child[4004 
[sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.269956: Sending 
request (169 bytes) to COMPANY.ORG (master)


(Tue Dec  6 15:36:48 2016) 

Re: [Freeipa-users] IPA versions for small scale hope-to-be-production use on CentOS 7?

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

On Tue, Dec 06, 2016 at 11:45:18AM -0500, List dedicated to discussions about 
use, configuration and deployment of the IPA server. wrote:
> 
> It's certainly some sort of TGT ticket issue; I just need to find the proper
> bits of log to sanitize and post back to this list. I'll do that under
> another thread though to keep this one clean. Trying to figure out if
> upgrading to 4.3 or even 4.4 would be "wise" on a CentOS-7 system we hope to
> put into production once the password checking problem is resolved for SSH
> users.

I would prefer to look at the sanitize krb5_child.log file first before
saying if updating might help or not. There is one case related to
enterprise principal and alternative domain suffixes on the AD side
where updating to 4.4 would help. But there are other cases related to
ticket validation where updating won't help at all.

bye,
Sumit

> 
> List dedicated to discussions about use, configuration and deployment of the
> IPA server. wrote:
> > In the latter case it might be some general issue with password
> > authentication and the krb5_child.log file with debug_level=10 in the
> > [domain/...] section of sssd.conf might help to find the reason (maybe
> > ticket validation?).
> 
> -- 
> 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] IPA versions for small scale hope-to-be-production use on CentOS 7?

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

It's certainly some sort of TGT ticket issue; I just need to find the 
proper bits of log to sanitize and post back to this list. I'll do that 
under another thread though to keep this one clean. Trying to figure out 
if upgrading to 4.3 or even 4.4 would be "wise" on a CentOS-7 system we 
hope to put into production once the password checking problem is 
resolved for SSH users.


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

In the latter case it might be some general issue with password
authentication and the krb5_child.log file with debug_level=10 in the
[domain/...] section of sssd.conf might help to find the reason (maybe
ticket validation?).


--
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] ns-slapd often hangs on CentOS 7

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

Hello all,

we recently updated our two freeipa clusters to CentOS 7 and both of them
now suffers from often ns-slapd hangs. We use stock CentOS 7.2 packages
with one exception - 389-ds-base-1.3.5.10-11 which comes from RHEL 7.3 together
with backported fix
https://fedorahosted.org/389/changeset/e2bc8fd60bf232cd4c1bc9a6860b7bd570a9dff1/

After update we are facing issue that random nodes in the cluster (we have two
6-nodes clusters) hang and stops to answer and must be manually restarted.
It happens roughly twice a day which is pretty annoying. Symptoms are same every
time, ns-slapd accepts connection but simply keeps it open and doesn't respond.

Package versions: 

# rpm -q 389-ds-base{,-libs,-debuginfo} libdb{,-debuginfo}
389-ds-base-1.3.5.10-11.gdc1.x86_64
389-ds-base-libs-1.3.5.10-11.gdc1.x86_64
389-ds-base-debuginfo-1.3.5.10-11.gdc1.x86_64
libdb-5.3.21-19.el7.x86_64
libdb-debuginfo-5.3.21-19.el7.x86_64

(as I wrote above, that .gdc1 packages are rebuilt RHEL 7.3 packages with above 
fix)

I captured pstack trace & db locks dump (db_stat -h 
/var/lib/dirsrv/slapd-PRODGDC-COM/db -N -CA)
from the hung ns-slapd. Both files are attached.

Do you have any clue where might be the problem? Thank you in advance for
response.

Regards, Adam
Default locking region information:
305 Last allocated locker ID
0x7fff  Current maximum unused locker ID
9   Number of lock modes
150 Initial number of locks allocated
0   Initial number of lockers allocated
150 Initial number of lock objects allocated
1   Maximum number of locks possible
1   Maximum number of lockers possible
1   Maximum number of lock objects possible
707 Current number of locks allocated
293 Current number of lockers allocated
363 Current number of lock objects allocated
30  Number of lock object partitions
8191Size of object hash table
117 Number of current locks
723 Maximum number of locks at any one time
25  Maximum number of locks in any one bucket
1659Maximum number of locks stolen by for an empty partition
89  Maximum number of locks stolen for any one partition
289 Number of current lockers
292 Maximum number of lockers at any one time
115 Number of current lock objects
441 Maximum number of lock objects at any one time
3   Maximum number of lock objects in any one bucket
1132Maximum number of objects stolen by for an empty partition
45  Maximum number of objects stolen for any one partition
19M Total number of locks requested (19374435)
19M Total number of locks released (19367572)
0   Total number of locks upgraded
103 Total number of locks downgraded
1406Lock requests not available due to conflicts, for which we waited
5075Lock requests not available due to conflicts, for which we did not wait
0   Number of deadlocks
0   Lock timeout value
0   Number of locks that have timed out
0   Transaction timeout value
0   Number of transactions that have timed out
2MB 288KB   Region size
2819The number of partition locks that required waiting (0%)
553 The maximum number of times any partition lock was waited for (0%)
0   The number of object queue operations that required waiting (0%)
62  The number of locker allocations that required waiting (0%)
1367The number of region locks that required waiting (0%)
5   Maximum hash bucket length
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lock REGINFO information:
Environment Region type
1   Region ID
/var/lib/dirsrv/slapd-PRODGDC-COM/db/__db.001   Region name
0x7f0ba133b000  Region address
0x7f0ba133b0a0  Region allocation head
0x7f0ba13432b0  Region primary address
0   Region maximum allocation
0   Region allocated
Region allocations: 750942 allocations, 0 failures, 750625 frees, 4 longest
Allocations by power-of-two sizes:
  1KB   750916
  2KB   3
  4KB   7
  8KB   9
 16KB   4
 32KB   1
 64KB   0
128KB   0
256KB   2
512KB   0
1024KB  1
REGION_SHARED   Region flags
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lock region parameters:
2   Lock region region mutex [1367/9417277 0% !Own] 
16381   locker table size
8191object table size
34128   obj_off
888776  locker_off
0   need_dd
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lock conflict matrix:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Locks grouped by lockers:
Locker   Mode  Count Status  - Object ---
   2 dd=288 locks held 1write locks 0pid/thread 
29929/139845097302144 flags 10   priority 100   
   2 READ  1 HELDuserRoot/id2entry.db  handle0
   3 dd=287 locks held 0write locks 0pid/thread 
29929/139844000872192 flags 0priority 100   
   4 dd=286 locks held 1write locks 0pid/thread 
29929/139845097302144 flags 10   priority 100   
   4 READ  1 HELDipaca/id2entry.db handle0
   5 dd=285 

Re: [Freeipa-users] IPA versions for small scale hope-to-be-production use on CentOS 7?

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

On Tue, Dec 06, 2016 at 10:55:12AM -0500, List dedicated to discussions about 
use, configuration and deployment of the IPA server. wrote:
> 
> Still trying to figure out why my AD users in various trusted forests can be
> resolved and "su - " but password checks via SSH logins fail.

Do you call 'su - ' as root or do you get a password prompt
here as well. In case you do it as root, can you try if calling it as
a user will accept the password or not?

In the latter case it might be some general issue with password
authentication and the krb5_child.log file with debug_level=10 in the
[domain/...] section of sssd.conf might help to find the reason (maybe
ticket validation?).

bye,
Sumit

> 
> In the mean time I'm wondering if I should consider upgrading before I go
> much further into the troubleshooting tunnel. It really does seem like there
> has been a ton of action in the codebase specifically relating to AD trusts.
> Maybe I should upgrade first and then keep troubleshooting on the updated
> software. We are not yet in production.
> 
> We have a standard CentOS 7 server running this software set:
> 
> > ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64
> > ipa-server-dns-4.2.0-15.0.1.el7.centos.19.x86_64
> > python-iniparse-0.4-9.el7.noarch
> > sssd-ipa-1.13.0-40.el7_2.12.x86_64
> > ipa-python-4.2.0-15.0.1.el7.centos.19.x86_64
> > ipa-client-4.2.0-15.0.1.el7.centos.19.x86_64
> > ipa-admintools-4.2.0-15.0.1.el7.centos.19.x86_64
> > ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.19.x86_64
> > python-libipa_hbac-1.13.0-40.el7_2.12.x86_64
> > libipa_hbac-1.13.0-40.el7_2.12.x86_64
> 
> Would people generally recommend stepping up to the stable 4.3 release on
> CentOS 7? If so are there any repositories that would be a good source for
> grabbing RPMs?  Is 4.4 still not being recommended for production use?
> 
> Thanks!
> 
> 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

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

[Freeipa-users] IPA versions for small scale hope-to-be-production use on CentOS 7?

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

Still trying to figure out why my AD users in various trusted forests 
can be resolved and "su - " but password checks via SSH logins 
fail.


In the mean time I'm wondering if I should consider upgrading before I 
go much further into the troubleshooting tunnel. It really does seem 
like there has been a ton of action in the codebase specifically 
relating to AD trusts. Maybe I should upgrade first and then keep 
troubleshooting on the updated software. We are not yet in production.


We have a standard CentOS 7 server running this software set:


ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64
ipa-server-dns-4.2.0-15.0.1.el7.centos.19.x86_64
python-iniparse-0.4-9.el7.noarch
sssd-ipa-1.13.0-40.el7_2.12.x86_64
ipa-python-4.2.0-15.0.1.el7.centos.19.x86_64
ipa-client-4.2.0-15.0.1.el7.centos.19.x86_64
ipa-admintools-4.2.0-15.0.1.el7.centos.19.x86_64
ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.19.x86_64
python-libipa_hbac-1.13.0-40.el7_2.12.x86_64
libipa_hbac-1.13.0-40.el7_2.12.x86_64


Would people generally recommend stepping up to the stable 4.3 release 
on CentOS 7? If so are there any repositories that would be a good 
source for grabbing RPMs?  Is 4.4 still not being recommended for 
production use?


Thanks!

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

[Freeipa-users] Problem with autofs

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

Hello,

i have setup an IPA environment using Fedora 24 for the clients
and Scientific Linux 7.2 for the servers.

All clients are mounting NFS4 shares on a central server.

The setup is based on the Red Hat Documentation 
(Red_Hat_Enterprise_Linux-7-Linux_Domain_Identity_Authentication_and_Policy_Guide-en-US).

Everything works well, except one issue:

On the NFS servers i was also using the command ipa-client-automount
to complete the installation process. As i mentioned, it is a
NFS4 server with a basic setup, exports like this:

/export 1xx.xx.xx.0/25(ro,root_squash,sec=krb5i,fsid=0)
/export/appl1xx.xx.xx.0/25(rw,root_squash,sec=krb5i)

But starting the autofs service freezes some parts of the server.
Especially „ls“ is not working and you have to wait a long time
to login. After a while autofs is running. After some days
login is no problem or only sometimes. The same with „ls“.
I never saw NFS problems, this services had no problems.

But the server crashes now every two or four days. Rebooting and
running again. 

Ok, it makes no sense to run autofs on a dedicated NFS server.
So i disabled this service and i had no problems anymore.

But i think, it must be possible to run it. So i think, there
is somewhere a big bug.

So i want to know, is here someone who is running a Kerberized NFS Server
in an IPA environment and also have autofs problems on this server?

I have a lot of core dumps and system messages. I am not able to
analyze them. Of course, i can send them somewhere …

At least i want to know, is this behavior a know bug or is something wrong
with my configuration?

Thanx for any hints.

Detlev


--
  Detlev  | Institut fuer Mikroelektronische Systeme
  Habicht | D-30167 Hannover +49 511 76219662 habi...@ims.uni-hannover.de
  + Handy+49 172 5415752  ---



-- 
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] nfsv4+kerberos: group ID not mapped on newly create users, however user id is correct

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

VERSION: 4.4.0, API_VERSION: 2.213  on rhel7.

ipa server was recently upgraded to version 4.4 from version 4.2 and it seems 
that we are having problems with users created after the upgrade. Of course, it 
could be
something I forgot.

Our environment consist of an hds nfs server, a couple of ipa servers - rhel7 
and a lot of clients - rhel6.  The NFS server is not part of the idm domain, 
i.e. not joined, but of course has a keytab created on the ipa server. The NFS 
server provides common shares, mounted as krb5p on the clients.

All this workes fine and the mapping is correct for all existing users. That 
is, if I log into a client, get a Kerberos ticket for myself and create a file 
on
one of the shares, uid and gid are set to my uid and gid.

But if I create a new user on the ipa server and do the same, the gid on the 
newly created file is "nobody(99)"  whereas the uid is correct.
I have tested with two different users - same result.

klist shows the default principal to be correct.
For user mqm uid=1414 gid=1414, rpc.gssd shows,that after finding the user 
credentials, for some reason there is a switch to machine credentials:


Dec  6 12:17:16 nfsclient rpc.gssd[1607]: handling gssd upcall 
(/var/lib/nfs/rpc_pipefs/nfs/clnt0)
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: handle_gssd_upcall: 'mech=krb5 
uid=1414 enctypes=18,17,16,23,3,1,2 '
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: handling krb5 upcall 
(/var/lib/nfs/rpc_pipefs/nfs/clnt0)
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: process_krb5_upcall: service is 
''
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: getting credentials for client with 
uid 1414 for server jnsa-dnt2.domaine.com
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: CC file 
'/tmp/krb5cc_1622800027_u0vmh1' being considered, with preferred realm 
'DOMAINE.COM'
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: CC file 
'/tmp/krb5cc_1622800027_u0vmh1' owned by 1622800027, not 1414
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_1414_bVlw8x' 
being considered, with preferred realm 'DOMAINE.COM'
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: CC file 
'/tmp/krb5cc_1414_bVlw8x'(m...@domaine.com) passed all checks and has mtime of 
1481022999
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: CC file 
'/tmp/krb5cc_machine_DOMAINE.COM' being considered, with preferred realm 
'DOMAINE.COM'
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: CC file 
'/tmp/krb5cc_machine_DOMAINE.COM' owned by 0, not 1414
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_0' being 
considered, with preferred realm 'DOMAINE.COM'
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_0' owned by 0, 
not 1414
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: using FILE:/tmp/krb5cc_1414_bVlw8x as 
credentials cache for client with uid 1414 for server jnsa-dnt2.domaine.com
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: using environment variable to select 
krb5 ccache FILE:/tmp/krb5cc_1414_bVlw8x
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: creating context using fsuid 1414 
(save_uid 0)
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: creating tcp client for server 
jnsa-dnt2.domaine.com
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: port already set to 2049
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: creating context with server 
n...@jnsa-dnt2.domaine.com
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: serialize_krb5_ctx: lucid 
version!
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: protocol 
1
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: 
serializing key with enctype 18 and size 32
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: doing downcall lifetime_rec 86363
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: handling gssd upcall 
(/var/lib/nfs/rpc_pipefs/nfs/clnt0)
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: handle_gssd_upcall: 'mech=krb5 uid=0 
service=* enctypes=18,17,16,23,3,1,2 '
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: handling krb5 upcall 
(/var/lib/nfs/rpc_pipefs/nfs/clnt0)
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: process_krb5_upcall: service is '*'
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: Full hostname for 
'jnsa-dnt2.domaine.com' is 'jnsa-dnt2.domaine.com'
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: Full hostname for 
'nfsclient.domaine.com' is 'nfsclient.domaine.com'
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for 
nfsclient$@DOMAINE.COM while getting keytab entry for 'nfsclient$@DOMAINE.COM'
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for 
nfsclient$@DOMAINE.COM while getting keytab entry for 'nfsclient$@DOMAINE.COM'
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for 
root/nfsclient.domaine@domaine.com while getting keytab entry for 
'root/nfsclient.domaine@domaine.com'
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for 
nfs/nfsclient.domaine@domaine.com while getting keytab entry for 
'nfs/nfsclient.domaine@domaine.com'
Dec  6 12:17:16 nfsclient rpc.gssd[1607]: Success getting keytab entry 

Re: [Freeipa-users] New IPA Servers

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

On 02.12.2016 17:11, Outback Dingo wrote:

Ok so trying to setup a replca to deploy 2 new freeipa servers on
AWS... migrating from old servers going away, It was suggested to
create a replica then promote it.

this issue is the public ip for the new server is not the same as
the servers IP on AWS...
so which one do i use ???


Hello,

please use internal address otherwise IPA installer checks don't leave 
you to finish installation.


Which version of IPA do you have? if older than 4.4 in domain level 1 
please make sure you set the new CA renewal master to a new server, 
http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Procedure_in_FreeIPA_4.0_or_later


Martin

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

Re: [Freeipa-users] Importing Host Entries from /etc/hosts using sample nis-hosts.sh: Zone name error

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

On 05.12.2016 17:42, Robert Kudyba wrote:


./nis-hosts.sh nisnamesubdomain.ourdomain.edu 



Zone name:
ipa: ERROR: 'name' is required
awk: cmd. line:1: {print $3 "."subdomain.ourdomain.edu 

 
"." nisname ".in-addr.arpa."}

awk: cmd. line:1:  ^ syntax error

Zone name: subdomain
ipa: ERROR: DNS is not configured


Looks to me like the DNS component was not configured in IPA so all the
dns-* commands will fail.


Well I mentioned that we are using the university’s DNS rather than a 
dedicated DNS server on the FreeIPA Fedora server. Where do I 
configure that in the GUI? Since our department does not have 
authority over the ouruniversity.edu  domain 
I figured it was best to use their’s red resolving DNS.





Hello,
you cannot use ipa dns* commands without integrated IPA DNS installed

to add DNS records you have to use the standard way your university 
system provides.


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

[Freeipa-users] Change of list behavior

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

Dear freeipa-users,
due to persisting spam and other issues with DMARC protection, I changed
the list behavior to anonymize the user's address.
We'll experiment with this mode for a little while and see if it works
for the group.
If you have major issues with this mode please write to the list owners
(you can find address and names in the list's mailman page) and we'll
discuss those issues.

Thank you all for participating in this community, hopefully this change
will improve our communication tool.

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