Re: [Freeipa-users] IPA Trusts

[Martin Kosek]

Joshua or Erinn, can either of you please help us improve the docs and file a
bug for the Windows integration guide, about the section you are concerned with?

This is a direct link:
https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207&component=doc-Windows_Integration_Guide

Thank you!
Martin

On 03/16/2015 09:56 PM, Gould, Joshua wrote:
> FWIW, we have IPA working with AD managed DNS. As Alexander mentioned,
> you¹ll need to have DNS properly configured. What I¹ve found is the most
> critical is having the SRV records properly defined for the AD domain and
> the IPA domains. I kind of wish the docs were a bit clearer on which of
> the SRV records were needed. Ex. They list ldap but I didn¹t see any
> mention of kerberos SRV records.
> 
> On 3/16/15, 3:16 PM, "Erinn Looney-Triggs" 
> wrote:
> 
>> On Monday, March 16, 2015 09:13:56 PM Alexander Bokovoy wrote:
>>> On Mon, 16 Mar 2015, Erinn Looney-Triggs wrote:
 Reading through the RHEL 7.1 documents on setting up a trust between
>>> IPA
 and AD I came across a note that IPA had to be managing DNS in order
>>> for
 this to work. Why is this? Is there any way around this? At this point
>>> the
 DNS IPA would manage is DNSSEC signed and as such can't be managed by
>>> IPA,
 it must be managed separately.
>>>
>>> It is unfortunate that documentation turns recommendations into a
>>> mandatory statements. IPA deployment depends heavily on properly
>>> configured DNS and we provide means to maintain DNS server with IPA
>>> tools. This, however, doesn't mean DNS is required to be maintained by
>>> IPA only. Instead, a properly maintained DNS setup is required, not that
>>> it is set up and controlled by IPA means.
>>>
>>> It is easier in many cases to use IPA-managed DNS but if you know what
>>> you are doing, all we ask is to have proper DNS entries in your DNS
>>> infrastructure prior to using IPA commands which require these entries
>>> to exist (or be created, had the DNS infrastructure been managed by
>>> IPA).
>>
>> Ok thanks, I sort of figured that was probably the case, but I wanted to
>> check 
>> to make sure.
>>
>> -Erinn
> 
> 
> 

-- 
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] Saltstack and ipa-install on Centos7 failing

[Martin Kosek]

Looks like a bug, yes. I am just not sure whether in missing Saltstack SELinux
module or the actual SELinux policy. You can try filing a bug to SELinux policy.

Looking at SaltStack Troubleshooting guide, would switching to rpm_script_t 
help?

http://docs.saltstack.com/en/latest/topics/troubleshooting/#salt-and-selinux

On 03/16/2015 05:21 PM, Andrew Holway wrote:
> Hi,
> 
> I think this is perhaps a bug?
> 
> Thanks,
> 
> Andrew
> 
> On 13 March 2015 at 15:55, Andrew Holway  wrote:
> 
>>
>>
>> On 13 March 2015 at 15:33, Michael Lasevich  wrote:
>>
>>> Is SELinux on?
>>>
>> Yes,
>>
>> ipa-server-install is running in the initrc_t domain but I guess its set
>> up to run unconfined
>>
>>
>> ps -Z with ipa-server-install run from salt-stack :
>>
>> system_u:system_r:init_t:s0 root   1568  0.0  1.4 231308 14652 ?
>>   Ss   14:31   0:00 /bin/python2 /usr/bin/salt-minion
>>
>> system_u:system_r:initrc_t:s0   root   3101  1.0  4.8 222004 49232 ?
>>   S14:47   0:01 /usr/bin/python -E /usr/sbin/ipa-server-install
>>
>> ps -Z with ipa-server-install run from console :
>>
>> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 4503 23.7  4.8
>> 323356 48860 pts/1 S+ 14:53   0:00 /usr/bin/python -E
>> /sbin/ipa-server-install
>>
>>
>> On Mar 13, 2015 7:46 AM, "Andrew Holway"  wrote:
>>>
 Hallo

 I have a quite odd situation. I am using saltstack to set up freeipa
 servers on Centos 7 but I am getting the following error:

 failed to create ds instance Command '/usr/sbin/setup-ds.pl --silent
 --logfile - -f /tmp/tmp5witgD' returned non-zero exit status 1

 Saltstack outputs the command it is trying to run:

 ipa-server-install -a password --realm CLOUD.DOMAIN.DE -P password -p
 password -n cloud.domain.de --setup-dns --unattended --no-forwarders

 However if I run this command manually on a clean machine it works fine.

 It works on Centos 6.



 I see this in the slapd error log:

 [root@freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors
 389-Directory/1.3.1.6 B2014.219.1825
 freeipa-2.cloud.native-instruments.de:389
 (/etc/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE)

 [13/Mar/2015:10:45:59 +] - Error - Unable to create
 /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape
 Portable Runtime error -5966 (Access Denied.)
 [13/Mar/2015:10:45:59 +] - Shutting down due to possible conflicts
 with other slapd processes
 [13/Mar/2015:10:45:59 +] - Error - Unable to create
 /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape
 Portable Runtime error -5966 (Access Denied.)
 [13/Mar/2015:10:45:59 +] - Shutting down due to possible conflicts
 with other slapd processes
 [root@freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors | sed
 s/NATIVE-INSTRUMENTS/DOMAIN/g
 389-Directory/1.3.1.6 B2014.219.1825
 freeipa-2.cloud.native-instruments.de:389
 (/etc/dirsrv/slapd-CLOUD-DOMAIN-DE)

 [13/Mar/2015:10:45:59 +] - Error - Unable to create
 /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime
 error -5966 (Access Denied.)
 [13/Mar/2015:10:45:59 +] - Shutting down due to possible conflicts
 with other slapd processes
 [13/Mar/2015:10:45:59 +] - Error - Unable to create
 /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime
 error -5966 (Access Denied.)
 [13/Mar/2015:10:45:59 +] - Shutting down due to possible conflicts
 with other slapd processes







 ipaserver-install.log

 015-03-13T10:45:57Z DEBUG Loading StateFile from
 '/var/lib/ipa/sysrestore/sysrestore.state'
 2015-03-13T10:45:57Z DEBUG Loading Index file from
 '/var/lib/ipa/sysrestore/sysrestore.index'
 2015-03-13T10:45:57Z DEBUG httpd is not configured
 2015-03-13T10:45:57Z DEBUG kadmin is not configured
 2015-03-13T10:45:57Z DEBUG dirsrv is not configured
 2015-03-13T10:45:57Z DEBUG pki-cad is not configured
 2015-03-13T10:45:57Z DEBUG pki-tomcatd is not configured
 2015-03-13T10:45:57Z DEBUG install is not configured
 2015-03-13T10:45:57Z DEBUG krb5kdc is not configured
 2015-03-13T10:45:57Z DEBUG ntpd is not configured
 2015-03-13T10:45:57Z DEBUG named is not configured
 2015-03-13T10:45:57Z DEBUG ipa_memcached is not configured
 2015-03-13T10:45:57Z DEBUG filestore is tracking no files
 2015-03-13T10:45:57Z DEBUG Loading Index file from
 '/var/lib/ipa-client/sysrestore/sysrestore.index'
 2015-03-13T10:45:57Z DEBUG /usr/sbin/ipa-server-install was invoked with
 options: {'reverse_zone': None, 'mkhomedir': False, 'create_sshfp': True,
 'conf_sshd': True, 'conf_ntp': True, 'subject': None, 'no_forwarders':
 True, 'ui_redirect': True, 'domain_name': 'cloud.domain.de', 'idmax':
 0, 'hbac_allow': False, 'no_reverse': False, '

[Freeipa-users] Only one AD user can able to login to IPA server

[Ben .T.George]

HI List

i was following this link :
http://www.freeipa.org/page/Active_Directory_trust_setup#Assumptions
to setup IPA server

my IPA version is 4.1.2

every setps in this tutorials was passed without any error

even "*Allow access for users from AD domain to protected resources*"
went successfully
my current issue is only one user called ben can able to login to ipa
server.please check below:

[root@kwtpocpbis01 ~]# getent passwd b...@infra.com
b...@infra.com:*:531001104:531001104:ben:/home/infra.com/ben:
[root@kwtpocpbis01 ~]# getent passwd bo...@infra.com
[root@kwtpocpbis01 ~]# getent passwd administra...@infra.com
[root@kwtpocpbis01 ~]#

the users ben & bobby are on same group (Domain users). but bobby cannot
able to login to IPA and not getting any information while querying
please help me to fix this issue. i don't know where i need to troubleshoot
this issue.

thanks & Regards,
Ben
-- 
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] Only one AD user can able to login to IPA server

[Jakub Hrozek]

On Tue, Mar 17, 2015 at 11:37:24AM +0300, Ben .T.George wrote:
> HI List
> 
> i was following this link :
> http://www.freeipa.org/page/Active_Directory_trust_setup#Assumptions
> to setup IPA server
> 
> my IPA version is 4.1.2
> 
> every setps in this tutorials was passed without any error
> 
> even "*Allow access for users from AD domain to protected resources*"
> went successfully
> my current issue is only one user called ben can able to login to ipa
> server.please check below:
> 
> [root@kwtpocpbis01 ~]# getent passwd b...@infra.com
> b...@infra.com:*:531001104:531001104:ben:/home/infra.com/ben:
> [root@kwtpocpbis01 ~]# getent passwd bo...@infra.com
> [root@kwtpocpbis01 ~]# getent passwd administra...@infra.com
> [root@kwtpocpbis01 ~]#
> 
> the users ben & bobby are on same group (Domain users). but bobby cannot
> able to login to IPA and not getting any information while querying
> please help me to fix this issue. i don't know where i need to troubleshoot
> this issue.

Can you increase debug_level in both [nss] and [domain] sections on the
server and paste the logs here?

-- 
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] Only one AD user can able to login to IPA server

[Ben .T.George]

HI

i have enabled debug

here is my sssd.conf

[root@kwtpocpbis01 ~]# cat /etc/sssd/sssd.conf
[domain/solaris.local]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = solaris.local
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = kwtpocpbis01.solaris.local
chpass_provider = ipa
ipa_server = kwtpocpbis01.solaris.local
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2

domains = solaris.local
debug_level = 6
[nss]
homedir_substring = /home
debug_level = 6

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]


LOGS:

sssd.log:

(Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging
solaris.local
(Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging nss
(Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging sudo
(Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging pam
(Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging ssh
(Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging pac
(Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service nss
replied to ping
(Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service sudo
replied to ping
(Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service pam
replied to ping
(Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service ssh
replied to ping
(Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service
solaris.local replied to ping
(Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service pac
replied to ping


error_log:

[root@kwtpocpbis01 ~]# tail -f /var/log/httpd/error_log
[Tue Mar 17 11:26:25.458878 2015] [:error] [pid 15175] ipa: INFO: ***
PROCESS START ***
[Tue Mar 17 11:26:25.603536 2015] [:error] [pid 15176] ipa: DEBUG:
session_auth_duration: 0:20:00
[Tue Mar 17 11:26:25.609112 2015] [:error] [pid 15176] ipa: DEBUG:
session_auth_duration: 0:20:00
[Tue Mar 17 11:26:25.655477 2015] [:error] [pid 15176] ipa: DEBUG: Mounting
ipaserver.rpcserver.login_kerberos() at '/session/login_kerberos'
[Tue Mar 17 11:26:25.655597 2015] [:error] [pid 15176] ipa: DEBUG:
session_auth_duration: 0:20:00
[Tue Mar 17 11:26:25.681652 2015] [:error] [pid 15176] ipa: DEBUG: Mounting
ipaserver.rpcserver.login_password() at '/session/login_password'
[Tue Mar 17 11:26:25.681849 2015] [:error] [pid 15176] ipa: DEBUG:
session_auth_duration: 0:20:00
[Tue Mar 17 11:26:25.754351 2015] [:error] [pid 15176] ipa: INFO: ***
PROCESS START ***
p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute
[Tue Mar 17 11:26:28.847563 2015] [:warn] [pid 15377] NSSProtocol:  Unknown
protocol 'tlsv1.2' not supported

secure:
[root@kwtpocpbis01 log]# tail -f secure
Mar 17 12:35:41 kwtpocpbis01 sshd[15714]: subsystem request for sftp by
user root
Mar 17 12:35:44 kwtpocpbis01 sshd[15736]: Accepted password for root from
10.18.2.130 port 64141 ssh2
Mar 17 12:35:44 kwtpocpbis01 sshd[15736]: pam_unix(sshd:session): session
opened for user root by (uid=0)
Mar 17 12:35:44 kwtpocpbis01 sshd[15736]: subsystem request for sftp by
user root
Mar 17 12:39:12 kwtpocpbis01 sshd[14507]: pam_unix(sshd:session): session
closed for user root
Mar 17 12:40:57 kwtpocpbis01 sshd[15816]: Invalid user bo...@infra.com from
10.18.2.130
Mar 17 12:40:57 kwtpocpbis01 sshd[15816]: input_userauth_request: invalid
user bo...@infra.com [preauth]
Mar 17 12:41:02 kwtpocpbis01 sshd[15816]: pam_unix(sshd:auth): check pass;
user unknown
Mar 17 12:41:02 kwtpocpbis01 sshd[15816]: pam_unix(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.18.2.130
Mar 17 12:41:04 kwtpocpbis01 sshd[15816]: Failed password for invalid user
bo...@infra.com from 10.18.2.130 port 64470 ssh2

Mar 17 12:44:56 kwtpocpbis01 sshd[15840]: pam_unix(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.18.2.130  user=b...@infra.com
Mar 17 12:44:57 kwtpocpbis01 sshd[15840]: pam_sss(sshd:auth):
authentication success; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.18.2.130 user=b...@infra.com
Mar 17 12:44:57 kwtpocpbis01 sshd[15840]: Accepted password for
b...@infra.com from 10.18.2.130 port 64782 ssh2
Mar 17 12:44:59 kwtpocpbis01 sshd[15840]: pam_unix(sshd:session): session
opened for user b...@infra.com by (uid=0)



On Tue, Mar 17, 2015 at 12:09 PM, Jakub Hrozek  wrote:

> On Tue, Mar 17, 2015 at 11:37:24AM +0300, Ben .T.George wrote:
> > HI List
> >
> > i was following this link :
> > http://www.freeipa.org/page/Active_Directory_trust_setup#Assumptions
> > to setup IPA server
> >
> > my IPA version is 4.1.2
> >
> > every setps in this tutorials was passed without any error
> >
> > even "*Allow access for users from AD domain to protected resources*"
> > went successfully
> > my current issue is only one user called ben can able to login to ipa
> > server.please check below:
> >
> > [root@kwtpocpbis01 ~]# getent passwd b...@infra.com
> > b...@i

Re: [Freeipa-users] Only one AD user can able to login to IPA server

[Ben .T.George]

another thing i notice is:

[root@kwtpocpbis01 ~]# kinit admin
Password for admin@SOLARIS.LOCAL:
[root@kwtpocpbis01 ~]# ipa trust-fetch-domains infra.com
ipa: DEBUG: importing all plugin modules in
'/usr/lib/python2.7/site-packages/ipalib/plugins'...
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/config.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/group.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/host.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/idviews.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/otpconfig.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken_yubikey.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py'
ipa: DEBUG: Starting external process
ipa: DEBUG: args='klist' '-V'
ipa: DEBUG: Process finished, return code=0
ipa: DEBUG: stdout=Kerberos 5 version 1.12.2

ipa: DEBUG: stderr=
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/radiusproxy.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/role.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/rpcclient.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/service.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/user.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py'
ipa: DEBUG: Starting external process
ipa: DEBUG: args='keyctl' 'search

Re: [Freeipa-users] Only one AD user can able to login to IPA server

[Ben .T.George]

i tried to establish trust again and got below output. Is this the expected
one. i can see " Insufficient access: CIFS server denied your credentials"
here too.



[root@kwtpocpbis01 ~]# ipa trust-add --type=ad infra.com --admin
Administrator --password
ipa: DEBUG: importing all plugin modules in
'/usr/lib/python2.7/site-packages/ipalib/plugins'...
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/config.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/group.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/host.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/idviews.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/otpconfig.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken_yubikey.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py'
ipa: DEBUG: Starting external process
ipa: DEBUG: args='klist' '-V'
ipa: DEBUG: Process finished, return code=0
ipa: DEBUG: stdout=Kerberos 5 version 1.12.2

ipa: DEBUG: stderr=
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/radiusproxy.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/role.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/rpcclient.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/service.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/user.py'
ipa: DEBUG: importing plugin module
'/usr/lib/python2.7/site-package

Re: [Freeipa-users] Only one AD user can able to login to IPA server

[Jakub Hrozek]

On Tue, Mar 17, 2015 at 12:57:27PM +0300, Ben .T.George wrote:
> HI
> 
> i have enabled debug
> 
> here is my sssd.conf
> 
> [root@kwtpocpbis01 ~]# cat /etc/sssd/sssd.conf
> [domain/solaris.local]
> 
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = solaris.local
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = kwtpocpbis01.solaris.local
> chpass_provider = ipa
> ipa_server = kwtpocpbis01.solaris.local
> ipa_server_mode = True
> ldap_tls_cacert = /etc/ipa/ca.crt

Please also add debug_level to this section, not just [sssd] and [nss]


> [sssd]
> services = nss, sudo, pam, ssh
> config_file_version = 2
> 
> domains = solaris.local
> debug_level = 6
> [nss]
> homedir_substring = /home
> debug_level = 6
> 
> [pam]
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> [pac]
> 
> [ifp]

-- 
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] Only one AD user can able to login to IPA server

[Ben .T.George]

HI

i have changed like this:

[root@kwtpocpbis01 yum.repos.d]# more /etc/sssd/sssd.conf
[domain/solaris.local]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = solaris.local
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = kwtpocpbis01.solaris.local
chpass_provider = ipa
ipa_server = kwtpocpbis01.solaris.local
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt
debug_level = 10
[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2
debug_level = 5
domains = solaris.local
[nss]
homedir_substring = /home
debug_level = 6

[pam]
debug_level = 10
[sudo]
debug_level = 5
[autofs]
debug_level = 5
[ssh]
debug_level = 5
[pac]
debug_level = 5
[ifp]


but sssd.log looks same.

(Tue Mar 17 14:23:13 2015) [sssd] [ping_check] (0x0100): Service pam
replied to ping
(Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging
solaris.local
(Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging nss
(Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging sudo
(Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging pam
(Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging ssh
(Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging pac
(Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service sudo
replied to ping
(Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service ssh
replied to ping
(Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service pam
replied to ping
(Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service
solaris.local replied to ping
(Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service pac
replied to ping
(Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service nss
replied to ping

On Tue, Mar 17, 2015 at 1:27 PM, Jakub Hrozek  wrote:

> On Tue, Mar 17, 2015 at 12:57:27PM +0300, Ben .T.George wrote:
> > HI
> >
> > i have enabled debug
> >
> > here is my sssd.conf
> >
> > [root@kwtpocpbis01 ~]# cat /etc/sssd/sssd.conf
> > [domain/solaris.local]
> >
> > cache_credentials = True
> > krb5_store_password_if_offline = True
> > ipa_domain = solaris.local
> > id_provider = ipa
> > auth_provider = ipa
> > access_provider = ipa
> > ipa_hostname = kwtpocpbis01.solaris.local
> > chpass_provider = ipa
> > ipa_server = kwtpocpbis01.solaris.local
> > ipa_server_mode = True
> > ldap_tls_cacert = /etc/ipa/ca.crt
>
> Please also add debug_level to this section, not just [sssd] and [nss]
>
>
> > [sssd]
> > services = nss, sudo, pam, ssh
> > config_file_version = 2
> >
> > domains = solaris.local
> > debug_level = 6
> > [nss]
> > homedir_substring = /home
> > debug_level = 6
> >
> > [pam]
> >
> > [sudo]
> >
> > [autofs]
> >
> > [ssh]
> >
> > [pac]
> >
> > [ifp]
>
-- 
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] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds)

[Martin Kosek]

On 03/16/2015 08:01 PM, Benjamin Reed wrote:
> So given my RHEL6 machine started on an older FreeIPA 3.0, was a
> self-signed cert, and has gone through all kinds of hell and I'm having
> an impossible time setting up new master(s), I've decided to start over.
> 
> I installed the EPEL7 FreeIPA 4.1.3 RPMs, in the hopes that being on the
> latest would give me the best chance at migrating.
> 
> I did the following:
> 
> --- 8< ---
> ipa-server-install
> ipa config-mod --enable-migration=true
> ipa-compat-manage disable
> service ipa restart # ipa-compat-manage wants a restart
> ipa migrate-ds \
> --bind-dn=uid=admin,cn=users,cn=accounts,dc=XXX,dc=XXX \

Note that this Bind DN will not migrate passwords at all, as admin does not
have the privilege to *read* userPassword attribute by design. You need to
migrate using Directory Manager.

> --user-container=cn=users,cn=accounts \
> --group-container=cn=groups,cn=accounts \
> --group-overwrite-gid \
> ldap://XXX:389
> ipa-compat-manage enable
> ipa-config-mod --enable-mogration=false

As Dmitri mentioned, this should not be done before password migration is over.

> service ipa restart
> --- 8< ---
> 
> It all seems to have (kinda) worked, I can log in to the UI as admin and
> see all of my users and groups.  There are a couple of snags.
> 
> 1. When the migration completed, it said:
> 
>> Passwords have been migrated in pre-hashed format.
>> IPA is unable to generate Kerberos keys unless provided
>> with clear text passwords. All migrated users need to
>> login at https://your.domain/ipa/migration/ before they
>> can use their Kerberos accounts.
> 
> If I try to actually do this as a regular user, the web UI just says:
> 
>> The password or username you entered is incorrect. Please try again
>> (make sure your caps lock is off).
>> If the problem persists, contact your administrator.
> 
> I'm not sure where to look in the logs to figure out what's going on,
> but nothing in the kerberos logs jump out at me.  The dirsrv log has these:
> 
>> [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password
>> Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should
>> be added before the CoS Definition.
>> [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password
>> Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should
>> be added before the CoS Definition.
> 
> ...which seems fishy.

The problem here is that migrate-ds is designed to migrate users from general
LDAP, usually without Kerberos integration. However, you are migrating from
FreeIPA LDAP with full Kerberos support and the already generated Kerberos keys.

You thus need to do a small tweaking of migrate-ds options to filter
already-generated kerberos keys from the old FreeIPA instance and to also let
it migrate private user groups.

This is what I did to migrate users from my RHEL-6 test VM to FreeIPA 4.1.3:

# ipa config-mod --enable-migration=true

# echo Secret123 | ipa migrate-ds --bind-dn="cn=Directory Manager"
--user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts
--group-objectclass=posixgroup
--user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference}
--with-compat ldap://vm-086.rhel-6.test
---
migrate-ds:
---
Migrated:
  user: fbar, non-upg
  group: fbar
Failed user:
  admin: This entry already exists
Failed group:
  admins: This entry already exists. Check GID of the existing group. Use
--group-overwrite-gid option to overwrite the GID
  editors: This entry already exists. Check GID of the existing group. Use
--group-overwrite-gid option to overwrite the GID
  ipausers: This entry already exists. Check GID of the existing group. Use
--group-overwrite-gid option to overwrite the GID
--
Passwords have been migrated in pre-hashed format.
IPA is unable to generate Kerberos keys unless provided
with clear text passwords. All migrated users need to
login at https://your.domain/ipa/migration/ before they
can use their Kerberos accounts.

This migrated both fbar and non-pug users, with fbar's UPG and with 
userPassword:

# ipa user-show fbar --all --raw
  dn: uid=fbar,cn=users,cn=accounts,dc=f21
  uid: fbar
  givenname: Foo
  sn: Bar
  cn: Foo Bar
  initials: FB
  homedirectory: /home/fbar
  gecos: Foo Bar
  loginshell: /bin/sh
  mail: f...@idm.lab.bos.redhat.com
  uidnumber: 187381
  gidnumber: 187381
  nsaccountlock: FALSE
  has_password: TRUE
  has_keytab: FALSE
  displayName: Foo Bar
  ipaUniqueID: fa9a125e-cc92-11e4-9bbd-001a4a104e33
  krbPrincipalName: fbar@F21
  memberofindirect: cn=ipausers,cn=groups,cn=accounts,dc=f21
  mepManagedEntry: cn=fbar,cn=groups,cn=accounts,dc=f21
  objectClass: ipasshgroupofpubkeys
  objectClass: ipaobject
  objectClass: meporiginentry
  objectClass: organizationalperson
  objectClass: top
  objectClass: ipasshuser
  objec

Re: [Freeipa-users] Only one AD user can able to login to IPA server

[Ben .T.George]

Oops sorry
here is the logs

==> sssd_pam.log <==
(Tue Mar 17 14:33:23 2015) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn:
0x7fdea7263bd0
(Tue Mar 17 14:33:23 2015) [sssd[pam]] [sbus_dispatch] (0x4000):
Dispatching.
(Tue Mar 17 14:33:23 2015) [sssd[pam]] [sbus_message_handler] (0x4000):
Received SBUS method [ping]
(Tue Mar 17 14:33:23 2015) [sssd[pam]] [sbus_get_sender_id_send] (0x2000):
Not a sysbus message, quit
(Tue Mar 17 14:33:23 2015) [sssd[pam]] [sbus_handler_got_caller_id]
(0x4000): Received SBUS method [ping]

==> sssd.log <==
(Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service
solaris.local replied to ping
(Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service pac
replied to ping
(Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service sudo
replied to ping
(Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service ssh
replied to ping
(Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service pam
replied to ping
(Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service nss
replied to ping

==> sssd_nss.log <==
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running
command [17] with input [bo...@infra.com].
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_parse_name_for_domains]
(0x0200): name 'bo...@infra.com' matched expression for domain 'infra.com',
user is bobby
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
Requesting info for [bobby] from [infra.com]
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
Requesting info for [bo...@infra.com]
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x7f426adbfb50:1:bo...@infra.com]
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [infra.com][4097][1][name=bobby]
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x7f426adbfb50:1:bo...@infra.com]

==> sssd_solaris.local.log <==
(Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch]
(0x4000): dbus conn: 0x7f6b7d2a5140
(Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch]
(0x4000): Dispatching.
(Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_message_handler]
(0x4000): Received SBUS method [getAccountInfo]
(Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]]
[sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
(Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]]
[sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo]
(Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_account_info]
(0x0200): Got request for [0x1001][1][name=bobby]
(Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_account_info]
(0x0100): Request processed. Returned 1,11,Fast reply - offline
(Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_req_set_domain]
(0x0400): Changing request domain from [solaris.local] to [infra.com]

==> sssd_nss.log <==
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getby_dp_callback]
(0x0040): Unable to get information from Data Provider
Error: 1, 11, Fast reply - offline
Will try to return what we have in cache
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x7f426adbfb50:1:bo...@infra.com]
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running
command [17] with input [bo...@infra.com].
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_parse_name_for_domains]
(0x0200): name 'bo...@infra.com' matched expression for domain 'infra.com',
user is bobby
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
Requesting info for [bobby] from [infra.com]
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100):
Requesting info for [bo...@infra.com]
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x7f426adbfb50:1:bo...@infra.com]
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [infra.com][4097][1][name=bobby]
(Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x7f426adbfb50:1:bo...@infra.com]

==> sssd_solaris.local.log <==
(Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch]
(0x4000): dbus conn: 0x7f6b7d2a5140
(Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch]
(0x4000): Dispatching.
(Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_message_handler]
(0x4000): Received SBUS method [getAccountInfo]
(Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]]
[sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
(Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]]
[sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo]
(Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_account_info]
(0x0200): Got request for [0x1001][1][name=bobby]
(Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_ac

Re: [Freeipa-users] Only one AD user can able to login to IPA server

[Jakub Hrozek]

On Tue, Mar 17, 2015 at 02:38:41PM +0300, Ben .T.George wrote:
> here is separated logs:
> 
> tail -f sssd_solaris.local.log

Thank you, see inline:

> (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_tgt_recv]
> (0x0400): Child responded: 14 [Decrypt integrity check failed], expired on
> [0]
> (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_kinit_done]
> (0x0100): Could not get TGT: 14 [Bad address]
> (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_cli_kinit_done]
> (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed)
> (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status]
> (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'not
> working'
> (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status]
> (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local'
> as 'not working'
> (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_handle_release]
> (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[(nil)],
> ldap[0x7f6b7d265a00], destructor_lock[0], release_memory[0]
> (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]]
> [remove_connection_callback] (0x4000): Successfully removed connection
> callback.
> (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]]
> [check_online_callback] (0x0100): Backend returned: (3, 0, )
> [Internal Error (Success)]

So it seems the keytab is wrong, you can also test the keytab validity
with "kinit -k"..

-- 
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] Only one AD user can able to login to IPA server

[Ben .T.George]

Hi

i did kinit

[root@kwtpocpbis01 sssd]# kinit -kt /etc/dirsrv/ds.keytab
kinit: Keytab contains no suitable keys for
host/kwtpocpbis01.solaris.local@SOLARIS.LOCAL while getting initial
credentials


i destroyed and re-created. but still same



On Tue, Mar 17, 2015 at 2:45 PM, Jakub Hrozek  wrote:

> On Tue, Mar 17, 2015 at 02:38:41PM +0300, Ben .T.George wrote:
> > here is separated logs:
> >
> > tail -f sssd_solaris.local.log
>
> Thank you, see inline:
>
> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_tgt_recv]
> > (0x0400): Child responded: 14 [Decrypt integrity check failed], expired
> on
> > [0]
> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_kinit_done]
> > (0x0100): Could not get TGT: 14 [Bad address]
> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]]
> [sdap_cli_kinit_done]
> > (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed)
> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status]
> > (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'not
> > working'
> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status]
> > (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local'
> > as 'not working'
> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]]
> [sdap_handle_release]
> > (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[(nil)],
> > ldap[0x7f6b7d265a00], destructor_lock[0], release_memory[0]
> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]]
> > [remove_connection_callback] (0x4000): Successfully removed connection
> > callback.
> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]]
> > [check_online_callback] (0x0100): Backend returned: (3, 0, )
> > [Internal Error (Success)]
>
> So it seems the keytab is wrong, you can also test the keytab validity
> with "kinit -k"..
>
-- 
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] DNS forwarders

[Roberto Cornacchia]

Hi there,

I've just installed freeIPA on a FC21 server and trying to perform some
sanity checks.

A first puzzle for me is: I have some DNS forwarders, which I selected
during installation.
They do work and they do appear in /etc/named.conf

  forward first;
forwarders {
217.21.244.7;
217.21.244.66;
8.8.8.8;
8.8.4.4;
};

However, I don't see them as DNS forwarders in IPA? Should I see them?

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

Re: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA

[Dan Lavu]

I was helping a friend out with his environment that was experiencing the same 
issue. CC'ing him as well. 

Between his ipa servers, the conflicted values were the same just time stamp 
that created the conflict? (I'm still not sure what caused the conflict in the 
first place). So what we did to fix the issue was to modify the entries and 
remove the conflict. You can follow this guide, 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
 and with a simple script we were able to clean up the conflicts. 

Then SSSD started working again as soon as these conflicts were cleaned up, 
just make sure the values are the same between both servers otherwise you may 
be updating the environment with old data. Let me know if you have specific 
questions. 

Dan 


- Original Message -

From: "Jakub Hrozek"  
To: "Andreas Skarmutsos Lindh"  
Cc: freeipa-users@redhat.com, "Dan Lavu"  
Sent: Monday, March 16, 2015 5:37:16 PM 
Subject: Re: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA 


> On 16 Mar 2015, at 22:03, Andreas Skarmutsos Lindh  
> wrote: 
> 
> Hi everyone, 
> 
> After upgrading (using rpm, yum upgrade) I can no longer login to my machines 
> using ssh. Before the upgrade everything was working fine. 
> 
> Some loose facts: 
> - I'm installing IPA packages from the RHEL repositories onto RHEL systems, 
> so I'm not sure if this is the right mailing list to ask for assistance 
> - I have a basic setup of IPA with minimum rules (deleted HBAC rules to 
> single that out), using SSSD+PAM. 
> - Both other machines that are upgraded to a more recent version of sssd and 
> it's fellow packages and servers which was not yum upgraded are affected by 
> the issue, thus, everything seems to point at IPA. 
> - I'm able to obtain a kerberos ticket via kinit 
> - Running the following package version: ipa-server-4.1.0-18.el7.x86_64 
> 
> SSH returns (adding -vvv hardly tells me anything useful): 
> Connection closed by UNKNOWN 
> 
> I think that I have boiled down the issue to the following.. 
> Both clients with upgraded sssd (1.12.2-58) and non upgraded clients 
> (1.11.2-65) give me the following output in sssd_.log: 
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_eval_user_element] 
> (0x0080): Parse error on [cn=Modify PassSync Managers 
> Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com]
>  
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_ctx_to_rules] 
> (0x0020): Could not construct eval request 
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [ipa_hbac_evaluate_rules] 
> (0x0020): Could not construct HBAC rules 
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] 
> (0x0100): Backend returned: (3, 4, ) [Internal Error (System error)] 
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] 
> (0x0100): Sending result [4][domain.com] 
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] 
> (0x0100): Sent result [4][domain.com] 
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] 
> (0x2000): Trace: sh[0x7f5711099220], connected[1], ops[(nil)], 
> ldap[0x7f571108d0e0] 
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] 
> (0x2000): Trace: ldap_result found nothing! 
> 

This is a combination of a broken replication on the server side and too strict 
SSSD processing which can't handle unexpected entries. The broken replication 
has yielded entries like: 
cn=Modify PassSync Managers 
Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com]
 
note the nsUniqueID. As I learned today, entries with nsUniqueID in the RDN are 
relicts of broken replication. 

Dan Lavu (CC) has helped another setup with the same symtoms recently, maybe he 
can help here as well? 

The SSSD should just skip malformed entries if no DENY rules are used. That is 
tracked by SSSD ticket #2603. I have local patches for that one and I'll send 
them out to the list tomorrow. 

> I'm happy to attach more logs if needed. 
> I would very much like to avoid rolling back to an older IPA version by 
> reinstalling everything from scratch. 
> Any and all help would be very much appreciated. 
> 
> Thanks in advance, 
> Andreas 
> -- 
> 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] 4.1.0: Logon issue after upgrading IPA

[Andreas Skarmutsos Lindh]

Thanks, I'll look into that. Would you mind sharing the script used to
clean up the entries? That would save me some time.
Not expecting anything that I can run blindly and that will magically solve
my problems, but some hints would definitely be appreciated :-)


- Andreas

On Mon, Mar 16, 2015 at 11:24 PM, Dan Lavu  wrote:

> I was helping a friend out with his environment that was experiencing the
> same issue. CC'ing him as well.
>
> Between his ipa servers, the conflicted values were the same just time
> stamp that created the conflict? (I'm still not sure what caused the
> conflict in the first place). So what we did to fix the issue was to modify
> the entries and remove the conflict. You can follow this guide,
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
> and with a simple script we were able to clean up the conflicts.
>
> Then SSSD started working again as soon as these conflicts were cleaned
> up, just make sure the values are the same between both servers otherwise
> you may be updating the environment with old data. Let me know if you have
> specific questions.
>
> Dan
>
>
> --
> *From: *"Jakub Hrozek" 
> *To: *"Andreas Skarmutsos Lindh" 
> *Cc: *freeipa-users@redhat.com, "Dan Lavu" 
> *Sent: *Monday, March 16, 2015 5:37:16 PM
> *Subject: *Re: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA
>
>
>
> > On 16 Mar 2015, at 22:03, Andreas Skarmutsos Lindh <
> andr...@superblock.se> wrote:
> >
> > Hi everyone,
> >
> > After upgrading (using rpm, yum upgrade) I can no longer login to my
> machines using ssh. Before the upgrade everything was working fine.
> >
> > Some loose facts:
> > - I'm installing IPA packages from the RHEL repositories onto RHEL
> systems, so I'm not sure if this is the right mailing list to ask for
> assistance
> > - I have a basic setup of IPA with minimum rules (deleted HBAC rules to
> single that out), using SSSD+PAM.
> > - Both other machines that are upgraded to a more recent version of sssd
> and it's fellow packages and servers which was not yum upgraded are
> affected by the issue, thus, everything seems to point at IPA.
> > - I'm able to obtain a kerberos ticket via kinit
> > - Running the following package version: ipa-server-4.1.0-18.el7.x86_64
> >
> > SSH returns (adding -vvv hardly tells me anything useful):
> > Connection closed by UNKNOWN
> >
> > I think that I have boiled down the issue to the following..
> > Both clients with upgraded sssd (1.12.2-58) and non upgraded clients
> (1.11.2-65) give me the following output in sssd_.log:
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]]
> [hbac_eval_user_element] (0x0080): Parse error on [cn=Modify PassSync
> Managers
> Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com]
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_ctx_to_rules]
> (0x0020): Could not construct eval request
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]]
> [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]]
> [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, )
> [Internal Error (System error)]
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]]
> [be_pam_handler_callback] (0x0100): Sending result [4][domain.com]
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]]
> [be_pam_handler_callback] (0x0100): Sent result [4][domain.com]
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result]
> (0x2000): Trace: sh[0x7f5711099220], connected[1], ops[(nil)],
> ldap[0x7f571108d0e0]
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result]
> (0x2000): Trace: ldap_result found nothing!
> >
>
> This is a combination of a broken replication on the server side and too
> strict SSSD processing which can't handle unexpected entries. The broken
> replication has yielded entries like:
> cn=Modify PassSync Managers
> Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com]
> note the nsUniqueID. As I learned today, entries with nsUniqueID in the
> RDN are relicts of broken replication.
>
> Dan Lavu (CC) has helped another setup with the same symtoms recently,
> maybe he can help here as well?
>
> The SSSD should just skip malformed entries if no DENY rules are used.
> That is tracked by SSSD ticket #2603. I have local patches for that one and
> I'll send them out to the list tomorrow.
>
> > I'm happy to attach more logs if needed.
> > I would very much like to avoid rolling back to an older IPA version by
> reinstalling everything from scratch.
> > Any and all help would be very much appreciated.
> >
> > Thanks in advance,
> > Andreas
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to htt

Re: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA

[Andreas Skarmutsos Lindh]

Quick update: I think that I have solved it, by just deleting the entries
holding nsuniqueid additional string. I went forward using a gui
application for browsing LDAP structures.
I guess a script for tackling this issue in a slightly more automated way
could probably be of value to other people.

Thanks a lot for the help & support guys


- Andreas

On Mon, Mar 16, 2015 at 11:24 PM, Dan Lavu  wrote:

> I was helping a friend out with his environment that was experiencing the
> same issue. CC'ing him as well.
>
> Between his ipa servers, the conflicted values were the same just time
> stamp that created the conflict? (I'm still not sure what caused the
> conflict in the first place). So what we did to fix the issue was to modify
> the entries and remove the conflict. You can follow this guide,
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
> and with a simple script we were able to clean up the conflicts.
>
> Then SSSD started working again as soon as these conflicts were cleaned
> up, just make sure the values are the same between both servers otherwise
> you may be updating the environment with old data. Let me know if you have
> specific questions.
>
> Dan
>
>
> --
> *From: *"Jakub Hrozek" 
> *To: *"Andreas Skarmutsos Lindh" 
> *Cc: *freeipa-users@redhat.com, "Dan Lavu" 
> *Sent: *Monday, March 16, 2015 5:37:16 PM
> *Subject: *Re: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA
>
>
>
> > On 16 Mar 2015, at 22:03, Andreas Skarmutsos Lindh <
> andr...@superblock.se> wrote:
> >
> > Hi everyone,
> >
> > After upgrading (using rpm, yum upgrade) I can no longer login to my
> machines using ssh. Before the upgrade everything was working fine.
> >
> > Some loose facts:
> > - I'm installing IPA packages from the RHEL repositories onto RHEL
> systems, so I'm not sure if this is the right mailing list to ask for
> assistance
> > - I have a basic setup of IPA with minimum rules (deleted HBAC rules to
> single that out), using SSSD+PAM.
> > - Both other machines that are upgraded to a more recent version of sssd
> and it's fellow packages and servers which was not yum upgraded are
> affected by the issue, thus, everything seems to point at IPA.
> > - I'm able to obtain a kerberos ticket via kinit
> > - Running the following package version: ipa-server-4.1.0-18.el7.x86_64
> >
> > SSH returns (adding -vvv hardly tells me anything useful):
> > Connection closed by UNKNOWN
> >
> > I think that I have boiled down the issue to the following..
> > Both clients with upgraded sssd (1.12.2-58) and non upgraded clients
> (1.11.2-65) give me the following output in sssd_.log:
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]]
> [hbac_eval_user_element] (0x0080): Parse error on [cn=Modify PassSync
> Managers
> Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com]
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_ctx_to_rules]
> (0x0020): Could not construct eval request
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]]
> [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]]
> [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, )
> [Internal Error (System error)]
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]]
> [be_pam_handler_callback] (0x0100): Sending result [4][domain.com]
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]]
> [be_pam_handler_callback] (0x0100): Sent result [4][domain.com]
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result]
> (0x2000): Trace: sh[0x7f5711099220], connected[1], ops[(nil)],
> ldap[0x7f571108d0e0]
> > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result]
> (0x2000): Trace: ldap_result found nothing!
> >
>
> This is a combination of a broken replication on the server side and too
> strict SSSD processing which can't handle unexpected entries. The broken
> replication has yielded entries like:
> cn=Modify PassSync Managers
> Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com]
> note the nsUniqueID. As I learned today, entries with nsUniqueID in the
> RDN are relicts of broken replication.
>
> Dan Lavu (CC) has helped another setup with the same symtoms recently,
> maybe he can help here as well?
>
> The SSSD should just skip malformed entries if no DENY rules are used.
> That is tracked by SSSD ticket #2603. I have local patches for that one and
> I'll send them out to the list tomorrow.
>
> > I'm happy to attach more logs if needed.
> > I would very much like to avoid rolling back to an older IPA version by
> reinstalling everything from scratch.
> > Any and all help would be very much appreciated.
> >
> > Thanks in advance,
> > Andreas
> > --
> > Manage your subscription for the Freeipa-users mailing

Re: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA

[Ludwig Krispenz]

Hi,

do you have the DS access logs from your servers from the time around 
the conflicting entry was created ?


Thanks,
Ludwig

On 03/17/2015 11:14 AM, Andreas Skarmutsos Lindh wrote:
Quick update: I think that I have solved it, by just deleting the 
entries holding nsuniqueid additional string. I went forward using a 
gui application for browsing LDAP structures.
I guess a script for tackling this issue in a slightly more automated 
way could probably be of value to other people.


Thanks a lot for the help & support guys


- Andreas

On Mon, Mar 16, 2015 at 11:24 PM, Dan Lavu > wrote:


I was helping a friend out with his environment that was
experiencing the same issue. CC'ing him as well.

Between his ipa servers, the conflicted values were the same just
time stamp that created the conflict? (I'm still not sure what
caused the conflict in the first place). So what we did to fix the
issue was to modify the entries and remove the conflict. You can
follow this guide,

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
and with a simple script we were able to clean up the conflicts.

Then SSSD started working again as soon as these conflicts were
cleaned up, just make sure the values are the same between both
servers otherwise you may be updating the environment with old
data. Let me know if you have specific questions.

Dan



*From: *"Jakub Hrozek" mailto:jhro...@redhat.com>>
*To: *"Andreas Skarmutsos Lindh" mailto:andr...@superblock.se>>
*Cc: *freeipa-users@redhat.com ,
"Dan Lavu" mailto:dl...@redhat.com>>
*Sent: *Monday, March 16, 2015 5:37:16 PM
*Subject: *Re: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA



> On 16 Mar 2015, at 22:03, Andreas Skarmutsos Lindh
mailto:andr...@superblock.se>> wrote:
>
> Hi everyone,
>
> After upgrading (using rpm, yum upgrade) I can no longer login
to my machines using ssh. Before the upgrade everything was
working fine.
>
> Some loose facts:
> - I'm installing IPA packages from the RHEL repositories onto
RHEL systems, so I'm not sure if this is the right mailing list to
ask for assistance
> - I have a basic setup of IPA with minimum rules (deleted HBAC
rules to single that out), using SSSD+PAM.
> - Both other machines that are upgraded to a more recent version
of sssd and it's fellow packages and servers which was not yum
upgraded are affected by the issue, thus, everything seems to
point at IPA.
> - I'm able to obtain a kerberos ticket via kinit
> - Running the following package version:
ipa-server-4.1.0-18.el7.x86_64
>
> SSH returns (adding -vvv hardly tells me anything useful):
> Connection closed by UNKNOWN
>
> I think that I have boiled down the issue to the following..
> Both clients with upgraded sssd (1.12.2-58) and non upgraded
clients (1.11.2-65) give me the following output in sssd_.log:
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com
]]] [hbac_eval_user_element] (0x0080): Parse
error on [cn=Modify PassSync Managers

Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com]
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com
]]] [hbac_ctx_to_rules] (0x0020): Could not
construct eval request
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com
]]] [ipa_hbac_evaluate_rules] (0x0020): Could
not construct HBAC rules
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com
]]] [be_pam_handler_callback] (0x0100): Backend
returned: (3, 4, ) [Internal Error (System error)]
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com
]]] [be_pam_handler_callback] (0x0100): Sending
result [4][domain.com ]
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com
]]] [be_pam_handler_callback] (0x0100): Sent
result [4][domain.com ]
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com
]]] [sdap_process_result] (0x2000): Trace:
sh[0x7f5711099220], connected[1], ops[(nil)], ldap[0x7f571108d0e0]
> (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com
]]] [sdap_process_result] (0x2000): Trace:
ldap_result found nothing!
>

This is a combination of a broken replication on the server side
and too strict SSSD processing which can't handle unexpected
entries. The broken replication has yielded entries like:
cn=Modify PassSync Managers

Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,d

Re: [Freeipa-users] DNS forwarders

[Martin Basti]

On 17/03/15 13:32, Roberto Cornacchia wrote:

Hi there,

I've just installed freeIPA on a FC21 server and trying to perform 
some sanity checks.


A first puzzle for me is: I have some DNS forwarders, which I selected 
during installation.

They do work and they do appear in /etc/named.conf

  forward first;
forwarders {
217.21.244.7;
217.21.244.66;
8.8.8.8;
8.8.4.4;
};

However, I don't see them as DNS forwarders in IPA? Should I see them?

Roberto



Hello,

if you want to see them in IPA, you must add those forwarders with IPA 
command


ipa dnsconfig-mod --forwarder=8.8.4.4 --forwarder=8.8.8.8 ...
or using webUI

This setting will override configuration of forwarders in named.conf.

I don't know if there are some historical reasons to configure 
forwarders only in named.conf during installation, do you know Petr?


--
Martin Basti

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

Re: [Freeipa-users] DNS forwarders

[Petr Spacek]

On 17.3.2015 14:06, Martin Basti wrote:
> On 17/03/15 13:32, Roberto Cornacchia wrote:
>> Hi there,
>>
>> I've just installed freeIPA on a FC21 server and trying to perform some
>> sanity checks.
>>
>> A first puzzle for me is: I have some DNS forwarders, which I selected
>> during installation.
>> They do work and they do appear in /etc/named.conf
>>
>>   forward first;
>> forwarders {
>> 217.21.244.7;
>> 217.21.244.66;
>> 8.8.8.8;
>> 8.8.4.4;
>> };
>>
>> However, I don't see them as DNS forwarders in IPA? Should I see them?
>>
>> Roberto
>>
>>
> Hello,
> 
> if you want to see them in IPA, you must add those forwarders with IPA command
> 
> ipa dnsconfig-mod --forwarder=8.8.4.4 --forwarder=8.8.8.8 ...
> or using webUI
> 
> This setting will override configuration of forwarders in named.conf.
> 
> I don't know if there are some historical reasons to configure forwarders only
> in named.conf during installation, do you know Petr?

This is done for practical purposes. In cases where you have multiple IPA
servers scatted across the globe you most likely do not want to use the same
set of forwarders for all IPA DNS servers - usually you want to use nearest
forwarder possible.

'ipa dnsconfig' is global for the whole cluster, /etc/named.conf is local for
that particular server.

It would be nice to move per-server configuration to LDAP to make it available
via IPA user interface but up to know it did not get priority.

-- 
Petr^2 Spacek

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

[Freeipa-users] Unknown Client?

[Tevfik Ceydeliler]

Hi,
Altough I have this configuration in client .conf:

##
client 172.30.47.241 {
   secret  = 877909
   shortname   = VodafonePinarsuAPNYeni1
   nastype = other
}

client 172.30.47.242 {
   secret  = 877909
   shortname   = VodafonePinarsuAPNYeni2
   nastype = other
}



Why I get this error?

#

Tue Mar 17 14:31:55 2015 : Error: Ignoring request to authentication 
address * port 1812 from unknown client 172.30.47.242 port 58312
Tue Mar 17 14:32:01 2015 : Error: Ignoring request to authentication 
address * port 1812 from unknown client 172.30.47.241 port 6040


#

And I am sure that secret is correct.
Any idea?
Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece 
adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi 
ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi 
dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar 
ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail 
and any files transmitted with it are intended solely for the use of the 
individual or entity to whom they are addressed and Yasar Group Companies do 
not accept legal responsibility for the contents. If you are not the intended 
recipient, please immediately notify the sender and delete it from your system.


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

[Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID

[Guertin, David S.]

We have a trust relationship established between our AD domain and our IPA 
domain, and AD users can be found on the IPA server with id and getent passwd. 
When a user tries to SSH to the IPA server with AD credentials, the logs show:


(Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_save_user] 
(0x0400): Processing user guertin-s
(Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_save_user] 
(0x1000): Mapping user [guertin-s] objectSID 
[S-1-5-21-1983215674-46037090-646806464-245906] to unix ID
(Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_idmap_sid_to_unix] 
(0x0080): Could not convert objectSID 
[S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID

It seems that this is a problem with the ID range, but I can't see where the 
problem is. We increased the default ranges of 200,000 to 2,000,000, which I 
would think should be able to handle a RID of 245906:


# ipa idrange-find --all

2 ranges matched

  dn: 
cn=CSNS.MIDDLEBURY.EDU_id_range,cn=ranges,cn=etc,dc=csns,dc=middlebury,dc=edu
  Range name: CSNS.MIDDLEBURY.EDU_id_range
  First Posix ID of the range: 182460
  Number of IDs in the range: 200
  First RID of the corresponding RID range: 1000
  First RID of the secondary RID range: 1
  Range type: local domain range
  iparangetyperaw: ipa-local
  objectclass: top, ipaIDrange, ipaDomainIDRange

  dn: cn=MIDDLEBURY.EDU_id_range,cn=ranges,cn=etc,dc=csns,dc=middlebury,dc=edu
  Range name: MIDDLEBURY.EDU_id_range
  First Posix ID of the range: 1
  Number of IDs in the range: 200
  Domain SID of the trusted domain: S-1-5-21-1983215674-46037090-646806464
  Range type: Active Directory trust range with POSIX attributes
  iparangetyperaw: ipa-ad-trust-posix
  objectclass: ipatrustedaddomainrange, ipaIDrange

Number of entries returned 2


But the error remains. What am I missing?

David Guertin
-- 
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] Unknown Client?

[Rob Crittenden]

Tevfik Ceydeliler wrote:
> Hi,
> Altough I have this configuration in client .conf:
> 
> ##
> client 172.30.47.241 {
>secret  = 877909
>shortname   = VodafonePinarsuAPNYeni1
>nastype = other
> }
> 
> client 172.30.47.242 {
>secret  = 877909
>shortname   = VodafonePinarsuAPNYeni2
>nastype = other
> }
> 
> 
> 
> Why I get this error?
> 
> #
> 
> 
> Tue Mar 17 14:31:55 2015 : Error: Ignoring request to authentication
> address * port 1812 from unknown client 172.30.47.242 port 58312
> Tue Mar 17 14:32:01 2015 : Error: Ignoring request to authentication
> address * port 1812 from unknown client 172.30.47.241 port 6040
> 
> #

How is this related to IPA?

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] pki-tomcatd stopped responding? Won't restart?

[Janelle]

Hello,

I have a server - a master (has CA) - and it does not want to restart 
after it has been running sometime. pki-tomcatd keeps failing. It starts 
up with these errors, then adds a lot more. Maybe this might point you 
to something that is know or a place I can start looking?


Any ideas?
~J

Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule 
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property 'enableOCSP' to 'false' did not find a matching property.


Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule 
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property 'ocspResponderURL' to 
'http://ipa-server.example.com:9080/ca/ocsp' did not find a matching 
property.


Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule 
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property 'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' 
did not find a matching property.


Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule 
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property 'ocspCacheSize' to '1000' did not find a matching property.


Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule 
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property 'ocspMinCacheEntryDuration' to '60' did not find a matching 
property.


Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule 
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property 'ocspMaxCacheEntryDuration' to '120' did not find a matching 
property.


Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule 
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property 'ocspTimeout' to '10' did not find a matching property.


Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule 
begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property 'strictCiphers' to 'true' did not find a matching property.
Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule 
begin


WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property 'sslOptions' to 'ssl2=true,ssl3=true,tls=true' did not find a 
matching property.


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

Re: [Freeipa-users] DNS forwarders

[Roberto Cornacchia]

I see. Peter, Martin, thanks for the explanation. My worry was that
something went wrong in my reinstallation, glad to hear it is not the case.

Roberto
On 17 Mar 2015 14:51, "Petr Spacek"  wrote:

> On 17.3.2015 14:06, Martin Basti wrote:
> > On 17/03/15 13:32, Roberto Cornacchia wrote:
> >> Hi there,
> >>
> >> I've just installed freeIPA on a FC21 server and trying to perform some
> >> sanity checks.
> >>
> >> A first puzzle for me is: I have some DNS forwarders, which I selected
> >> during installation.
> >> They do work and they do appear in /etc/named.conf
> >>
> >>   forward first;
> >> forwarders {
> >> 217.21.244.7;
> >> 217.21.244.66;
> >> 8.8.8.8;
> >> 8.8.4.4;
> >> };
> >>
> >> However, I don't see them as DNS forwarders in IPA? Should I see them?
> >>
> >> Roberto
> >>
> >>
> > Hello,
> >
> > if you want to see them in IPA, you must add those forwarders with IPA
> command
> >
> > ipa dnsconfig-mod --forwarder=8.8.4.4 --forwarder=8.8.8.8 ...
> > or using webUI
> >
> > This setting will override configuration of forwarders in named.conf.
> >
> > I don't know if there are some historical reasons to configure
> forwarders only
> > in named.conf during installation, do you know Petr?
>
> This is done for practical purposes. In cases where you have multiple IPA
> servers scatted across the globe you most likely do not want to use the
> same
> set of forwarders for all IPA DNS servers - usually you want to use nearest
> forwarder possible.
>
> 'ipa dnsconfig' is global for the whole cluster, /etc/named.conf is local
> for
> that particular server.
>
> It would be nice to move per-server configuration to LDAP to make it
> available
> via IPA user interface but up to know it did not get priority.
>
> --
> Petr^2 Spacek
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID

[Alexander Bokovoy]

On Tue, 17 Mar 2015, Guertin, David S. wrote:

We have a trust relationship established between our AD domain and our IPA 
domain, and AD users can be found on the IPA server with id and getent passwd. 
When a user tries to SSH to the IPA server with AD credentials, the logs show:


(Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_save_user] 
(0x0400): Processing user guertin-s
(Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_save_user] 
(0x1000): Mapping user [guertin-s] objectSID 
[S-1-5-21-1983215674-46037090-646806464-245906] to unix ID
(Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_idmap_sid_to_unix] 
(0x0080): Could not convert objectSID 
[S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID

It seems that this is a problem with the ID range, but I can't see where the 
problem is. We increased the default ranges of 200,000 to 2,000,000, which I 
would think should be able to handle a RID of 245906:


# ipa idrange-find --all

2 ranges matched

 dn: 
cn=CSNS.MIDDLEBURY.EDU_id_range,cn=ranges,cn=etc,dc=csns,dc=middlebury,dc=edu
 Range name: CSNS.MIDDLEBURY.EDU_id_range
 First Posix ID of the range: 182460
 Number of IDs in the range: 200
 First RID of the corresponding RID range: 1000
 First RID of the secondary RID range: 1
 Range type: local domain range
 iparangetyperaw: ipa-local
 objectclass: top, ipaIDrange, ipaDomainIDRange

 dn: cn=MIDDLEBURY.EDU_id_range,cn=ranges,cn=etc,dc=csns,dc=middlebury,dc=edu
 Range name: MIDDLEBURY.EDU_id_range
 First Posix ID of the range: 1
 Number of IDs in the range: 200
 Domain SID of the trusted domain: S-1-5-21-1983215674-46037090-646806464
 Range type: Active Directory trust range with POSIX attributes
 iparangetyperaw: ipa-ad-trust-posix
 objectclass: ipatrustedaddomainrange, ipaIDrange

Number of entries returned 2


But the error remains. What am I missing?

When you changed idrange, it helps to remove SSSD cache, both on IPA
master and IPA clients and restart SSSD.

--
/ 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] 4.1.0: Logon issue after upgrading IPA

[Martin Kosek]

On 03/17/2015 11:14 AM, Andreas Skarmutsos Lindh wrote:
> Quick update: I think that I have solved it, by just deleting the entries
> holding nsuniqueid additional string. I went forward using a gui
> application for browsing LDAP structures.
> I guess a script for tackling this issue in a slightly more automated way
> could probably be of value to other people.

I am glad to see the problem resolved. FYI, the pending upstrema request to
have more automated way of handling replication conflicts is

https://fedorahosted.org/freeipa/ticket/1025

You can add yourself to CC list of you are interested in the updates (or even
contribute help/patches :-)

-- 
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] pki-tomcatd stopped responding? Won't restart?

[Martin Kosek]

On 03/17/2015 04:35 PM, Janelle wrote:
> Hello,
> 
> I have a server - a master (has CA) - and it does not want to restart after it
> has been running sometime. pki-tomcatd keeps failing. It starts up with these
> errors, then adds a lot more. Maybe this might point you to something that is
> know or a place I can start looking?
> 
> Any ideas?
> ~J
> 
> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'enableOCSP' to 'false' did not find a matching property.
> 
> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'ocspResponderURL' to 'http://ipa-server.example.com:9080/ca/ocsp' did not 
> find
> a matching property.
> 
> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not find a
> matching property.
> 
> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'ocspCacheSize' to '1000' did not find a matching property.
> 
> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'ocspMinCacheEntryDuration' to '60' did not find a matching property.
> 
> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'ocspMaxCacheEntryDuration' to '120' did not find a matching property.
> 
> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'ocspTimeout' to '10' did not find a matching property.
> 
> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'strictCiphers' to 'true' did not find a matching property.
> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
> 
> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'sslOptions' to 'ssl2=true,ssl3=true,tls=true' did not find a matching 
> property.
> 

CCing folks from Dogtag team to know about this issue. However, I think you
will need to provide more information before we continue with issues - like
version of FreeIPA, pki-ca packages, what system you are running it on
(Fedora/RHEL/CentOS/...) and maybe whole logs pasted somewhere (system and
catalina.out logs are usually most interesting ones).

-- 
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] pki-tomcatd stopped responding? Won't restart?

[Janelle]

On 3/17/15 9:06 AM, Martin Kosek wrote:

On 03/17/2015 04:35 PM, Janelle wrote:

Hello,

I have a server - a master (has CA) - and it does not want to restart after it
has been running sometime. pki-tomcatd keeps failing. It starts up with these
errors, then adds a lot more. Maybe this might point you to something that is
know or a place I can start looking?

Any ideas?
~J

Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'enableOCSP' to 'false' did not find a matching property.

Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspResponderURL' to 'http://ipa-server.example.com:9080/ca/ocsp' did not find
a matching property.

Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not find a
matching property.

Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspCacheSize' to '1000' did not find a matching property.

Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspMinCacheEntryDuration' to '60' did not find a matching property.

Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspMaxCacheEntryDuration' to '120' did not find a matching property.

Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspTimeout' to '10' did not find a matching property.

Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'strictCiphers' to 'true' did not find a matching property.
Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin

WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'sslOptions' to 'ssl2=true,ssl3=true,tls=true' did not find a matching property.


CCing folks from Dogtag team to know about this issue. However, I think you
will need to provide more information before we continue with issues - like
version of FreeIPA, pki-ca packages, what system you are running it on
(Fedora/RHEL/CentOS/...) and maybe whole logs pasted somewhere (system and
catalina.out logs are usually most interesting ones).

My bad --

CentOS 7
FreeIPA 4.1.3 from mosek

The strange thing is -- 12 other servers - 3 of which are CA masters and 
no issues,


~J

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

Re: [Freeipa-users] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds)

[Martin Kosek]

On 03/17/2015 04:27 PM, Benjamin Reed wrote:
> On 3/17/15 7:33 AM, Martin Kosek wrote:
>> # ipa config-mod --enable-migration=true
>>
>> # echo Secret123 | ipa migrate-ds --bind-dn="cn=Directory Manager"
>> --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts
>> --group-objectclass=posixgroup
>> --user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference}
>> --with-compat ldap://vm-086.rhel-6.test
> 
> Confirmed, this works PERFECTLY.
> 
> It'd be great to have it as a simple option in the migrate-ds script.
> 
> Thanks so much for the help!  You saved me a lot of pain.  :)

Ah, good to hear!

I would still wished we fixed the original root cause why replication was
failing for you - as this is the obviously expected way of upgrading to
RHEL/CentOS 7.1 from RHEL-6 environment and I think/hope it would be less work
than starting over (depends on how populated is your existing IPA instance).

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] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds)

[Benjamin Reed]

On 3/17/15 12:09 PM, Martin Kosek wrote:
> I would still wished we fixed the original root cause why replication was
> failing for you - as this is the obviously expected way of upgrading to
> RHEL/CentOS 7.1 from RHEL-6 environment and I think/hope it would be less work
> than starting over (depends on how populated is your existing IPA instance).

Yeah, I totally get that, but I've actually been holding up a product
launch trying to get things working, or I'd try to work through it
longer.  :(

I'm actually going to just shut down the old server's IPA but not
uninstall it, so if there is any progress made on the issue I've opened
I may be able to try it with a fresh replication target still.

I did run into one snag.  Our IPA servers are on the public internet, so
I've disabled anonymous bind.  However, it appears that the
/ipa/migration/ tool requires it; at least, I'm getting this error in
httpd/error_log:

> migration context search failed: Insufficient access: Inappropriate
> authentication: Anonymous access is not allowed.

Is there a way to make migration work without anonymous bind?  A config
file I can change somewhere to force the migration tool to bind as a user?


-- 
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/




signature.asc
Description: OpenPGP digital signature
-- 
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] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds)

[Martin Kosek]

On 03/17/2015 05:16 PM, Benjamin Reed wrote:
> On 3/17/15 12:09 PM, Martin Kosek wrote:
>> I would still wished we fixed the original root cause why replication was
>> failing for you - as this is the obviously expected way of upgrading to
>> RHEL/CentOS 7.1 from RHEL-6 environment and I think/hope it would be less 
>> work
>> than starting over (depends on how populated is your existing IPA instance).
> 
> Yeah, I totally get that, but I've actually been holding up a product
> launch trying to get things working, or I'd try to work through it
> longer.  :(
> 
> I'm actually going to just shut down the old server's IPA but not
> uninstall it, so if there is any progress made on the issue I've opened
> I may be able to try it with a fresh replication target still.

Ok, thank you.

> I did run into one snag.  Our IPA servers are on the public internet, so
> I've disabled anonymous bind.  However, it appears that the
> /ipa/migration/ tool requires it; at least, I'm getting this error in
> httpd/error_log:
> 
>> migration context search failed: Insufficient access: Inappropriate
>> authentication: Anonymous access is not allowed.

I am CCing Peter Vobornik for the UI part. I think you are right. I quickly
checked the code, it indeed does an anonymous search and it also does not use
the CA certificate for TLS authentication when LDAPI is not available.

IMO, a ticket creation is due, to use IPA API object to get the basedn that is
read in the anonymous connection and to also use TLS when LDAPI is not 
available.

> Is there a way to make migration work without anonymous bind?  A config
> file I can change somewhere to force the migration tool to bind as a user?

Hmm, if the migration page is not working for you, I see following options:

1) Migrate users via SSSD and simply SSH or log in to any machine enrolled to
the new IPA, as I showed in the example

2) Implement your own migration tool, doing an LDAP BIND for the migrated user
(this is what SSSD does too anyway).

3) (hackish) Until the potential ticket is fixed, you can try to fix
/usr/share/ipa/migration/migration.py on the IPA server yourself. This is the
migration script that is used. If you actually fix it, you may even think about
contributing the fix to FreeIPA project as a patch, it would be very welcome :-)

-- 
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] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds)

[Benjamin Reed]

On 3/17/15 7:33 AM, Martin Kosek wrote:
> # ipa config-mod --enable-migration=true
>
> # echo Secret123 | ipa migrate-ds --bind-dn="cn=Directory Manager"
> --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts
> --group-objectclass=posixgroup
> --user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference}
> --with-compat ldap://vm-086.rhel-6.test

Confirmed, this works PERFECTLY.

It'd be great to have it as a simple option in the migrate-ds script.

Thanks so much for the help!  You saved me a lot of pain.  :)

-- 
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/




signature.asc
Description: OpenPGP digital signature
-- 
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] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds)

[Benjamin Reed]

On 3/17/15 12:29 PM, Martin Kosek wrote:
> 1) Migrate users via SSSD and simply SSH or log in to any machine enrolled to
> the new IPA, as I showed in the example

I'll have my users who need working kerberos ssh in.  The union of the
set of users who need kerberos and users who ssh is a circle.  ;)

> 2) Implement your own migration tool, doing an LDAP BIND for the migrated user
> (this is what SSSD does too anyway).
>
> 3) (hackish) Until the potential ticket is fixed, you can try to fix
> /usr/share/ipa/migration/migration.py on the IPA server yourself. This is the
> migration script that is used. If you actually fix it, you may even think 
> about
> contributing the fix to FreeIPA project as a patch, it would be very welcome 
> :-)

I looked at the script and I don't know python or how the binding stuff
is set up enough to understand making a patch, but I have at least
created an issue: https://fedorahosted.org/freeipa/ticket/4953

Thanks again for your help.  I've been banging my head on getting away
from our broken old FreeIPA server for quite some time.

-- 
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/




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

Re: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID

[Guertin, David S.]

> When you changed idrange, it helps to remove SSSD cache, both on IPA
> master and IPA clients and restart SSSD.

OK, I cleared the cache and restarted sssd with:

sss_cache -E
systemctl restart sssd

Still no change in the error: Could not convert objectSID 
[S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID

FWIW, here's my sssd.conf:

[domain/csns.middlebury.edu]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = csns.middlebury.edu
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = genet.csns.middlebury.edu
chpass_provider = ipa
ipa_server = genet.csns.middlebury.edu
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt

[domain/middlebury.edu]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
debug_level = 10

[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2
domains = middlebury.edu,csns.middlebury.edu
debug_level = 10

[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]
#debug_level = 10

[pac]

[ifp]

This is RHEL 7 running sssd-1.12.2 and ipa-server-4.1.0.

Thanks for any suggestions.

David Guertin

-- 
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] Unknown Client?

[Natxo Asenjo]

On Tue, Mar 17, 2015 at 4:19 PM, Tevfik Ceydeliler <
tevfik.ceydeli...@astron.yasar.com.tr> wrote:

> Hi,
> Altough I have this configuration in client .conf:
>
> ##
> client 172.30.47.241 {
>secret  = 877909
>shortname   = VodafonePinarsuAPNYeni1
>nastype = other
> }
>
> client 172.30.47.242 {
>secret  = 877909
>shortname   = VodafonePinarsuAPNYeni2
>nastype = other
> }
>
> 
>
> Why I get this error?
>
> 
> #
>
> Tue Mar 17 14:31:55 2015 : Error: Ignoring request to authentication
> address * port 1812 from unknown client 172.30.47.242 port 58312
> Tue Mar 17 14:32:01 2015 : Error: Ignoring request to authentication
> address * port 1812 from unknown client 172.30.47.241 port 6040
>
> 
> #
>  


I think you should post your question to the free*radius* mailing list ;-)

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

Re: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID

[Alexander Bokovoy]

On Tue, 17 Mar 2015, Guertin, David S. wrote:

When you changed idrange, it helps to remove SSSD cache, both on IPA
master and IPA clients and restart SSSD.


OK, I cleared the cache and restarted sssd with:

sss_cache -E
systemctl restart sssd

Still no change in the error: Could not convert objectSID
[S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID

I don't think sss_cache -E removes cached idrange objects. You need to
delete the databases in /var/lib/sss/db/.


This is RHEL 7 running sssd-1.12.2 and ipa-server-4.1.0.

You mean RHEL 7.1, right?
--
/ 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] Unknown Client?

[Brendan Kearney]

On Tue, 2015-03-17 at 18:07 +0100, Natxo Asenjo wrote:
> 
> 
> On Tue, Mar 17, 2015 at 4:19 PM, Tevfik Ceydeliler
>  wrote:
> Hi,
> Altough I have this configuration in client .conf:
> 
> ##
> client 172.30.47.241 {
>secret  = 877909
>shortname   = VodafonePinarsuAPNYeni1
>nastype = other
> }
> 
> client 172.30.47.242 {
>secret  = 877909
>shortname   = VodafonePinarsuAPNYeni2
>nastype = other
> }
> 
> 
> 
> Why I get this error?
> 
> 
> #
> 
> Tue Mar 17 14:31:55 2015 : Error: Ignoring request to
> authentication address * port 1812 from unknown client
> 172.30.47.242 port 58312
> Tue Mar 17 14:32:01 2015 : Error: Ignoring request to
> authentication address * port 1812 from unknown client
> 172.30.47.241 port 6040
> 
> 
> #
> 
> 
> I think you should post your question to the free*radius* mailing
> list ;-)
> 
> 
> --
> Groeten,
> natxo

yes, and when you do post to that list, give the output of "radiusd -X".
see http://wiki.freeradius.org/guide/Troubleshooting

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

Re: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID

[Guertin, David S.]

> I don't think sss_cache -E removes cached idrange objects. You need to
> delete the databases in /var/lib/sss/db/.

OK, I stopped sssd, removed everything in /var/lib/sss/db, and restarted sssd.

Still no change -- I get the same error.

> You mean RHEL 7.1, right?

Yes, RHEL 7.1.

David Guertin

-- 
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] Using FreeIPA for LDAP authentication in 3rd party applications

[Dan]

Thomas Raehalme  writes:

> 
> Hi,
> 
> Previously we have used Atlassian Crowd as a source for user data in
> various applications, both in-house built and proprietary such as JIRA
> or Confluence. As we have deployed FreeIPA, I would like to start
> using it as the identity source. Unfortunately using Kerberos is not
> always possible so I am thinking about LDAP which often is an option
> in 3rd party applicaitons.
> 
> Anonymous access to the FreeIPA LDAP is enabled by default. Is it
> possible to configure username/password to access the information?
> Currently vSphere has a problem with anonymous access to LDAP not
> working as intended. Ofcourse it would be nice to be able to restrict
> access anyways.
> 
> If using FreeIPA LDAP as the identity source, how should
> authentication be handled? Is it possible to read the hash code for
> passwords? Is it possible to authenticate against the LDAP service?
> 
> Any advice appreciated!
> 
> Best regards,
> Thomas


Hi,

I have just successfully configured confluence and jira to use FreeIPA for 
its LDAP user directory.

First, create an IPA user group for confluence-users and jira-users using 
the IPA dashboard. Then add a user to both of these groups.

If you navigate to the confluence and jira dashboards and then in the "User 
Directories" settings menu add a "Generic Directory Server" and then use the 
following settings...

Base DN: You can find this in your IPA config.
Additional User DN: cn=users,cn=accounts
Additional Group DN: cn=groups,cn=accounts
LDAP Permissions: Read Only

Advanced Settings - Defaults are fine for this section

User Schema Settings
User Object Class:  inetorgperson
User Object Filter: (objectclass=inetorgperson)
User Name Attribute:uid
User Name RDN Attribute:uid
User First Name Attribute:  givenName
User Last Name Attribute:   sn
User Display Name Attribute:displayName
User Email Attribute:   mail
User Password Attribute:userPassword
User Password Encryption:   SHA
User Unique ID Attribute:   ipaUniqueID

Group Schema Settings   
Group Object Class  ipausergroup
Group Object Filter (objectclass=ipausergroup)
Group Name Attributecn
Group Description   description

Membership Schema Settings  
Group Members Attribute: member
User Membership Attribute: member (This is not used due to the next option)
User the User Membership Attribute: (Ensure this is unchecked, it is not 
supported)

Now save and test using the user who is in the groups created above.

Hope this helps someone.

Dan


-- 
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] Only one AD user can able to login to IPA server

[Ben .T.George]

Hi all

how can i fix this issue.? even i tried to trust add AD again. that too
failed.

from where i need to troubleshoot ?

On Tue, Mar 17, 2015 at 3:02 PM, Ben .T.George 
wrote:

> Hi
>
> i did kinit
>
> [root@kwtpocpbis01 sssd]# kinit -kt /etc/dirsrv/ds.keytab
> kinit: Keytab contains no suitable keys for
> host/kwtpocpbis01.solaris.local@SOLARIS.LOCAL while getting initial
> credentials
>
>
> i destroyed and re-created. but still same
>
>
>
> On Tue, Mar 17, 2015 at 2:45 PM, Jakub Hrozek  wrote:
>
>> On Tue, Mar 17, 2015 at 02:38:41PM +0300, Ben .T.George wrote:
>> > here is separated logs:
>> >
>> > tail -f sssd_solaris.local.log
>>
>> Thank you, see inline:
>>
>> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_tgt_recv]
>> > (0x0400): Child responded: 14 [Decrypt integrity check failed], expired
>> on
>> > [0]
>> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_kinit_done]
>> > (0x0100): Could not get TGT: 14 [Bad address]
>> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]]
>> [sdap_cli_kinit_done]
>> > (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed)
>> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]]
>> [fo_set_port_status]
>> > (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'not
>> > working'
>> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]]
>> [fo_set_port_status]
>> > (0x0400): Marking port 0 of duplicate server
>> 'kwtpocpbis01.solaris.local'
>> > as 'not working'
>> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]]
>> [sdap_handle_release]
>> > (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[(nil)],
>> > ldap[0x7f6b7d265a00], destructor_lock[0], release_memory[0]
>> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]]
>> > [remove_connection_callback] (0x4000): Successfully removed connection
>> > callback.
>> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]]
>> > [check_online_callback] (0x0100): Backend returned: (3, 0, )
>> > [Internal Error (Success)]
>>
>> So it seems the keytab is wrong, you can also test the keytab validity
>> with "kinit -k"..
>>
>
>
-- 
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] Only one AD user can able to login to IPA server

[Alexander Bokovoy]

On Tue, 17 Mar 2015, Ben .T.George wrote:

Hi

i did kinit

[root@kwtpocpbis01 sssd]# kinit -kt /etc/dirsrv/ds.keytab
kinit: Keytab contains no suitable keys for
host/kwtpocpbis01.solaris.local@SOLARIS.LOCAL while getting initial
credentials


i destroyed and re-created. but still same

What did you destroy?

Why did you need to touch /etc/dirsrv/ds.keytab at all? It contains key
for ldap/kwtpocpbis01.solaris.local@SOLARIS.LOCAL that your LDAP server
is using. It has nothing to do with your host/... principal. 



If your sssd cannot authenticate against AD DC, it means trust is *not*
working and anything else is fruitless unless you fix it. 


hat do you see
in /var/log/httpd/error_log as result of dumping netr_LogonControl2Ex structure?


Can you follow
http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust
and tell what do you see in /var/log/httpd/error_log as result of
dumping netr_LogonControl2Ex structure?

We went through this few weeks ago and I'm not seeing what did you
broke.

--
/ 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] Problems with ssh and install-uninstall-install sequence on the server

[Prasun Gera]

Hello,
I installed the ipa-server on an RHEL 7.1 system, uninstalled it and
reinstalled it with the same domain name as the first time. This somehow
creates problems with ssh authentication on the server from external
systems as well as from the server itself.

Steps:
1. ipa-server-install
2. service sshd restart
3. kinit admin
4. ssh admin@localhost
-- 
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] Problems with ssh and install-uninstall-install sequence on the server

[Prasun Gera]

Sorry, the message got sent accidentally earlier before I could provide all
the details.

Version: 4.1.0 on RHEL 7.1 x86_64

Steps:
1. ipa-server-install
2. service sshd restart
3. kinit admin  <- This always works
4. ssh admin@localhost <- This works for the first time, fails
second time onwards
ssh admin@host_addr from external system  <- This also works the
first time, fails second time onwards

5. ipa-server-install --uninstall
6. go to 1

The log messages in /var/log/messages point to [sssd[krb5_child[21029]]]:
Decrypt integrity check failed at the point of the authentication failure
sssd's log's have a lot of "No matching domain found for user" messages.
/var/log/krb5kdc.log has a lot of error decoding FAST:  for
, Decrypt integrity check failed while handling ap-request
armor

The only ERROR I can see in /var/log/ipaserver-uninstall.log is
pkidestroy  : ERROR... subprocess.CalledProcessError:  Command
'['/usr/bin/sslget', '-n', 'subsystemCert cert-pki-ca', ..returned
non-zero exit status 6!


It appears that the uninstall process is leaving some residual
configuration behind which is conflicting with the subsequent installation
with the same domain name


Regards,
Prasun







On Tue, Mar 17, 2015 at 2:41 PM, Prasun Gera  wrote:

> Hello,
> I installed the ipa-server on an RHEL 7.1 system, uninstalled it and
> reinstalled it with the same domain name as the first time. This somehow
> creates problems with ssh authentication on the server from external
> systems as well as from the server itself.
>
> Steps:
> 1. ipa-server-install
> 2. service sshd restart
> 3. kinit admin
> 4. ssh admin@localhost
>
-- 
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] pki-tomcatd stopped responding? Won't restart?

[Dmitri Pal]

On 03/17/2015 12:12 PM, Janelle wrote:

On 3/17/15 9:06 AM, Martin Kosek wrote:

On 03/17/2015 04:35 PM, Janelle wrote:

Hello,

I have a server - a master (has CA) - and it does not want to 
restart after it
has been running sometime. pki-tomcatd keeps failing. It starts up 
with these
errors, then adds a lot more. Maybe this might point you to 
something that is

know or a place I can start looking?

Any ideas?
~J

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'enableOCSP' to 'false' did not find a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property
'ocspResponderURL' to 'http://ipa-server.example.com:9080/ca/ocsp' 
did not find

a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property
'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not 
find a

matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'ocspCacheSize' to '1000' did not find a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'ocspMinCacheEntryDuration' to '60' did not find a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'ocspMaxCacheEntryDuration' to '120' did not find a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'ocspTimeout' to '10' did not find a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'strictCiphers' to 'true' did not find a matching property.
Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin


WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property
'sslOptions' to 'ssl2=true,ssl3=true,tls=true' did not find a 
matching property.


CCing folks from Dogtag team to know about this issue. However, I 
think you
will need to provide more information before we continue with issues 
- like

version of FreeIPA, pki-ca packages, what system you are running it on
(Fedora/RHEL/CentOS/...) and maybe whole logs pasted somewhere 
(system and

catalina.out logs are usually most interesting ones).

My bad --

CentOS 7
FreeIPA 4.1.3 from mosek

The strange thing is -- 12 other servers - 3 of which are CA masters 
and no issues,


~J


Just some areas to check:
- versions of dogtag package
- versions of nss package

--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

--
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] Scripting reports from ipa?

[Watson, Dan]

Hi all,

Can anyone tell me how to script calls from the ipa server? I would like to be 
able to do something like "ipa group-show unix_admin" in a script, but I don't 
know how to pass Kerberos credentials that don't expire.

I'd appreciate some help, thanks!

Dan
-- 
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] pki-tomcatd stopped responding? Won't restart?

[Janelle]

On 3/17/15 12:14 PM, Dmitri Pal wrote:

On 03/17/2015 12:12 PM, Janelle wrote:

On 3/17/15 9:06 AM, Martin Kosek wrote:

On 03/17/2015 04:35 PM, Janelle wrote:

Hello,

I have a server - a master (has CA) - and it does not want to 
restart after it
has been running sometime. pki-tomcatd keeps failing. It starts up 
with these
errors, then adds a lot more. Maybe this might point you to 
something that is

know or a place I can start looking?

Any ideas?
~J

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'enableOCSP' to 'false' did not find a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property
'ocspResponderURL' to 'http://ipa-server.example.com:9080/ca/ocsp' 
did not find

a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property
'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did 
not find a

matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'ocspCacheSize' to '1000' did not find a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'ocspMinCacheEntryDuration' to '60' did not find a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'ocspMaxCacheEntryDuration' to '120' did not find a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'ocspTimeout' to '10' did not find a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'strictCiphers' to 'true' did not find a matching property.
Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin


WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property
'sslOptions' to 'ssl2=true,ssl3=true,tls=true' did not find a 
matching property.


CCing folks from Dogtag team to know about this issue. However, I 
think you
will need to provide more information before we continue with issues 
- like

version of FreeIPA, pki-ca packages, what system you are running it on
(Fedora/RHEL/CentOS/...) and maybe whole logs pasted somewhere 
(system and

catalina.out logs are usually most interesting ones).

My bad --

CentOS 7
FreeIPA 4.1.3 from mosek

The strange thing is -- 12 other servers - 3 of which are CA masters 
and no issues,


~J


Just some areas to check:
- versions of dogtag package
- versions of nss package


pki-tools-10.1.2-7.1.el7.centos.x86_64
dogtag-pki-server-theme-10.1.1-1.el7.centos.noarch
pki-server-10.1.2-7.1.el7.centos.noarch
krb5-pkinit-1.12.2-9.el7.centos.x86_64
pki-base-10.1.2-7.1.el7.centos.noarch
pki-ca-10.1.2-7.1.el7.centos.noarch

mod_nss-1.0.8-32.el7.x86_64
nss-sysinit-3.16.2.3-2.el7_0.x86_64
python-nss-0.15.0-1.el7.centos.x86_64
nss-softokn-3.16.2.3-1.el7_0.x86_64
nss-softokn-freebl-3.16.2.3-1.el7_0.x86_64
nss-tools-3.16.2.3-2.el7_0.x86_64
nss-util-3.16.2.3-1.el7_0.x86_64
nss-3.16.2.3-2.el7_0.x86_64

Anything? All the servers are identical.

~J

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

[Freeipa-users] Can't remove all replica records from ldap

[Kim Perrin]

Hello all,

For nearly 2 years I’ve been running a Freeipa 3 (currently 3.0.0-42)
environment. We've had 2 masters since the start.  Several replicas
have had problems that required me to remove them. I’ve removed them
all (except the very last one) by running  ‘ipa-server-install
--uninstall’  and then  ipa-replica-manage clean-ruv’. The latest
replica I tried to remove failed on both commands. On further
inspection I see all the previous replicas have orphaned entries in
the ldap db.  How do I remove all the entries? (I’ve listed the
entries below). Is this process safe (in what is currently a single
ipa server environment)? Note, I’ve seen the one of the necessary
LDIFs that can be ‘run’ to remove the entries -- I just don’t
understand how to run an ldif.

Relevant entries -

kperrin@noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -s
sub -b cn=config objectclass=nsds5replica
Enter LDAP Password:
dn: cn=replica,cn=dc\3Dcompanyz\2Cdc\3Dcom,cn=mapping tree,cn=config
cn: replica
nsDS5Flags: 1
objectClass: top
objectClass: nsds5replica
objectClass: extensibleobject
nsDS5ReplicaType: 3
nsDS5ReplicaRoot: dc=companyz,dc=com
nsds5ReplicaLegacyConsumer: off
nsDS5ReplicaId: 4
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindDN:
krbprincipalname=ldap/noc2prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
nsDS5ReplicaBindDN:
krbprincipalname=ldap/util1prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
nsDS5ReplicaBindDN:
krbprincipalname=ldap/noc3prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
nsDS5ReplicaBindDN:
krbprincipalname=ldap/noc4prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
nsState:: BABlZwhVDgAFAA==
nsDS5ReplicaName: 2767660e-9e5611e2-b7b6a070-c35ad5d3
nsds5ReplicaAbortCleanRUV: 14:dc=companyz,dc=com
nsds5ReplicaChangeCount: 682699
nsds5replicareapactive: 0

kperrin@noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -b
o=ipaca  
'(&(nsuniqueid=---)(objectclass=nstombstone))'
-p 7389 -h noc1-prd
Enter LDAP Password:
dn: nsuniqueid=---,o=ipaca
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 5317a4490060
nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a45500
60 550878b90060
nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce01800
47 531ce06900030047
nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde800
4c 53f65954004c
nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf21600
51 531bf26500010051
nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a322200
56 531a325600040056
nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf00
5b 53194992005b
nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a4500
061 5317a48a00010061
o: ipaca
nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389}
 550878ab
nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389}
 
nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389}
 
nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389}
 
nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389}
 
nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389}
 
nsruvReplicaLastModified: {replica 97 ldap://util1-prd.companyz.com:7389
} 

-- and here is an example LDIF to remove the last record listed above -

dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task: CLEANRUV97

How do I ‘run’ this ldif?


Thanks,
Kim Perrin

-- 
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't remove all replica records from ldap

[Rob Crittenden]

Kim Perrin wrote:
> Hello all,
> 
> For nearly 2 years I’ve been running a Freeipa 3 (currently 3.0.0-42)
> environment. We've had 2 masters since the start.  Several replicas
> have had problems that required me to remove them. I’ve removed them
> all (except the very last one) by running  ‘ipa-server-install
> --uninstall’  and then  ipa-replica-manage clean-ruv’. The latest
> replica I tried to remove failed on both commands. On further
> inspection I see all the previous replicas have orphaned entries in
> the ldap db.  How do I remove all the entries? (I’ve listed the
> entries below). Is this process safe (in what is currently a single
> ipa server environment)? Note, I’ve seen the one of the necessary
> LDIFs that can be ‘run’ to remove the entries -- I just don’t
> understand how to run an ldif.

You're skipping the step of ipa-replica-manage del ?
That should do most of this cleanup for you.

For the CA you use ipa-csreplica-manage. Unfortunately that utility
lacks the RUV commands.

rob

> Relevant entries -
> 
> kperrin@noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -s
> sub -b cn=config objectclass=nsds5replica
> Enter LDAP Password:
> dn: cn=replica,cn=dc\3Dcompanyz\2Cdc\3Dcom,cn=mapping tree,cn=config
> cn: replica
> nsDS5Flags: 1
> objectClass: top
> objectClass: nsds5replica
> objectClass: extensibleobject
> nsDS5ReplicaType: 3
> nsDS5ReplicaRoot: dc=companyz,dc=com
> nsds5ReplicaLegacyConsumer: off
> nsDS5ReplicaId: 4
> nsDS5ReplicaBindDN: cn=replication manager,cn=config
> nsDS5ReplicaBindDN:
> krbprincipalname=ldap/noc2prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
> nsDS5ReplicaBindDN:
> krbprincipalname=ldap/util1prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
> nsDS5ReplicaBindDN:
> krbprincipalname=ldap/noc3prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
> nsDS5ReplicaBindDN:
> krbprincipalname=ldap/noc4prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
> nsState:: BABlZwhVDgAFAA==
> nsDS5ReplicaName: 2767660e-9e5611e2-b7b6a070-c35ad5d3
> nsds5ReplicaAbortCleanRUV: 14:dc=companyz,dc=com
> nsds5ReplicaChangeCount: 682699
> nsds5replicareapactive: 0
> 
> kperrin@noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -b
> o=ipaca  
> '(&(nsuniqueid=---)(objectclass=nstombstone))'
> -p 7389 -h noc1-prd
> Enter LDAP Password:
> dn: nsuniqueid=---,o=ipaca
> objectClass: top
> objectClass: nsTombstone
> objectClass: extensibleobject
> nsds50ruv: {replicageneration} 5317a4490060
> nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a45500
> 60 550878b90060
> nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce01800
> 47 531ce06900030047
> nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde800
> 4c 53f65954004c
> nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf21600
> 51 531bf26500010051
> nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a322200
> 56 531a325600040056
> nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf00
> 5b 53194992005b
> nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a4500
> 061 5317a48a00010061
> o: ipaca
> nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389}
>  550878ab
> nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389}
>  
> nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389}
>  
> nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389}
>  
> nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389}
>  
> nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389}
>  
> nsruvReplicaLastModified: {replica 97 ldap://util1-prd.companyz.com:7389
> } 
> 
> -- and here is an example LDIF to remove the last record listed above -
> 
> dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
> changetype: modify
> replace: nsds5task
> nsds5task: CLEANRUV97

That doesn't look right. It should look like:

dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
replica-base-dn: dc=companyz,dc=com
replica-id: 97
cn: clean 97

Be careful which RUV you remove. You only want to remove those that are
no longer active.

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] Scripting reports from ipa?

[Rob Crittenden]

Watson, Dan wrote:
> Hi all,
> 
>  
> 
> Can anyone tell me how to script calls from the ipa server? I would like
> to be able to do something like “ipa group-show unix_admin” in a script,
> but I don’t know how to pass Kerberos credentials that don’t expire.

I think you want to use credentials in a keytab. Then, before you call
your command, you can run:

$ kinit -kt /path/to/keytab princ@REALM

This can be wasteful because it always gets a new ticket.

Depending on your distro, if you have gss-proxy, it can take care of a
lot of those details for you.

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] Can't remove all replica records from ldap

[Kim Perrin]

Thanks for the reply Rob.

On Tue, Mar 17, 2015 at 2:06 PM, Rob Crittenden  wrote:
> Kim Perrin wrote:
>> Hello all,
>>
>> For nearly 2 years I’ve been running a Freeipa 3 (currently 3.0.0-42)
>> environment. We've had 2 masters since the start.  Several replicas
>> have had problems that required me to remove them. I’ve removed them
>> all (except the very last one) by running  ‘ipa-server-install
>> --uninstall’  and then  ipa-replica-manage clean-ruv’. The latest
>> replica I tried to remove failed on both commands. On further
>> inspection I see all the previous replicas have orphaned entries in
>> the ldap db.  How do I remove all the entries? (I’ve listed the
>> entries below). Is this process safe (in what is currently a single
>> ipa server environment)? Note, I’ve seen the one of the necessary
>> LDIFs that can be ‘run’ to remove the entries -- I just don’t
>> understand how to run an ldif.
>
> You're skipping the step of ipa-replica-manage del ?
> That should do most of this cleanup for you.
I did run 'ipa-replica-manage del '  for all these as well.


>
> For the CA you use ipa-csreplica-manage. Unfortunately that utility
> lacks the RUV commands.
>
> rob
>
>> Relevant entries -
>>
>> kperrin@noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -s
>> sub -b cn=config objectclass=nsds5replica
>> Enter LDAP Password:
>> dn: cn=replica,cn=dc\3Dcompanyz\2Cdc\3Dcom,cn=mapping tree,cn=config
>> cn: replica
>> nsDS5Flags: 1
>> objectClass: top
>> objectClass: nsds5replica
>> objectClass: extensibleobject
>> nsDS5ReplicaType: 3
>> nsDS5ReplicaRoot: dc=companyz,dc=com
>> nsds5ReplicaLegacyConsumer: off
>> nsDS5ReplicaId: 4
>> nsDS5ReplicaBindDN: cn=replication manager,cn=config
>> nsDS5ReplicaBindDN:
>> krbprincipalname=ldap/noc2prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
>> nsDS5ReplicaBindDN:
>> krbprincipalname=ldap/util1prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
>> nsDS5ReplicaBindDN:
>> krbprincipalname=ldap/noc3prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
>> nsDS5ReplicaBindDN:
>> krbprincipalname=ldap/noc4prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
>> nsState:: BABlZwhVDgAFAA==
>> nsDS5ReplicaName: 2767660e-9e5611e2-b7b6a070-c35ad5d3
>> nsds5ReplicaAbortCleanRUV: 14:dc=companyz,dc=com
>> nsds5ReplicaChangeCount: 682699
>> nsds5replicareapactive: 0
>>
>> kperrin@noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -b
>> o=ipaca  
>> '(&(nsuniqueid=---)(objectclass=nstombstone))'
>> -p 7389 -h noc1-prd
>> Enter LDAP Password:
>> dn: nsuniqueid=---,o=ipaca
>> objectClass: top
>> objectClass: nsTombstone
>> objectClass: extensibleobject
>> nsds50ruv: {replicageneration} 5317a4490060
>> nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a45500
>> 60 550878b90060
>> nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce01800
>> 47 531ce06900030047
>> nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde800
>> 4c 53f65954004c
>> nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf21600
>> 51 531bf26500010051
>> nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a322200
>> 56 531a325600040056
>> nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf00
>> 5b 53194992005b
>> nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a4500
>> 061 5317a48a00010061
>> o: ipaca
>> nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389}
>>  550878ab
>> nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389}
>>  
>> nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389}
>>  
>> nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389}
>>  
>> nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389}
>>  
>> nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389}
>>  
>> nsruvReplicaLastModified: {replica 97 ldap://util1-prd.companyz.com:7389
>> } 
>>
>> -- and here is an example LDIF to remove the last record listed above -
>>
>> dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
>> changetype: modify
>> replace: nsds5task
>> nsds5task: CLEANRUV97
>
> That doesn't look right. It should look like:
>
> dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config
> changetype: add
> objectclass: top
> objectclass: extensibleObject
> replica-base-dn: dc=companyz,dc=com
> replica-id: 97
> cn: clean 97
>
> Be careful which RUV you remove. You only want to remove those that are
> no longer active.
Thanks for the additional spec on the LDIF, though I still don't
understand how to run this. Is there somewhere you can point me to
with example commands to run such LDIFs?

-Kim
>
> rob

-- 
Ma

Re: [Freeipa-users] pki-tomcatd stopped responding? Won't restart?

[Dmitri Pal]

On 03/17/2015 03:41 PM, Janelle wrote:

On 3/17/15 12:14 PM, Dmitri Pal wrote:

On 03/17/2015 12:12 PM, Janelle wrote:

On 3/17/15 9:06 AM, Martin Kosek wrote:

On 03/17/2015 04:35 PM, Janelle wrote:

Hello,

I have a server - a master (has CA) - and it does not want to 
restart after it
has been running sometime. pki-tomcatd keeps failing. It starts up 
with these
errors, then adds a lot more. Maybe this might point you to 
something that is

know or a place I can start looking?

Any ideas?
~J

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'enableOCSP' to 'false' did not find a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property
'ocspResponderURL' to 'http://ipa-server.example.com:9080/ca/ocsp' 
did not find

a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property
'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did 
not find a

matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'ocspCacheSize' to '1000' did not find a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'ocspMinCacheEntryDuration' to '60' did not find a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property
'ocspMaxCacheEntryDuration' to '120' did not find a matching 
property.


Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'ocspTimeout' to '10' did not find a matching property.

Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property

'strictCiphers' to 'true' did not find a matching property.
Mar 17, 2015 8:21:03 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin


WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting 
property
'sslOptions' to 'ssl2=true,ssl3=true,tls=true' did not find a 
matching property.


CCing folks from Dogtag team to know about this issue. However, I 
think you
will need to provide more information before we continue with 
issues - like

version of FreeIPA, pki-ca packages, what system you are running it on
(Fedora/RHEL/CentOS/...) and maybe whole logs pasted somewhere 
(system and

catalina.out logs are usually most interesting ones).

My bad --

CentOS 7
FreeIPA 4.1.3 from mosek

The strange thing is -- 12 other servers - 3 of which are CA masters 
and no issues,


~J


Just some areas to check:
- versions of dogtag package
- versions of nss package


pki-tools-10.1.2-7.1.el7.centos.x86_64
dogtag-pki-server-theme-10.1.1-1.el7.centos.noarch
pki-server-10.1.2-7.1.el7.centos.noarch
krb5-pkinit-1.12.2-9.el7.centos.x86_64
pki-base-10.1.2-7.1.el7.centos.noarch
pki-ca-10.1.2-7.1.el7.centos.noarch

mod_nss-1.0.8-32.el7.x86_64
nss-sysinit-3.16.2.3-2.el7_0.x86_64
python-nss-0.15.0-1.el7.centos.x86_64
nss-softokn-3.16.2.3-1.el7_0.x86_64
nss-softokn-freebl-3.16.2.3-1.el7_0.x86_64
nss-tools-3.16.2.3-2.el7_0.x86_64
nss-util-3.16.2.3-1.el7_0.x86_64
nss-3.16.2.3-2.el7_0.x86_64

Anything? All the servers are identical.

~J


No if they are same then it is not it.
We need to find what is different on these machines. May be it is tomcat 
or tomcatjss that is different.



--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

--
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] sssd options ignored?

[Gould, Joshua]

I’ve been getting messages like these when I try the id command for a test AD 
domain user:

(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_get_primary_name] 
(0x0400): Processing object farus@test.osuwmc
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] 
(0x0400): Processing user farus@test.osuwmc
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] 
(0x1000): Mapping user [farus@test.osuwmc] objectSID 
[S-1-5-21-226267946-722566613-1883572810-398410] to unix ID
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] 
[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID 
[S-1-5-21-226267946-722566613-1883572810-398410] to a UNIX ID
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] 
(0x0020): Failed to save user [adm-faru03@test.osuwmc]

Various sources all inicate that its a range issue with ldap_idmap_range_size. 
I’ve tried several large values of just ldap_idmap_range_size as well as adding 
ldap_idmap_range_min and ldap_idmap_range_range. All I can figure is that 
perhaps sssd is ignoring the values? Between changing values I did stop sssd, 
delete the cache and restart it. This is RHEL7 fully up to date. My SSSD shows 
1.12.2-58.

Here is my full sssd.conf.

[domain/unix.test.osuwmc]
debug_level = 9
subdomains_provider = ipa
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = unix.test.osuwmc
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = mid-ipa-vp01.unix.test.osuwmc
chpass_provider = ipa
ipa_server = mid-ipa-vp01.unix.test.osuwmc
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt
#ldap_idmap_range_min = 2000
#ldap_idmap_range_size = 90
#ldap_idmap_range_range = 3602000
ldap_idmap_range_size=100
ldap_id_mapping = True

[sssd]
services = nss, sudo, pam, ssh, pac
config_file_version = 2


domains = unix.test.osuwmc
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]

-- 
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't remove all replica records from ldap

[Kim Perrin]

On Tue, Mar 17, 2015 at 2:52 PM, Kim Perrin  wrote:
> Thanks for the reply Rob.
>
> On Tue, Mar 17, 2015 at 2:06 PM, Rob Crittenden  wrote:
>> Kim Perrin wrote:
>>> Hello all,
>>>
>>> For nearly 2 years I’ve been running a Freeipa 3 (currently 3.0.0-42)
>>> environment. We've had 2 masters since the start.  Several replicas
>>> have had problems that required me to remove them. I’ve removed them
>>> all (except the very last one) by running  ‘ipa-server-install
>>> --uninstall’  and then  ipa-replica-manage clean-ruv’. The latest
>>> replica I tried to remove failed on both commands. On further
>>> inspection I see all the previous replicas have orphaned entries in
>>> the ldap db.  How do I remove all the entries? (I’ve listed the
>>> entries below). Is this process safe (in what is currently a single
>>> ipa server environment)? Note, I’ve seen the one of the necessary
>>> LDIFs that can be ‘run’ to remove the entries -- I just don’t
>>> understand how to run an ldif.
>>
>> You're skipping the step of ipa-replica-manage del ?
>> That should do most of this cleanup for you.
> I did run 'ipa-replica-manage del '  for all these as well.
>
>
>>
>> For the CA you use ipa-csreplica-manage. Unfortunately that utility
>> lacks the RUV commands.
>>
>> rob
>>
>>> Relevant entries -
>>>
>>> kperrin@noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -s
>>> sub -b cn=config objectclass=nsds5replica
>>> Enter LDAP Password:
>>> dn: cn=replica,cn=dc\3Dcompanyz\2Cdc\3Dcom,cn=mapping tree,cn=config
>>> cn: replica
>>> nsDS5Flags: 1
>>> objectClass: top
>>> objectClass: nsds5replica
>>> objectClass: extensibleobject
>>> nsDS5ReplicaType: 3
>>> nsDS5ReplicaRoot: dc=companyz,dc=com
>>> nsds5ReplicaLegacyConsumer: off
>>> nsDS5ReplicaId: 4
>>> nsDS5ReplicaBindDN: cn=replication manager,cn=config
>>> nsDS5ReplicaBindDN:
>>> krbprincipalname=ldap/noc2prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
>>> nsDS5ReplicaBindDN:
>>> krbprincipalname=ldap/util1prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
>>> nsDS5ReplicaBindDN:
>>> krbprincipalname=ldap/noc3prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
>>> nsDS5ReplicaBindDN:
>>> krbprincipalname=ldap/noc4prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
>>> nsState:: BABlZwhVDgAFAA==
>>> nsDS5ReplicaName: 2767660e-9e5611e2-b7b6a070-c35ad5d3
>>> nsds5ReplicaAbortCleanRUV: 14:dc=companyz,dc=com
>>> nsds5ReplicaChangeCount: 682699
>>> nsds5replicareapactive: 0
>>>
>>> kperrin@noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -b
>>> o=ipaca  
>>> '(&(nsuniqueid=---)(objectclass=nstombstone))'
>>> -p 7389 -h noc1-prd
>>> Enter LDAP Password:
>>> dn: nsuniqueid=---,o=ipaca
>>> objectClass: top
>>> objectClass: nsTombstone
>>> objectClass: extensibleobject
>>> nsds50ruv: {replicageneration} 5317a4490060
>>> nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a45500
>>> 60 550878b90060
>>> nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce01800
>>> 47 531ce06900030047
>>> nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde800
>>> 4c 53f65954004c
>>> nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf21600
>>> 51 531bf26500010051
>>> nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a322200
>>> 56 531a325600040056
>>> nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf00
>>> 5b 53194992005b
>>> nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a4500
>>> 061 5317a48a00010061
>>> o: ipaca
>>> nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389}
>>>  550878ab
>>> nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389}
>>>  
>>> nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389}
>>>  
>>> nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389}
>>>  
>>> nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389}
>>>  
>>> nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389}
>>>  
>>> nsruvReplicaLastModified: {replica 97 ldap://util1-prd.companyz.com:7389
>>> } 
>>>
>>> -- and here is an example LDIF to remove the last record listed above -
>>>
>>> dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
>>> changetype: modify
>>> replace: nsds5task
>>> nsds5task: CLEANRUV97
>>
>> That doesn't look right. It should look like:
>>
>> dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config
>> changetype: add
>> objectclass: top
>> objectclass: extensibleObject
>> replica-base-dn: dc=companyz,dc=com
>> replica-id: 97
>> cn: clean 97
>>
>> Be careful which RUV you remove. You only want to remove those that are
>> no longer active.
> Thanks for the add

Re: [Freeipa-users] Can't remove all replica records from ldap

[Kim Perrin]

On Tue, Mar 17, 2015 at 3:09 PM, Kim Perrin  wrote:
> On Tue, Mar 17, 2015 at 2:52 PM, Kim Perrin  
> wrote:
>> Thanks for the reply Rob.
>>
>> On Tue, Mar 17, 2015 at 2:06 PM, Rob Crittenden  wrote:
>>> Kim Perrin wrote:
 Hello all,

 For nearly 2 years I’ve been running a Freeipa 3 (currently 3.0.0-42)
 environment. We've had 2 masters since the start.  Several replicas
 have had problems that required me to remove them. I’ve removed them
 all (except the very last one) by running  ‘ipa-server-install
 --uninstall’  and then  ipa-replica-manage clean-ruv’. The latest
 replica I tried to remove failed on both commands. On further
 inspection I see all the previous replicas have orphaned entries in
 the ldap db.  How do I remove all the entries? (I’ve listed the
 entries below). Is this process safe (in what is currently a single
 ipa server environment)? Note, I’ve seen the one of the necessary
 LDIFs that can be ‘run’ to remove the entries -- I just don’t
 understand how to run an ldif.
>>>
>>> You're skipping the step of ipa-replica-manage del ?
>>> That should do most of this cleanup for you.
>> I did run 'ipa-replica-manage del '  for all these as well.
>>
>>
>>>
>>> For the CA you use ipa-csreplica-manage. Unfortunately that utility
>>> lacks the RUV commands.
On using the 'ipa-csreplica-manage' command to remove the CAs  - the
del option failed with
"Unable to delete replica noc3-prd.companyz.com: Can't contact LDAP server"
And failed with the same response for a couple other listed servers as well.
>>>
>>> rob
>>>
 Relevant entries -

 kperrin@noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -s
 sub -b cn=config objectclass=nsds5replica
 Enter LDAP Password:
 dn: cn=replica,cn=dc\3Dcompanyz\2Cdc\3Dcom,cn=mapping tree,cn=config
 cn: replica
 nsDS5Flags: 1
 objectClass: top
 objectClass: nsds5replica
 objectClass: extensibleobject
 nsDS5ReplicaType: 3
 nsDS5ReplicaRoot: dc=companyz,dc=com
 nsds5ReplicaLegacyConsumer: off
 nsDS5ReplicaId: 4
 nsDS5ReplicaBindDN: cn=replication manager,cn=config
 nsDS5ReplicaBindDN:
 krbprincipalname=ldap/noc2prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
 nsDS5ReplicaBindDN:
 krbprincipalname=ldap/util1prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
 nsDS5ReplicaBindDN:
 krbprincipalname=ldap/noc3prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
 nsDS5ReplicaBindDN:
 krbprincipalname=ldap/noc4prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
 nsState:: BABlZwhVDgAFAA==
 nsDS5ReplicaName: 2767660e-9e5611e2-b7b6a070-c35ad5d3
 nsds5ReplicaAbortCleanRUV: 14:dc=companyz,dc=com
 nsds5ReplicaChangeCount: 682699
 nsds5replicareapactive: 0

 kperrin@noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -b
 o=ipaca  
 '(&(nsuniqueid=---)(objectclass=nstombstone))'
 -p 7389 -h noc1-prd
 Enter LDAP Password:
 dn: nsuniqueid=---,o=ipaca
 objectClass: top
 objectClass: nsTombstone
 objectClass: extensibleobject
 nsds50ruv: {replicageneration} 5317a4490060
 nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a45500
 60 550878b90060
 nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce01800
 47 531ce06900030047
 nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde800
 4c 53f65954004c
 nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf21600
 51 531bf26500010051
 nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a322200
 56 531a325600040056
 nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf00
 5b 53194992005b
 nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a4500
 061 5317a48a00010061
 o: ipaca
 nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389}
  550878ab
 nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389}
  
 nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389}
  
 nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389}
  
 nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389}
  
 nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389}
  
 nsruvReplicaLastModified: {replica 97 ldap://util1-prd.companyz.com:7389
 } 

 -- and here is an example LDIF to remove the last record listed above -

 dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
 changetype: modify
 replace: n

Re: [Freeipa-users] Can't remove all replica records from ldap

[Dmitri Pal]

On 03/17/2015 06:27 PM, Kim Perrin wrote:

On Tue, Mar 17, 2015 at 3:09 PM, Kim Perrin  wrote:

On Tue, Mar 17, 2015 at 2:52 PM, Kim Perrin  wrote:

Thanks for the reply Rob.

On Tue, Mar 17, 2015 at 2:06 PM, Rob Crittenden  wrote:

Kim Perrin wrote:

Hello all,

For nearly 2 years I’ve been running a Freeipa 3 (currently 3.0.0-42)
environment. We've had 2 masters since the start.  Several replicas
have had problems that required me to remove them. I’ve removed them
all (except the very last one) by running  ‘ipa-server-install
--uninstall’  and then  ipa-replica-manage clean-ruv’. The latest
replica I tried to remove failed on both commands. On further
inspection I see all the previous replicas have orphaned entries in
the ldap db.  How do I remove all the entries? (I’ve listed the
entries below). Is this process safe (in what is currently a single
ipa server environment)? Note, I’ve seen the one of the necessary
LDIFs that can be ‘run’ to remove the entries -- I just don’t
understand how to run an ldif.

You're skipping the step of ipa-replica-manage del ?
That should do most of this cleanup for you.

I did run 'ipa-replica-manage del '  for all these as well.



For the CA you use ipa-csreplica-manage. Unfortunately that utility
lacks the RUV commands.

On using the 'ipa-csreplica-manage' command to remove the CAs  - the
del option failed with
"Unable to delete replica noc3-prd.companyz.com: Can't contact LDAP server"
And failed with the same response for a couple other listed servers as well.



Yes, you would have to clean it manually.



rob


Relevant entries -

kperrin@noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -s
sub -b cn=config objectclass=nsds5replica
Enter LDAP Password:
dn: cn=replica,cn=dc\3Dcompanyz\2Cdc\3Dcom,cn=mapping tree,cn=config
cn: replica
nsDS5Flags: 1
objectClass: top
objectClass: nsds5replica
objectClass: extensibleobject
nsDS5ReplicaType: 3
nsDS5ReplicaRoot: dc=companyz,dc=com
nsds5ReplicaLegacyConsumer: off
nsDS5ReplicaId: 4
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindDN:
krbprincipalname=ldap/noc2prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
nsDS5ReplicaBindDN:
krbprincipalname=ldap/util1prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
nsDS5ReplicaBindDN:
krbprincipalname=ldap/noc3prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
nsDS5ReplicaBindDN:
krbprincipalname=ldap/noc4prd.companyz@companyz.com,cn=services,cn=accounts,dc=companyz,dc=com
nsState:: BABlZwhVDgAFAA==
nsDS5ReplicaName: 2767660e-9e5611e2-b7b6a070-c35ad5d3
nsds5ReplicaAbortCleanRUV: 14:dc=companyz,dc=com
nsds5ReplicaChangeCount: 682699
nsds5replicareapactive: 0

kperrin@noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -b
o=ipaca  
'(&(nsuniqueid=---)(objectclass=nstombstone))'
-p 7389 -h noc1-prd
Enter LDAP Password:
dn: nsuniqueid=---,o=ipaca
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 5317a4490060
nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a45500
60 550878b90060
nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce01800
47 531ce06900030047
nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde800
4c 53f65954004c
nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf21600
51 531bf26500010051
nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a322200
56 531a325600040056
nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf00
5b 53194992005b
nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a4500
061 5317a48a00010061
o: ipaca
nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389}
  550878ab
nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389}
  
nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389}
  
nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389}
  
nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389}
  
nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389}
  
nsruvReplicaLastModified: {replica 97 ldap://util1-prd.companyz.com:7389
} 

-- and here is an example LDIF to remove the last record listed above -

dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task: CLEANRUV97

That doesn't look right. It should look like:

dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
replica-base-dn: dc=companyz,dc=com
replica-id: 97
cn: clean 97

Be careful which RUV you remove. You only want to remove those that are
no longer active.

Thanks for the additional spec on the LDIF, 

Re: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID

[Gould, Joshua]

David,

I had a very similar issue which I posted to the list today. Your notes
indirectly helped me. I think we both had two ends to the same puzzle.

It looks like the range for your AD domain defined in ³ipa idrange-find
‹all² needs to match whats in for your domain in /etc/sssd/sssd.conf.

For your example. Under the [domain/CSNS.MIDDLEBURY.EDU] should have

ldap_idmap_range_min = 182460
ldap_idmap_range_size = 200

Setting these two identically let me resolve AD ID¹s with the id command.
Hopefully this works for you too.



From:  , "David S." 
Date:  Tuesday, March 17, 2015 at 11:18 AM
To:  "freeipa-users@redhat.com" 
Subject:  [Freeipa-users] AD integration: Could not convert objectSID to
a   UNIX ID


We have a trust relationship established between our AD domain and our IPA
domain, and AD users can be found on the IPA server with id and getent
passwd. When a user tries to SSH to the IPA server with AD credentials,
the logs
 show:

(Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_save_user]
(0x0400): Processing user guertin-s
(Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_save_user]
(0x1000): Mapping user [guertin-s] objectSID
[S-1-5-21-1983215674-46037090-646806464-245906] to unix ID
(Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]]
[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID
[S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID


It seems that this is a problem with the ID range, but I can't see where
the problem is. We increased the default ranges of 200,000 to 2,000,000,
which I would think should be able to handle a RID of 245906:

# ipa idrange-find --all

2 ranges matched

  dn: 
cn=CSNS.MIDDLEBURY.EDU_id_range,cn=ranges,cn=etc,dc=csns,dc=middlebury,dc=e
du
  Range name: CSNS.MIDDLEBURY.EDU_id_range
  First Posix ID of the range: 182460
  Number of IDs in the range: 200
  First RID of the corresponding RID range: 1000
  First RID of the secondary RID range: 1
  Range type: local domain range
  iparangetyperaw: ipa-local
  objectclass: top, ipaIDrange, ipaDomainIDRange

  dn: 
cn=MIDDLEBURY.EDU_id_range,cn=ranges,cn=etc,dc=csns,dc=middlebury,dc=edu
  Range name: MIDDLEBURY.EDU_id_range
  First Posix ID of the range: 1
  Number of IDs in the range: 200
  Domain SID of the trusted domain: S-1-5-21-1983215674-46037090-646806464
  Range type: Active Directory trust range with POSIX attributes
  iparangetyperaw: ipa-ad-trust-posix
  objectclass: ipatrustedaddomainrange, ipaIDrange

Number of entries returned 2


But the error remains. What am I missing?



David Guertin



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

Re: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID

[David Guertin]

On 03/17/2015 08:30 PM, Gould, Joshua wrote:

It looks like the range for your AD domain defined in ³ipa idrange-find
‹all² needs to match whats in for your domain in /etc/sssd/sssd.conf.

For your example. Under the [domain/CSNS.MIDDLEBURY.EDU] should have

ldap_idmap_range_min = 182460
ldap_idmap_range_size = 200

Setting these two identically let me resolve AD ID¹s with the id command.
Hopefully this works for you too.
Bingo! Thank you! That was indeed the solution. I needed to set the ID 
range in both places, and now users can log in.


David Guertin

--
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] sssd options ignored?

[Gould, Joshua]

I figured out that the ldap_idmap_range_min and ldap_idmap_range_size need
to match whats in ipa idrange-find --all for the AD domain.

# ipa idrange-mod --base-id=10 --range-size=90 --rid-base=0
Range name: TEST.OSUWMC_id_range

Modified ID range "TEST.OSUWMC_id_range"

Range name: TEST.OSUWMC_id_range
First Posix ID of the range: 10
Number of IDs in the range: 90
First RID of the corresponding RID range: 0
Domain SID of the trusted domain: S-1-5-21-226267946-722566613-1883572810
Range type: Active Directory domain range


/etc/sssd/sssd.conf:
[domain/test.osuwmc]
ldap_idmap_range_min = 10
ldap_idmap_range_size = 90





From:  , Joshua Gould 
Date:  Tuesday, March 17, 2015 at 6:08 PM
To:  "freeipa-users@redhat.com" 
Subject:  [Freeipa-users] sssd options ignored?


I¹ve been getting messages like these when I try the id command for a test
AD domain user:

(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]]
[sdap_get_primary_name] (0x0400): Processing object farus@test.osuwmc
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user]
(0x0400): Processing user farus@test.osuwmc
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user]
(0x1000): Mapping user [farus@test.osuwmc] objectSID
[S-1-5-21-226267946-722566613-1883572810-398410] to unix ID
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]]
[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID
[S-1-5-21-226267946-722566613-1883572810-398410] to a UNIX ID
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user]
(0x0020): Failed to save user [adm-faru03@test.osuwmc]


Various sources all inicate that its a range issue with
ldap_idmap_range_size. I¹ve tried several large values of just
ldap_idmap_range_size as well as adding ldap_idmap_range_min and
ldap_idmap_range_range. All I can figure is that perhaps sssd is ignoring
 the values? Between changing values I did stop sssd, delete the cache and
restart it. This is RHEL7 fully up to date. My SSSD shows 1.12.2-58.

Here is my full sssd.conf.

[domain/unix.test.osuwmc]
debug_level = 9
subdomains_provider = ipa
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = unix.test.osuwmc
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = mid-ipa-vp01.unix.test.osuwmc
chpass_provider = ipa
ipa_server = mid-ipa-vp01.unix.test.osuwmc
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt
#ldap_idmap_range_min = 2000
#ldap_idmap_range_size = 90
#ldap_idmap_range_range = 3602000
ldap_idmap_range_size=100
ldap_id_mapping = True

[sssd]
services = nss, sudo, pam, ssh, pac
config_file_version = 2


domains = unix.test.osuwmc
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]




-- 
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] Only one AD user can able to login to IPA server

[Ben .T.George]

Dear Alex

i already enable debugging and this is what i am getting on error_log while
running : ipa trust-add --type=ad infra.com --admin Administrator --password



[Wed Mar 18 08:10:17.470460 2015] [:error] [pid 15176] ipa: DEBUG: WSGI
wsgi_dispatch.__call__:
[Wed Mar 18 08:10:17.470571 2015] [:error] [pid 15176] ipa: DEBUG: WSGI
jsonserver_session.__call__:
[Wed Mar 18 08:10:17.470821 2015] [:error] [pid 15176] ipa: DEBUG: found
session cookie_id = 15b334c24b28c1e228c1e843efb0bf86
[Wed Mar 18 08:10:17.471493 2015] [:error] [pid 15176] ipa: DEBUG: found
session data in cache with id=15b334c24b28c1e228c1e843efb0bf86
[Wed Mar 18 08:10:17.471613 2015] [:error] [pid 15176] ipa: DEBUG:
jsonserver_session.__call__: session_id=15b334c24b28c1e228c1e843efb0bf86
start_timestamp=2015-03-18T08:06:18 access_timestamp=2015-03-18T08:10:17
expiration_timestamp=2015-03-18T08:26:18
[Wed Mar 18 08:10:17.471698 2015] [:error] [pid 15176] ipa: DEBUG: storing
ccache data into file "/var/run/ipa_memcached/krbcc_15176"
[Wed Mar 18 08:10:17.472404 2015] [:error] [pid 15176] ipa: DEBUG:
get_credential_times:
principal=HTTP/kwtpocpbis01.solaris.local@SOLARIS.LOCAL, authtime=03/17/15
16:04:12, starttime=03/18/15 08:06:17, endtime=03/18/15 16:04:09,
renew_till=01/01/70 03:00:00
[Wed Mar 18 08:10:17.472610 2015] [:error] [pid 15176] ipa: DEBUG:
get_credential_times:
principal=HTTP/kwtpocpbis01.solaris.local@SOLARIS.LOCAL, authtime=03/17/15
16:04:12, starttime=03/18/15 08:06:17, endtime=03/18/15 16:04:09,
renew_till=01/01/70 03:00:00
[Wed Mar 18 08:10:17.472829 2015] [:error] [pid 15176] ipa: DEBUG:
KRB5_CCache FILE:/var/run/ipa_memcached/krbcc_15176 endtime=1426683849
(03/18/15 16:04:09)
[Wed Mar 18 08:10:17.472978 2015] [:error] [pid 15176] ipa: DEBUG:
set_session_expiration_time: duration_type=inactivity_timeout duration=1200
max_age=1426683549 expiration=1426656617.47 (2015-03-18T08:30:17)
[Wed Mar 18 08:10:18.484137 2015] [:error] [pid 15176] ipa: DEBUG: Created
connection context.ldap2
[Wed Mar 18 08:10:18.484255 2015] [:error] [pid 15176] ipa: DEBUG: WSGI
jsonserver.__call__:
[Wed Mar 18 08:10:18.484330 2015] [:error] [pid 15176] ipa: DEBUG: WSGI
WSGIExecutioner.__call__:
[Wed Mar 18 08:10:18.484919 2015] [:error] [pid 15176] ipa: DEBUG: raw:
trust_add(u'infra.com', trust_type=u'ad', realm_admin=u'Administrator',
realm_passwd=u'', all=False, raw=False, version=u'2.113')
[Wed Mar 18 08:10:18.485210 2015] [:error] [pid 15176] ipa: DEBUG:
trust_add(u'infra.com', trust_type=u'ad', realm_admin=u'Administrator',
realm_passwd=u'', all=False, raw=False, version=u'2.113')
lpcfg_load: refreshing parameters from /usr/share/ipa/smb.conf.empty
params.c:pm_process() - Processing configuration file
"/usr/share/ipa/smb.conf.empty"
Processing section "[global]"
INFO: Current debug levels:
  all: 100
  tdb: 100
  printdrivers: 100
  lanman: 100
  smb: 100
  rpc_parse: 100
  rpc_srv: 100
  rpc_cli: 100
  passdb: 100
  sam: 100
  auth: 100
  winbind: 100
  vfs: 100
  idmap: 100
  quota: 100
  acls: 100
  locking: 100
  msdfs: 100
  dmapi: 100
  registry: 100
  scavenger: 100
  dns: 100
  ldb: 100
pm_process() returned Yes
Using binding ncacn_np:kwtpocpbis01.solaris.local[,]
s4_tevent: Added timed event "dcerpc_connect_timeout_handler":
0x7f5a6441f040
s4_tevent: Added timed event "composite_trigger": 0x7f5a6424ed80
s4_tevent: Added timed event "composite_trigger": 0x7f5a644b7f60
s4_tevent: Running timer event 0x7f5a6424ed80 "composite_trigger"
s4_tevent: Destroying timer event 0x7f5a644b7f60 "composite_trigger"
Mapped to DCERPC endpoint \pipe\lsarpc
added interface ens160 ip=172.16.107.244 bcast=172.16.107.255
netmask=255.255.255.0
added interface ens160 ip=172.16.107.244 bcast=172.16.107.255
netmask=255.255.255.0
s4_tevent: Ending timer event 0x7f5a6424ed80 "composite_trigger"
s4_tevent: Added timed event "connect_multi_timer": 0x7f5a64421500
s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7f5a64095f20
s4_tevent: Run immediate event "tevent_req_trigger": 0x7f5a64095f20
s4_tevent: Destroying timer event 0x7f5a64421500 "connect_multi_timer"
Socket options:
SO_KEEPALIVE = 0
SO_REUSEADDR = 0
SO_BROADCAST = 0
TCP_NODELAY = 1
TCP_KEEPCNT = 9
TCP_KEEPIDLE = 7200
TCP_KEEPINTVL = 75
IPTOS_LOWDELAY = 0
IPTOS_THROUGHPUT = 0
SO_REUSEPORT = 0
SO_SNDBUF = 663430
SO_RCVBUF = 261942
SO_SNDLOWAT = 1
SO_RCVLOWAT = 1
SO_SNDTIMEO = 0
SO_RCVTIMEO = 0
TCP_QUICKACK = 1
TCP_DEFER_ACCEPT = 0
s4_tevent: Added timed event "tevent_req_timedout": 0x7f5a6449da70
s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger":
0x7f5a640c4c30
s4_tevent: Run immediate event "tevent_queue_immediate_trigger":
0x7f5a640c4c30
s4_tevent: Destroying timer event 0x7f5a6449da70 "tevent_req_timedout"
Starting GENSEC mechanism spnego
Starting GENSEC submechanism gssapi_krb5
Ticket in credentials cache for admin@SOL

Re: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID

[Alexander Bokovoy]

On Tue, 17 Mar 2015, Guertin, David S. wrote:

When you changed idrange, it helps to remove SSSD cache, both on IPA
master and IPA clients and restart SSSD.


OK, I cleared the cache and restarted sssd with:

sss_cache -E
systemctl restart sssd

Still no change in the error: Could not convert objectSID 
[S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID

FWIW, here's my sssd.conf:

[domain/csns.middlebury.edu]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = csns.middlebury.edu
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = genet.csns.middlebury.edu
chpass_provider = ipa
ipa_server = genet.csns.middlebury.edu
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt

[domain/middlebury.edu]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
debug_level = 10

Wait, why do you have middlebury.edu section here at all? If middlebury
is trusted by csns.middlebury.edu, you should not have a separate
[domain/middlebury.edu] section at all! The whole idea is that SSSD
discovers all domains over trusted forest link path automatically.


--
/ 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] freeIPA.org wiki changes

[Lenka Ryznarova]

Hi,

I've made a few changes (and hopefully improvements) to freeipa.org wiki
concerning mainly test contribution and documentation.
These changes namely consist of:
- Contribute page [1] - the structure is a bit different (for previous
version see [2]), and there is a new paragraph Testing that is supposed
to point contributors to other pages they might need for testing or
contributions
- new Contribute/Tests page [3] - contains basic workflow for
contributing new tests and/or test plans
- Testing Documentation item on Documentation page [4] - so far pretty
much empty, but it is necessary for the test contribution workflow
- new Test plan template page [5] - supposed to make contributor's work
a tiny bit easier, the template is based on existing test plan
documentation already on the wiki

If there is anything unclear or you have any questions, comments,
suggestions or reservations, please let me know.
Please note that this is still work in progress, our goal is to improve
the wiki so that it is easily readable for users as well as contributors
etc. Any feedback concerning any part of the wiki is welcome.

Lenka Ryznarova

[1] http://www.freeipa.org/page/Contribute
[2] http://www.freeipa.org/index.php?title=Contribute&oldid=10811
[3] http://www.freeipa.org/page/Contribute/Tests
[4] http://www.freeipa.org/page/Documentation#Testing_Documentation
[5] http://www.freeipa.org/page/Test_plan_template

-- 
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] sssd options ignored?

[Alexander Bokovoy]

On Tue, 17 Mar 2015, Gould, Joshua wrote:

I figured out that the ldap_idmap_range_min and ldap_idmap_range_size need
to match whats in ipa idrange-find --all for the AD domain.

# ipa idrange-mod --base-id=10 --range-size=90 --rid-base=0
Range name: TEST.OSUWMC_id_range

Modified ID range "TEST.OSUWMC_id_range"

Range name: TEST.OSUWMC_id_range
First Posix ID of the range: 10
Number of IDs in the range: 90
First RID of the corresponding RID range: 0
Domain SID of the trusted domain: S-1-5-21-226267946-722566613-1883572810
Range type: Active Directory domain range


/etc/sssd/sssd.conf:
[domain/test.osuwmc]
ldap_idmap_range_min = 10
ldap_idmap_range_size = 90

There is something completely broken here. You *shouldn't* need to add a
separate domain section for any of the domains coming over the forest
trust link path _at_all_. SSSD automatically derives all needed
parameters for them via its IPA providers for the primary IPA domain.

Jakub, what is going on?








From:  , Joshua Gould 
Date:  Tuesday, March 17, 2015 at 6:08 PM
To:  "freeipa-users@redhat.com" 
Subject:  [Freeipa-users] sssd options ignored?


I¹ve been getting messages like these when I try the id command for a test
AD domain user:

(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]]
[sdap_get_primary_name] (0x0400): Processing object farus@test.osuwmc
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user]
(0x0400): Processing user farus@test.osuwmc
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user]
(0x1000): Mapping user [farus@test.osuwmc] objectSID
[S-1-5-21-226267946-722566613-1883572810-398410] to unix ID
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]]
[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID
[S-1-5-21-226267946-722566613-1883572810-398410] to a UNIX ID
(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user]
(0x0020): Failed to save user [adm-faru03@test.osuwmc]


Various sources all inicate that its a range issue with
ldap_idmap_range_size. I¹ve tried several large values of just
ldap_idmap_range_size as well as adding ldap_idmap_range_min and
ldap_idmap_range_range. All I can figure is that perhaps sssd is ignoring
the values? Between changing values I did stop sssd, delete the cache and
restart it. This is RHEL7 fully up to date. My SSSD shows 1.12.2-58.

Here is my full sssd.conf.

[domain/unix.test.osuwmc]
debug_level = 9
subdomains_provider = ipa
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = unix.test.osuwmc
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = mid-ipa-vp01.unix.test.osuwmc
chpass_provider = ipa
ipa_server = mid-ipa-vp01.unix.test.osuwmc
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt
#ldap_idmap_range_min = 2000
#ldap_idmap_range_size = 90
#ldap_idmap_range_range = 3602000
ldap_idmap_range_size=100
ldap_id_mapping = True

[sssd]
services = nss, sudo, pam, ssh, pac
config_file_version = 2


domains = unix.test.osuwmc
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]




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


--
/ Alexander Bokovoy

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