Re: [Freeipa-users] Creating another sudo rules full

2017-04-28 Thread Dewangga Bachrul Alam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

On 04/28/2017 07:26 PM, Jason B. Nance wrote:
> Hi Dewangga,
> 
>> [root@idm ~]# ipa sudorule-show sudo_rules_rekanalar Rule name:
>> sudo_rules_rekanalar Enabled: TRUE Command category: all RunAs
>> User category: all RunAs Group category: all User Groups:
>> rekanalar Host Groups: rekanalarservers Sudo Option:
>> !authenticate
>> 
>> ## Client [user@server02-v2 ~]$ sudo -l [sudo] password for
>> user:
> 
> The rule in your example above only matches users in the group
> "rekanalar" on servers in the host group "rekanalarservers".  Is
> the user "user" in your example in that group and is the host
> "server02-v2" in your example in that host group?

Yes, usergroup `rekanalar` contain `user`, and `server02-v2` is member
of `rekanalarservers` host group. But, if I assign `user` to usergroup
`admins`, they can do sudo as root.

The goal is, member of usergroup `rekanalar` can do all sudo command
in hostgroup `rekanalarservers` only.

[root@idm ~]# ipa user-show xxx
  User login: xxx
  First name: xxx
  Last name: [removed]
  Home directory: /home/xxx
  Login shell: /bin/bash
  Principal name: xxx@REALM
  Principal alias: xxx@REALM
  Email address: [REMOVED]
  UID: 1107600016
  GID: 1107600016
  Job Title: Rekanalar Director
  SSH public key fingerprint:
51:23:68:4B:BC:17:56:11:50:E1:72:B5:0C:00:B7:B6
  xxx (ssh-rsa)
  Account disabled: False
  Password: False
  Member of groups: rekanalar
  Indirect Member of Sudo rule: sudo_rules_rekanalar
  Kerberos keys available: False

[root@idm ~]# ipa group-show rekanalar
  Group name: rekanalar
  GID: 1107600017
  Member users: xxx
  Member of Sudo rule: sudo_rules_rekanalar

Am I miss something?

> 
> Regards,
> 
> j
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI4BAEBCAAiBQJZA0sdGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl
f9IgoCjNcND0D/4gJ+MFRuaNX9vfuhZwtXnWGCTfhTZiwWBhp6yniAE1PvCvJ0cT
03kGLzNHTp/EPyysXK/oT8yei09B475UFERxfG2rCdY0AN9aCpOHjxQKgWWFw7LJ
3ntLQNoVEFBqpHoa7fbsBpXiKuonqnt0wV1qCNJKUF8z/62TgdsFUmrO7qjMvUbd
FIBCQu2sCZ4Hx4duS8JpHgl9SJSGZkDRJN7XUpnd6bC2+zgUDfkAf74czwbjHQpb
yitDmWslG+V3KpZDcbuMFLhNtwOVVavhhEqacqMoMkuEpSHtHk8oF0CvD/YhuiKv
WUpzyDzLCx1u7xkRBTSRVRouzOi1WvEZ3JVnWSkFFExOW8SNWjpJhXF5ij4kBRF3
CRuKGys65SJA1HSUtH5eIPvXAYGxP+bJsoy72vyFZcy04+Jql9NRIHIMWZaZLe5Z
+qdbhxpBxuCSua1ddMBnGUP/UAmGER0SsxbXq5k6ZjHo9PHwrOlxHZlPyHylbfLr
Go1t2phtam410Rv8oMBB+6vO17QWduGZtBpXxSUXP+hvosE72FkLYnn5IOBIrKvC
Z0GK1jLFDtMU79JECkjm/wfKywgq9XjcyodG6aMaD2iaVqSWhqfphBHm0nbSnEXz
IpDT/WfK0uZkJUaIWYZ3dI7Iv9QCfwwVoWKaKjLkM9ReATti6ks/LYDz8Q==
=TP6o
-END PGP 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


[Freeipa-users] Creating another sudo rules full

2017-04-27 Thread Dewangga Bachrul Alam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

Is it possible to create another sudo rules that same with
sudo_rule_full or admin privileges, it means that the user can run
`sudo su -` without password.

I've create the similar rules, but no luck.

[root@idm ~]# ipa sudorule-show sudo_rules_rekanalar
  Rule name: sudo_rules_rekanalar
  Enabled: TRUE
  Command category: all
  RunAs User category: all
  RunAs Group category: all
  User Groups: rekanalar
  Host Groups: rekanalarservers
  Sudo Option: !authenticate

## Client
[user@server02-v2 ~]$ sudo -l
[sudo] password for user:

But, if I change/add the user to group admins, it's success can invoke
`sudo su -` command without password.

Any helps is appreciated.
Many thanks
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI4BAEBCAAiBQJZAqNgGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl
f9IgoCjNcK5+D/9G06PweGNcJrXuMANcVHysu9Wp97HfExFsGKpoDYU8t2Mip49R
OUD/mLUoPGzNpMVJwOF8V1SMJXjyKUwlnBbGTnOxTvHEzkXyQ0HMsBFVzJJ38LX8
TJItYn8DM45hlnKkVKYM3hTiGSUpNGAM4OLYFQK/AWwx+u/2w1pTjmZQCKCHndvP
/71u3octwTPPZPj2bbxlm8lhZovqPhB3JHpTGSckhvnS77t3W0L4KzaSF4omycni
GbAY8DGTIxXPp33EOJV3JKOpYRrwv5URdgtpNbfWN0l6O8VyJx8A/lamjoQ284gz
p8FJbZni1AoQ3/v2ZIbVcS7UJwqRVnhGFIwmmnlMEWz59NcrIxcxiAbsMepcTmOi
Sq010zOHz3TmRURW2CIPBHGscax0DErIviWFIO+lMy2W/7LSaPoTge4ilDyl7UBu
3uPrEOU5Kh3Z7ar0VP5Pd4FH5OJp3WBXY8tMxPG7h5KniRTuv9/WszP4+L7EFDWR
WdbZYkh1IYJUfsCvlLhYXDULjgacRPXmdQSXQkGD7b1WfmL0Wyy+TnSHKlr4X9LP
dqwKYgjVC6FokoTfRoMi/D27lwkV4PKsNA6nufze9kDxgYC/7VrAEeIFCEedWUfv
oGIBr94eMQYt8QI2GSikiUqJu0QccqtL+8ymE1lhByr9WmuxN6Ni1IhZ3w==
=MUPU
-END PGP 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] CA Certificate didn't automatically transfer to replica(s)

2017-04-27 Thread Dewangga Bachrul Alam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

On 04/26/2017 08:08 PM, Florence Blanc-Renaud wrote:
> On 04/25/2017 10:56 AM, Dewangga Bachrul Alam wrote: Hello!
> 
> Master IPA Server: - I install 1 (one) server as master
> (self-signed) and add/modify using external CA. - I am using
> ipa-cacert-manage install then ipa-certupdate on master
> 
>> Hi,
> 
>> I think I got you wrong... Do you mean that you installed IPA
>> with an integrated IdM CA which was self-signed, then your intent
>> was to move to integrated IdM CA externally signed? In this case,
>> the right command would be ipa-cacert-manage renew --external-ca,
>> and the procedure is described in "Changing the certificate
>> chain" [1].

Ah thanks for your corrections and information, then what should I do?
Should I run ipa-cacert-manage renew --external-ca ?

> 
>> The command ipa-cacert-manage install does not replace the
>> integrated IdM CA but adds the certificate as a known CA.
> 
>> Hope this clarifies, Flo
> 
>> [1] 
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linu
x/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/change-ce
rt-chaining.html
>
>> 
> 
> Replica IPA Server: - I install 1 (one) server as client and
> promoted to ipa-replica: - I run `ipa-client-install` and
> autodiscovery - Then `ipa-replica-install --principal admin
> --admin-password `
> 
> I've hit ipa-certupdate -v to verbose the logs (attached at first 
> email). Then replica server aren't using external CA(s) like master
> did.
> 
> So, I did the same like master, using `ipa-cacert-manage` on
> replica, and it's work fine. If it's normal, then thanks for
> clarifying this.
> 
> On 04/25/2017 02:52 PM, Florence Blanc-Renaud wrote:
>>>> Hi,
>>>> 
>>>> As your email refers to self-signed and signed CA
>>>> certificate, can you please clarify the exact steps that you
>>>> followed? It looks like - you first installed FreeIPA with a
>>>> self-signed CA - you added an external CA (did you use
>>>> ipa-cacert-manage install on 1 server then ipa-certupdate on
>>>> all replicas?) - you replaced the httpd/LDAP certificates
>>>> with a cert signed from the external CA (you probably ran
>>>> ipa-server-certinstall on one server).
>>>> 
>>>> In this case it is normal that the httpd/LDAP certificates on
>>>> the replica were not updated as they are different (each IPA
>>>> server has his own httpd/LDAP cert which contains the
>>>> hostname in its subject). You can check this by performing on
>>>> each server: ipaserver$ sudo certutil -d /etc/httpd/alias/ -L
>>>> -n Server-Cert | grep Subject: Subject:
>>>> "CN=ipaserver.domain.com,O=DOMAIN.COM" ^
>>>> 
>>>> If the goal is to replace the httpd/LDAP certificates on the 
>>>> replica, the command ipa-server-certinstall must also be run
>>>> on the replica with the appropriate certificate.
>>>> 
>>>> HTH, Flo.
>>>> 
>>>> On 04/22/2017 10:41 AM, Dewangga Bachrul Alam wrote: Hello!
>>>> 
>>>> Just update, manually add external CA(s) and signed
>>>> certificated was successful, but why it's didn't
>>>> automatically transferred to replica(s) from master.
>>>> 
>>>> On 04/22/2017 03:00 PM, Dewangga Bachrul Alam wrote:
>>>>>>> Hello!
>>>>>>> 
>>>>>>> I've successfully create replica, everything works fine
>>>>>>> but why my signed CA certificate didn't automatically
>>>>>>> transfer to another replica(s)? Is it normal?
>>>>>>> 
>>>>>>> Trying to add manually, but the certificate in
>>>>>>> replica(s) still using self-signed. Here's the output
>>>>>>> from `ipa-certupdate -v` 
>>>>>>> https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1U
NdI
>
>>>>>>> 
GYh
>>>> 
>>>>>>> 
> yR
>>>>>>> 
>>>>>>> 
>>>> LivL9gydE=
>>>>>>> 
>>>>>>> Interesting line was :
>>>>>>> 
>>>>>>> ipa: DEBUG: stderr= ipa: DEBUG: Starting external
>>>>>>> process ipa: DEBUG: args=/usr/bin/certutil -d
>>>>>>> /etc/ipa/nssdb -L -n IPA CA -a ipa: DEBUG: P

Re: [Freeipa-users] CA Certificate didn't automatically transfer to replica(s)

2017-04-25 Thread Dewangga Bachrul Alam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

Master IPA Server:
- - I install 1 (one) server as master (self-signed) and add/modify
using external CA.
- - I am using ipa-cacert-manage install then ipa-certupdate on master

Replica IPA Server:
- - I install 1 (one) server as client and promoted to ipa-replica:
  - I run `ipa-client-install` and autodiscovery
  - Then `ipa-replica-install --principal admin --admin-password
`

I've hit ipa-certupdate -v to verbose the logs (attached at first
email). Then replica server aren't using external CA(s) like master did.

So, I did the same like master, using `ipa-cacert-manage` on replica,
and it's work fine. If it's normal, then thanks for clarifying this.

On 04/25/2017 02:52 PM, Florence Blanc-Renaud wrote:
> Hi,
> 
> As your email refers to self-signed and signed CA certificate, can
> you please clarify the exact steps that you followed? It looks
> like - you first installed FreeIPA with a self-signed CA - you
> added an external CA (did you use ipa-cacert-manage install on 1 
> server then ipa-certupdate on all replicas?) - you replaced the
> httpd/LDAP certificates with a cert signed from the external CA
> (you probably ran ipa-server-certinstall on one server).
> 
> In this case it is normal that the httpd/LDAP certificates on the 
> replica were not updated as they are different (each IPA server has
> his own httpd/LDAP cert which contains the hostname in its
> subject). You can check this by performing on each server: 
> ipaserver$ sudo certutil -d /etc/httpd/alias/ -L -n Server-Cert |
> grep Subject: Subject: "CN=ipaserver.domain.com,O=DOMAIN.COM" 
> ^
> 
> If the goal is to replace the httpd/LDAP certificates on the
> replica, the command ipa-server-certinstall must also be run on the
> replica with the appropriate certificate.
> 
> HTH, Flo.
> 
> On 04/22/2017 10:41 AM, Dewangga Bachrul Alam wrote: Hello!
> 
> Just update, manually add external CA(s) and signed certificated
> was successful, but why it's didn't automatically transferred to 
> replica(s) from master.
> 
> On 04/22/2017 03:00 PM, Dewangga Bachrul Alam wrote:
>>>> Hello!
>>>> 
>>>> I've successfully create replica, everything works fine but
>>>> why my signed CA certificate didn't automatically transfer to
>>>> another replica(s)? Is it normal?
>>>> 
>>>> Trying to add manually, but the certificate in replica(s)
>>>> still using self-signed. Here's the output from
>>>> `ipa-certupdate -v` 
>>>> https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1UNdI
GYh
>
>>>> 
yR
>>>> 
>>>> 
> LivL9gydE=
>>>> 
>>>> Interesting line was :
>>>> 
>>>> ipa: DEBUG: stderr= ipa: DEBUG: Starting external process
>>>> ipa: DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n
>>>> IPA CA -a ipa: DEBUG: Process finished, return code=255 ipa:
>>>> DEBUG: stdout= ipa: DEBUG: stderr=certutil: Could not find
>>>> cert: IPA CA : PR_FILE_NOT_FOUND_ERROR: File not found
>>>> 
>>>> ipa: DEBUG: Starting external process ipa: DEBUG: 
>>>> args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External CA
>>>> cert -a ipa: DEBUG: Process finished, return code=255 ipa:
>>>> DEBUG: stdout= ipa: DEBUG: stderr=certutil: Could not find
>>>> cert: External CA cert : PR_FILE_NOT_FOUND_ERROR: File not
>>>> found
>>>> 
>>>> FYI: The replica server previously was a client and promoted
>>>> to be a replica by hitting this command:
>>>> `ipa-replica-install --principal admin --admin-password
>>>> admin_password`
>>>> 
>>>> Any hints?
>>>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI4BAEBCAAiBQJY/w9DGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl
f9IgoCjNcBkZD/wM9ia9854l7bIy7dHxKxc7WhduFmbW3AwW0Ren+aLLER/lqMhO
KPNA+fB9ojeoZagmA7JhpM9jblJ4BUaJjLnyf1vhJmOgIX0MgSfmNCr/f/EtfC9R
wZLBImntbGm8yQnsA4f21sdmqnQg9CZN6cg6R8TQ+OuAXdm8jU9Pv3RCLFXzS0mW
oxQdOZ9yNOC9chmfGl6Bz2oGFoEMHCsn1AcEoRHyIUU6jrCNhTVgYcHPVEz0PW73
DEY0ZkwNi9hMcGv5+5F8InYEOdOkS9Lp0juW47xRheztD/PRhYYn1m/FtOxmFa3z
3XS36/w6omSdfH2WOjBRwJduB4REmwHb9oGto7vu6FvWhwUHf9zWVjmJ6DH8tbYU
XgHLmmaSIfwHWc0iYnSLcbHuOaR+l2nOSOLJNg5FfUoIJy5qO51kV3u+pGGELCdr
GexkcXrEHxqk/OO9ioLlTfYIpd9NI6hdLzAsjJEbHuEVZe1B/nrkUOVy/yWOry0N
8muLkJlslMpRwGV4KRFlhcfd49mv9oylKrAxtZ843vz6F1WOKI6vbuS+SJ+wpoer
P1njVQyExrlKi3ruPBIOkxQ6fab9OvredesCo13wLqhfXvezsWpL1RkiqBaMzrsk
NDX/jqEEsk7gbYuawNazcQZP/NGzQZ6nBnVAkXV7vA8D/EV4y1CbW9YfXA==
=07Ri
-END PGP 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] List SPAM

2017-04-23 Thread Dewangga Bachrul Alam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark as spam, and they gone from my inbox. :)

On 04/23/2017 05:10 PM, Prasun Gera wrote:
> This still continues to be a problem. Was any solution identified
> for this ? Why are the emails not obfuscated on the public archives
> ?
> 
> On Tue, Dec 27, 2016 at 7:32 AM, Martin Basti  > wrote:
> 
> 
> 
> On 27.12.2016 13:22, Outback Dingo wrote:
> 
> Im still getting nude porn spam emails and pics from a user
> 
> Kimi Rachel  >
> 
> 
> It is not a user, it is a SPAM bot mining public archives. We
> don't have any control about it we can just un-publish archives
> (tested, spam stopped after that) but they contain a lot of
> information for users.
> 
> JFTR the email is changing.
> 
> 
> -- 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
> 
> 
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI4BAEBCAAiBQJY/I3kGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl
f9IgoCjNcLLgEAChyD/U8wlcTlwjiWgcbyLOcwrFsfvJ1HKUKPi4+fh3VDtX1iQF
XwSyxeMch+obLEraKXI01+rpk6cgxg2xWnhxcUOobsVPzFoQVFnYU9+Ngxpgajx9
XRigMU4lxwBf33IO3DOM7iUGdw4DfRaVZ5H3UUv/6JaQmxwyL6rmxVjcbhMFBcnG
p6Mw+xzsWlIgmf5Kz8e/Eu3pxZXgrxOddtI5z9e7ApZiRavtdi5SuNIEHPsVNC0j
6P2eNA/zK3E3IpfknWB2wCoR2+gB/1fYzP71iz55exy3Sefnv0CLpjnhRoPsuzVm
iiFeBF64KOYWmK0Uw3ftfNEw67bHPcvlnba4Ftj2PsTkwupH9/RpccQ0t9yOl+gi
fdmY7s91MdODNXiKR5GG/bT5JPyBE5VtkufZIqJDLliqn1kVkCLqSgOLZyQflhI6
2pZLHufBMiMGKgdEfSx1DdqmPILLqlIhr+kqAn0qtyIDlz1jV5cic9issi4Z/aWi
MVECMBkPu5kNnANVKBz2YjbL8LD/Dr15R2WZVH7drzAc4Byo88DRpwESSqS0W4hX
ai1nVTxyD8CdW8Ab63rLwmvF8li39V1Xse2hiinntaYa/Ap6/WFNOR7Qyon5yxnG
/AFpAgtWgH0rjnNMNnYZO3Ck7hpSgdCCgqOTOKc+3FHqqcg+K7uckqdswg==
=G2rj
-END PGP 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


[Freeipa-users] CA Certificate didn't automatically transfer to replica(s)

2017-04-23 Thread Dewangga Bachrul Alam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

I've successfully create replica, everything works fine but why my
signed CA certificate didn't automatically transfer to another
replica(s)? Is it normal?

Trying to add manually, but the certificate in replica(s) still using
self-signed. Here's the output from `ipa-certupdate -v`
https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1UNdIGYhyR
LivL9gydE=

Interesting line was :

ipa: DEBUG: stderr=
ipa: DEBUG: Starting external process
ipa: DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n IPA CA -a
ipa: DEBUG: Process finished, return code=255
ipa: DEBUG: stdout=
ipa: DEBUG: stderr=certutil: Could not find cert: IPA CA
: PR_FILE_NOT_FOUND_ERROR: File not found

ipa: DEBUG: Starting external process
ipa: DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External CA
cert -a
ipa: DEBUG: Process finished, return code=255
ipa: DEBUG: stdout=
ipa: DEBUG: stderr=certutil: Could not find cert: External CA cert
: PR_FILE_NOT_FOUND_ERROR: File not found

FYI:
The replica server previously was a client and promoted to be a
replica by hitting this command: `ipa-replica-install --principal
admin --admin-password admin_password`

Any hints?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI4BAEBCAAiBQJY+w2NGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl
f9IgoCjNcFn2EACjKLkv3XokuWsJwjXSyKV3IP6Gh54Os/bNVkAS5rBb5unRl/BQ
FG1eV5/Mgq0kSBbbC5C1qvXwSjeaJMjul0ssJ+fldL4d0S+S+s/nos7BsyjZZaQV
VP1c4iRrCUeHt//FdTaN9AslsW+2IUlKQ5qFBX+1cN8Kc4Q9yIBmr4e1p94dJCnu
z8Fwe/RZS1e69QOWLdfNYsEhGiwXKVqyWaX139kvpOXOaj41yehC0Zzkli6HxpFu
lypSRHFAPYLt9fWS0pglPk3PQFLlGC5bNYLTFdADeVn1siME6eZl09+cUUFp2o79
bF2/7+g98QExJ9LY6IxUrrvgvc42c9dX7SY2GU1niEIyxcwXbxt8gWoY91YjEIGX
Ibq5vc6FnsQB2rN3L+nO5WvwimH4wEqnFU1YJ+dDh+A80G25JQuLZ4ZBYsuH7rVE
T0TH9KEYD8BR46ca9prhv1WNVt0wDDgfWRLc6afLBdJ2eUrx7uXijauyibevc1mI
X2OfKELlejsrcDb6hyoS3z18cOES9oJmfpsrNdxGi2X59HVp1o67R4QprQ9ZrGld
Eb4njQRXF45O4ZSWT6tGteltf1KVKfoKaxL41S8DPf3wY1JFy/OmtYjNx5fSLcPL
b+TRSimv5q6YWIw5/mqmVlsdife5XnFTGSIBBOkssLx0qnqcpCetuoCnQw==
=jRl3
-END PGP 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] CA Certificate didn't automatically transfer to replica(s)

2017-04-23 Thread Dewangga Bachrul Alam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

Just update, manually add external CA(s) and signed certificated was
successful, but why it's didn't automatically transferred to
replica(s) from master.

On 04/22/2017 03:00 PM, Dewangga Bachrul Alam wrote:
> Hello!
> 
> I've successfully create replica, everything works fine but why my 
> signed CA certificate didn't automatically transfer to another 
> replica(s)? Is it normal?
> 
> Trying to add manually, but the certificate in replica(s) still
> using self-signed. Here's the output from `ipa-certupdate -v` 
> https://paste.fedoraproject.org/paste/U53pyXUa7Z34kLfiKh1QKV5M1UNdIGYh
yR
>
> 
LivL9gydE=
> 
> Interesting line was :
> 
> ipa: DEBUG: stderr= ipa: DEBUG: Starting external process ipa:
> DEBUG: args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n IPA CA -a 
> ipa: DEBUG: Process finished, return code=255 ipa: DEBUG: stdout= 
> ipa: DEBUG: stderr=certutil: Could not find cert: IPA CA :
> PR_FILE_NOT_FOUND_ERROR: File not found
> 
> ipa: DEBUG: Starting external process ipa: DEBUG:
> args=/usr/bin/certutil -d /etc/ipa/nssdb -L -n External CA cert -a 
> ipa: DEBUG: Process finished, return code=255 ipa: DEBUG: stdout= 
> ipa: DEBUG: stderr=certutil: Could not find cert: External CA cert 
> : PR_FILE_NOT_FOUND_ERROR: File not found
> 
> FYI: The replica server previously was a client and promoted to be
> a replica by hitting this command: `ipa-replica-install
> --principal admin --admin-password admin_password`
> 
> Any hints?
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI4BAEBCAAiBQJY+xccGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl
f9IgoCjNcJAHEACO4nF7guN05MjmqYFDwDrjhvWgMN2sRn+Nxt/aA+xziIOJJGaA
Rr97TbODiTiefBkjVoiYM6dxr6VK5ViPZIbe0IAjafCRACAKggyCRtb2j8+vb7Jd
imJN/MC0zSMCdATSs2b95uT7QrUiVHwt/xmKzJ44ezIYON+YOtgndk0QXynXHqjm
H6HcQkh4ZcC8antiFdbC+H8z4Iv4Ypnhdr80RtqLqQ6esnZXnWdIg3X0aRb6w1fw
KEDHemhfKeu5hMxpi2AQdesO4j+XhvW6TfvKymScbWv1PoEuLAsgQGdoxVmhkjN8
LKixSghHlg8A61DXtA9J2uaPUUKjVMmoKH4CFD0RLQlQJ+f4KfApbNzHZTBnSL8D
64c5WjJdtAY5LUArakwZ/EJt5N5AJEFDIoSWM3if/jpDIVFEAaDzFKIQvyLKyMIn
yHxNIcWcSoP/YwzZXMttWx5dNRkermmWEcvPsqovoT9BRlI/e700o3xqQk7V0720
7TniU1uZaBpLkJOxHUoWssaWfVHcWEBnw0UeU7bl4nKnAo7hkQs3/iJXwQiLk4aw
338ZIniIrDSmUmmfqJuhQrFPNK+heCOno5O/99Sa1bs0lTQgRRjMq5Q7mIajEYYI
NedyVj0VQ8R42rbgomWJPJP/uU+kirN8CpEc+d/IWNQE2t+5hOX5nme5dw==
=anzk
-END PGP 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] FreeIPA state - performace, commercial usage

2015-08-20 Thread Dewangga Bachrul Alam


On 08/21/2015 09:44 AM, Vaclav Adamec wrote:
> Hi,
> 
> Don't want to start flame, but my question is quite simple, is there
> anybody who use it in real production/commercial setup without any
> major issues ? don't you lack commercial support ? no issues with
> auditors ?

FreeIPA is upstream for Red Hat IdM, if you wanna get
commercial/enterprise support, go for Red Hat Subscription.

> 
>  after a year/two of usage/testing/troubleshooting of freeipa/redhat
> ipa it seems, for me as a simple admin, to be still not very mature
> project, even basic configuration isn't very stable/solid to use it in
> real production. I started with latest freeipa on fedora with one
> server (VM vmware), then add other master replicas but after many
> issues I carefully keep one server on redhat 7 with up2date version of
> ipa from rhel repos, default installation setup, no replication. But
> still with stability issue (processes died occasionally, mostly due
> multiple clients removing, sometimes it dies completely with cryptic
> errors in journal (but sometimes no errors at all just wait for
> something during restart) and only fast option is restore from snaphot
> backups with loosing some clients). Performance is also issue, we
> cannot register more then 4-5 servers at once, or it will timeout (but
> no visible network or cpu/mem load issue).
> 
> As there are no other complex solutions like IPA it's quite hard
> decide what to use as a replacement, but right now it's seems that we
> have no other option and we probably switch to simple openldap and
> missing functionality cover by puppet and some 2factor solution.
> 
> We don't need anything special, no dns handling, no certificates, no
> AD connection, just simple servers/clients, users with groups and
> rules for access/sudo. Multimaster (with DNS SRV) solution for higher
> performance and reliability would be nice, but not necessary if we can
> keep it stable and handle more clients registration. We have tens of
> users/groups, hundreds servers/clients with random registration
> "burst" as we use it also for temp. build environments and OpenStack
> instances.
> 
> Oficial support from RedHat is not very helpful, also they don't
> provide any real training for IPA, so only option is mail conference
> (very helpful, thanks for that) and tones of documentation/examples
> for variety of versions, but for such complex thing probably not
> enough for commercial use.

IMHO, there's no official support from Red Hat on FreeIPA, I was though
it was community support. If you wanna official support or real training
for IdM (Identity Management) from Red Hat, go to
https://access.redhat.com/products/Identity_Management

> 
> Can I ask you for your opinion ?
> 
> Vasek
> 

-- 
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] Sudo command not working

2015-08-13 Thread Dewangga Bachrul Alam
Hello!

On 08/13/2015 03:09 PM, Jakub Hrozek wrote:
> On Thu, Aug 13, 2015 at 03:01:40PM +0700, Dewangga Bachrul Alam wrote:
>> Hello!
>>
>> Should I reboot the machine after changing sudo.conf file?
> 
> No, it's read by sudo on every invocation. There is no sudo deamon or
> such.
> 

Yes, I found the problem :)
Missconfig on `As Whom` category, the current user should not be insert
there :D

Got the clue from sudo debug.

... snip ...
Aug 13 15:48:06 sudo[26020] searching SSSD/LDAP for sudoers entries
Aug 13 15:48:06 sudo[26020] sssd/ldap sudoRunAsUser 'subhan' ... not
... snip ...

Thanks Jakub.

-- 
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] Having problem with pwd_expiration

2015-08-13 Thread Dewangga Bachrul Alam
Hello!

I've been discovered something about pwd_expiration on freeipa 4.1.4,
I got a line from sssd_DOMAIN.log :

... snip ...
(Thu Aug 13 12:25:39 2015) [sssd[be[mydomain.co.id]]]
[confdb_get_domain_internal] (0x1000): pwd_expiration_warning is -1
... snip ...

$ ipa pwpolicy-find
  Group: global_policy
  Max lifetime (days): 90
  Min lifetime (hours): 1
  History size: 0
  Character classes: 0
  Min length: 8
  Max failures: 6
  Failure reset interval: 60
  Lockout duration: 600

The password policy should be available on next 90 days after I creating
the password, isn't it? But I tried to login, the password was expired.

$ sudo su -
[sudo] password for subhan:
Password expired. Change your password now.
sudo: Account or password is expired, reset your password and try again
Current Password:
New password:
Retype new password:
sudo: pam_chauthtok: Authentication token manipulation error

Every time I reset the password from ipa server, the password always
expired before 90 days (based on global_policy).

Got this from /var/log/secure (on ipa client):

Aug 13 15:23:59 rosaliaindah sudo: pam_sss(sudo:auth): received for user
subhan: 12 (Authentication token is no longer valid; new one required)
Aug 13 15:24:01 rosaliaindah sudo: pam_sss(sudo:account): User info
message: Password expired. Change your password now.
Aug 13 15:24:01 rosaliaindah sudo: subhan : Account or password is
expired, reset your password and try again ; TTY=pts/2 ;
PWD=/home/subhan ; USER=root ; COMMAND=/bin/su -
Aug 13 15:24:01 rosaliaindah sudo: pam_unix(sudo:chauthtok): user
"subhan" does not exist in /etc/passwd
Aug 13 15:24:09 rosaliaindah sudo: pam_unix(sudo:chauthtok): user
"subhan" does not exist in /etc/passwd
Aug 13 15:24:10 rosaliaindah sudo: pam_sss(sudo:chauthtok): Password
change failed for user subhan: 22 (Authentication token lock busy)
Aug 13 15:24:10 rosaliaindah sudo: subhan : pam_chauthtok:
Authentication token manipulation error ; TTY=pts/2 ; PWD=/home/subhan ;
USER=root ; COMMAND=/bin/su -
Aug 13 15:24:11 rosaliaindah sudo: pam_unix(sudo:auth): conversation failed
Aug 13 15:24:11 rosaliaindah sudo: pam_unix(sudo:auth): auth could not
identify password for [subhan]

Got clue form
http://www.redhat.com/archives/freeipa-users/2015-January/msg00183.html,
but still no luck.
I add krb5_auth_timeout = 30s to sssd.conf.

Note: krb5_child.log shows nothing.

-- 
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] Sudo command not working

2015-08-13 Thread Dewangga Bachrul Alam
Hello!

Should I reboot the machine after changing sudo.conf file?

On 08/12/2015 09:26 PM, Jakub Hrozek wrote:
> On Wed, Aug 12, 2015 at 07:44:15PM +0700, Dewangga Bachrul Alam wrote:
>> Hello!
>>
>> On 08/12/2015 07:36 PM, Jakub Hrozek wrote:
>>> On Wed, Aug 12, 2015 at 07:30:52PM +0700, Dewangga Bachrul Alam wrote:
>>>> Hello!
>>>>
>>>> I'm having problem with sudo command, the sudo command was sucessfully
>>>> initiated. But user still requested for password. For example :
>>>>
>>>> ipa-client $ sudo -l
>>>> Matching Defaults entries for subhan on this host:
>>>> requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS
>>>> DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1
>>>> PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE
>>>> LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY
>>>> LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL
>>>> LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
>>>> secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
>>>>
>>>> User subhan may run the following commands on this host:
>>>> (subhan) NOPASSWD: /bin/tail, /usr/bin/tail
>>>>
>>>> ipa-server $ ipa user-show subhan
>>>>   User login: subhan
>>>>   First name: [REMOVED]
>>>>   Last name: [REMOVED]
>>>>   Home directory: /home/subhan
>>>>   Login shell: /bin/bash
>>>>   Email address: [REMOVED]
>>>>   UID: 64207
>>>>   GID: 64207
>>>>   Job Title: Developer
>>>>   Account disabled: False
>>>>   Password: False
>>>>   Member of groups: g_gmt_developer, developer
>>>>   Member of Sudo rule: gmt_developer
>>>>   Member of HBAC rule: gmt_webserver
>>>>   Kerberos keys available: False
>>>>   SSH public key fingerprint: [REMOVED]
>>>>
>>>> ipa-server $ ipa sudocmd-find
>>>> ---
>>>> 2 Sudo Commands matched
>>>> ---
>>>>   Sudo Command: /bin/tail
>>>>   Sudo Command Groups: reading-files
>>>>
>>>>   Sudo Command: /usr/bin/tail
>>>>   Sudo Command Groups: reading-files
>>>>
>>>> ipa-server $ ipa sudorule-show gmt_developer
>>>>   Rule name: gmt_developer
>>>>   Enabled: TRUE
>>>>   Users: subhan
>>>>   User Groups: g_gmt_developer
>>>>   Host Groups: gmt_webserver
>>>>   Sudo Allow Command Groups: reading-files
>>>>   RunAs Users: subhan
>>>>   Sudo Option: !authenticate
>>>>
>>>>
>>>> ipa-client $ sudo tail -f /var/log/nginx/access.log
>>>> [sudo] password for subhan:
>>>> ipa-client $ sudo tail /var/log/nginx/access.log
>>>> [sudo] password for subhan:
>>>>
>>>> There's nothing information from sssd_sudo.log about this issue.
>>>
>>> In general sssd acts as a cache of the sudo rules, the decision to auth
>>> or not is done by sudo. So on the sssd side you can make sure the sudo
>>> option value was fetched, but you'll probably get a more useful
>>> debugging from sudo itself.
>>>
>>
>> Here is the sudo message from /var/log/secure :
>>
>> Aug 12 19:41:05 rosaliaindah su: pam_unix(su-l:session): session opened
>> for user subhan by dewangga(uid=0)
>> Aug 12 19:41:14 rosaliaindah sudo: pam_unix(sudo:auth): conversation failed
>> Aug 12 19:41:14 rosaliaindah sudo: pam_unix(sudo:auth): auth could not
>> identify password for [subhan]
>> Aug 12 19:41:14 rosaliaindah sudo: pam_sss(sudo:auth): authentication
>> failure; logname=dewangga uid=64207 euid=0 tty=/dev/pts/0
>> ruser=subhan rhost= user=subhan
>> Aug 12 19:41:14 rosaliaindah sudo: pam_sss(sudo:auth): received for user
>> subhan: 7 (Authentication failure)
>> Aug 12 19:41:14 rosaliaindah sudo: subhan : command not allowed ;
>> TTY=pts/0 ; PWD=/home/subhan ; USER=root ; COMMAND=/bin/tail -f
>> /var/log/nginx/error.log
>>
>> The sudo option (!authenticate) should be working, because I can invoke
>> `sudo -l` command without password. So I think sssd is not the problem.
>> CMIIW. :)
> 
> Look into man sudo.conf, depending on your sudo version the options to
> enable debugging for sudo differ.
> 

-- 
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] Sudo command not working

2015-08-12 Thread Dewangga Bachrul Alam
Hello!

On 08/12/2015 07:36 PM, Jakub Hrozek wrote:
> On Wed, Aug 12, 2015 at 07:30:52PM +0700, Dewangga Bachrul Alam wrote:
>> Hello!
>>
>> I'm having problem with sudo command, the sudo command was sucessfully
>> initiated. But user still requested for password. For example :
>>
>> ipa-client $ sudo -l
>> Matching Defaults entries for subhan on this host:
>> requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS
>> DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1
>> PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE
>> LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY
>> LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL
>> LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
>> secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
>>
>> User subhan may run the following commands on this host:
>> (subhan) NOPASSWD: /bin/tail, /usr/bin/tail
>>
>> ipa-server $ ipa user-show subhan
>>   User login: subhan
>>   First name: [REMOVED]
>>   Last name: [REMOVED]
>>   Home directory: /home/subhan
>>   Login shell: /bin/bash
>>   Email address: [REMOVED]
>>   UID: 64207
>>   GID: 64207
>>   Job Title: Developer
>>   Account disabled: False
>>   Password: False
>>   Member of groups: g_gmt_developer, developer
>>   Member of Sudo rule: gmt_developer
>>   Member of HBAC rule: gmt_webserver
>>   Kerberos keys available: False
>>   SSH public key fingerprint: [REMOVED]
>>
>> ipa-server $ ipa sudocmd-find
>> ---
>> 2 Sudo Commands matched
>> ---
>>   Sudo Command: /bin/tail
>>   Sudo Command Groups: reading-files
>>
>>   Sudo Command: /usr/bin/tail
>>   Sudo Command Groups: reading-files
>>
>> ipa-server $ ipa sudorule-show gmt_developer
>>   Rule name: gmt_developer
>>   Enabled: TRUE
>>   Users: subhan
>>   User Groups: g_gmt_developer
>>   Host Groups: gmt_webserver
>>   Sudo Allow Command Groups: reading-files
>>   RunAs Users: subhan
>>   Sudo Option: !authenticate
>>
>>
>> ipa-client $ sudo tail -f /var/log/nginx/access.log
>> [sudo] password for subhan:
>> ipa-client $ sudo tail /var/log/nginx/access.log
>> [sudo] password for subhan:
>>
>> There's nothing information from sssd_sudo.log about this issue.
> 
> In general sssd acts as a cache of the sudo rules, the decision to auth
> or not is done by sudo. So on the sssd side you can make sure the sudo
> option value was fetched, but you'll probably get a more useful
> debugging from sudo itself.
> 

Here is the sudo message from /var/log/secure :

Aug 12 19:41:05 rosaliaindah su: pam_unix(su-l:session): session opened
for user subhan by dewangga(uid=0)
Aug 12 19:41:14 rosaliaindah sudo: pam_unix(sudo:auth): conversation failed
Aug 12 19:41:14 rosaliaindah sudo: pam_unix(sudo:auth): auth could not
identify password for [subhan]
Aug 12 19:41:14 rosaliaindah sudo: pam_sss(sudo:auth): authentication
failure; logname=dewangga uid=64207 euid=0 tty=/dev/pts/0
ruser=subhan rhost= user=subhan
Aug 12 19:41:14 rosaliaindah sudo: pam_sss(sudo:auth): received for user
subhan: 7 (Authentication failure)
Aug 12 19:41:14 rosaliaindah sudo: subhan : command not allowed ;
TTY=pts/0 ; PWD=/home/subhan ; USER=root ; COMMAND=/bin/tail -f
/var/log/nginx/error.log

The sudo option (!authenticate) should be working, because I can invoke
`sudo -l` command without password. So I think sssd is not the problem.
CMIIW. :)

-- 
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] Sudo command not working

2015-08-12 Thread Dewangga Bachrul Alam
Hello!

I'm having problem with sudo command, the sudo command was sucessfully
initiated. But user still requested for password. For example :

ipa-client $ sudo -l
Matching Defaults entries for subhan on this host:
requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS
DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1
PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE
LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY
LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL
LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User subhan may run the following commands on this host:
(subhan) NOPASSWD: /bin/tail, /usr/bin/tail

ipa-server $ ipa user-show subhan
  User login: subhan
  First name: [REMOVED]
  Last name: [REMOVED]
  Home directory: /home/subhan
  Login shell: /bin/bash
  Email address: [REMOVED]
  UID: 64207
  GID: 64207
  Job Title: Developer
  Account disabled: False
  Password: False
  Member of groups: g_gmt_developer, developer
  Member of Sudo rule: gmt_developer
  Member of HBAC rule: gmt_webserver
  Kerberos keys available: False
  SSH public key fingerprint: [REMOVED]

ipa-server $ ipa sudocmd-find
---
2 Sudo Commands matched
---
  Sudo Command: /bin/tail
  Sudo Command Groups: reading-files

  Sudo Command: /usr/bin/tail
  Sudo Command Groups: reading-files

ipa-server $ ipa sudorule-show gmt_developer
  Rule name: gmt_developer
  Enabled: TRUE
  Users: subhan
  User Groups: g_gmt_developer
  Host Groups: gmt_webserver
  Sudo Allow Command Groups: reading-files
  RunAs Users: subhan
  Sudo Option: !authenticate


ipa-client $ sudo tail -f /var/log/nginx/access.log
[sudo] password for subhan:
ipa-client $ sudo tail /var/log/nginx/access.log
[sudo] password for subhan:

There's nothing information from sssd_sudo.log about this issue.

ipa-server $ cat /etc/sssd/sssd.conf

... snip ...
[sudo]
debug_level = 7
... snip ...

FYI, running on IPA Server 4.1.4 on EL7.
$ ipa --version
VERSION: 4.1.4, API_VERSION: 2.114

$ uname -a
Linux [REMOVED] 3.10.0-229.7.2.el7.x86_64 #1 SMP Tue Jun 23 22:06:11 UTC
2015 x86_64 x86_64 x86_64 GNU/Linux

Any hints to debug and solve this issue? Any help are appreciated. :)

-- 
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] Different domain enrollment

2015-08-12 Thread Dewangga Bachrul Alam
Hello!

On 08/11/2015 06:25 PM, Alexander Bokovoy wrote:
> On Tue, 11 Aug 2015, Dewangga Bachrul Alam wrote:
>> Hello!
>>
>> On 08/11/2015 01:43 PM, Alexander Bokovoy wrote:
>>> On Tue, 11 Aug 2015, Dewangga Bachrul Alam wrote:
>>>> Hello!
>>>>
>>>> I'm having problem with different hostname with primary domain on ipa
>>>> server. For example, my primary domain is mydomain.co.id, and then if
>>>> the server hostname using mydomain.co.id, the dns discover was
>>>> sucessfully.
>>>>
>>>> The problem come if the client hostname using different domain, for
>>>> example anotherdomain.com, the dns discovery was failed. Is there any
>>>> way to solve it? Should I enter it manually?
>>> Details of autodiscovery and suggestions how to configure are explained
>>> in the man page for ipa-client-install, section on DNS autodiscovery.
>>
>> Thanks for your hints, but I have another question after read the man
>> pages. The best practice register client to ipa server is using --domain
>> or add similar DNS record?
> You still would need _kerberos TXT record for runtime Kerberos realm
> detection unless your krb5.conf would contain domain_realms entry for
> your DNS domain.
> 
> Using --domain option is, of course, easy.
> 
> 
Yes, using --domain is very easy.
>> I've tried to create new record on anotherdomain.com. (eg. original dns
>> record was _ldap._tcp.mydomain.co.id, and IP create new record for
>> _ldap._tcp.anotherdomain.com).
>>
>> New dns record on anotherdomain.com is "_ldap._tcp, _ntp._udp,
>> _kpasswd._udp, _kpasswd._tcp, _kerberos._udp, _kerberos._tcp,
>> _kerberos-master._udp, _kerberos-master._tcp".
>>
>> anotherdomain.com $ ipa-client-install
>> Discovery was successful!
>> Hostname: spectre.anotherdomain.com
>> Realm: MYDOMAIN.CO.ID
>> DNS Domain: anotherdomain.com
>> IPA Server: ipa.anotherdomain.com
>> BaseDN: dc=merahciptamedia,dc=co,dc=id
>>
>> Continue to configure the system with these values? [no]: yes
>> Synchronizing time with KDC...
>> Unable to sync time with IPA NTP server, assuming the time is in sync.
>> Please check that 123 UDP port is opened.
>> User authorized to enroll computers: admin
>> Password for ad...@merahciptamedia.co.id:
>> Unable to download CA cert from LDAP.
>> Do you want to download the CA cert from
>> http://ipa.anotherdomain.com/ipa/config/ca.crt?
>> (this is INSECURE) [no]:
>>
>> Is it safe? Or just use --domain parameter?
> I don't think 'Unable to download CA cert from LDAP' is connected to the
> problem you have but you should be able to see what was the issue in
> /var/log/ipaclient-install.log.
> 
I think the client can't download the ca cert from LDAP because ca.crt
was registered on mydomain.co.id (not anotherdomain.com). For the
flexibility and my limited knowledge, it is better to use --domain (for
now) :D

-- 
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] Different domain enrollment

2015-08-11 Thread Dewangga Bachrul Alam
Hello!

On 08/11/2015 01:43 PM, Alexander Bokovoy wrote:
> On Tue, 11 Aug 2015, Dewangga Bachrul Alam wrote:
>> Hello!
>>
>> I'm having problem with different hostname with primary domain on ipa
>> server. For example, my primary domain is mydomain.co.id, and then if
>> the server hostname using mydomain.co.id, the dns discover was
>> sucessfully.
>>
>> The problem come if the client hostname using different domain, for
>> example anotherdomain.com, the dns discovery was failed. Is there any
>> way to solve it? Should I enter it manually?
> Details of autodiscovery and suggestions how to configure are explained
> in the man page for ipa-client-install, section on DNS autodiscovery.

Thanks for your hints, but I have another question after read the man
pages. The best practice register client to ipa server is using --domain
or add similar DNS record?

I've tried to create new record on anotherdomain.com. (eg. original dns
record was _ldap._tcp.mydomain.co.id, and IP create new record for
_ldap._tcp.anotherdomain.com).

New dns record on anotherdomain.com is "_ldap._tcp, _ntp._udp,
_kpasswd._udp, _kpasswd._tcp, _kerberos._udp, _kerberos._tcp,
_kerberos-master._udp, _kerberos-master._tcp".

anotherdomain.com $ ipa-client-install
Discovery was successful!
Hostname: spectre.anotherdomain.com
Realm: MYDOMAIN.CO.ID
DNS Domain: anotherdomain.com
IPA Server: ipa.anotherdomain.com
BaseDN: dc=merahciptamedia,dc=co,dc=id

Continue to configure the system with these values? [no]: yes
Synchronizing time with KDC...
Unable to sync time with IPA NTP server, assuming the time is in sync.
Please check that 123 UDP port is opened.
User authorized to enroll computers: admin
Password for ad...@merahciptamedia.co.id:
Unable to download CA cert from LDAP.
Do you want to download the CA cert from
http://ipa.anotherdomain.com/ipa/config/ca.crt?
(this is INSECURE) [no]:

Is it safe? Or just use --domain parameter?

-- 
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] Different domain enrollment

2015-08-10 Thread Dewangga Bachrul Alam
Hello!

I'm having problem with different hostname with primary domain on ipa
server. For example, my primary domain is mydomain.co.id, and then if
the server hostname using mydomain.co.id, the dns discover was sucessfully.

The problem come if the client hostname using different domain, for
example anotherdomain.com, the dns discovery was failed. Is there any
way to solve it? Should I enter it manually?

-- 
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] Is there any delay after applied rules to user?

2015-07-30 Thread Dewangga Bachrul Alam
Hello!

Sorry for making you confused.

The main problem is the cache on ipa server/client. How long the cache
remain active and refresh with correct policy/rules.

Whenever I set the sudo rules, modify another configuration (policy,
etc), it's always have delay.

And until now, the global_policy still didn't use correct configuration.
It's still using min 0, max 0 configuration (I set this policy
yesterday, and was revert it back to min 1 max 90 on yesterday too)

Any hints?

On 07/31/2015 01:47 AM, Jakub Hrozek wrote:
> On Thu, Jul 30, 2015 at 09:50:23PM +0700, Dewangga Bachrul Alam wrote:
>> Hello!
>>
>> I don't know start from where to tracking down this issue. I found
>> another something interesting.
>>
>> 1. Set `global_policy` password expired (both min and max) to 0 (zero)
>> 2. Add user called `dummy`
>> 3. Set global_policy password expired min (1) and max (90).
>> 4. Add user called `dummy2`
>>
>> Both user dummy and dummy2 have same password expiration :D
>> This problem is same with assign sudo/group to user.
>>
>> I was set debug_level = 7 to following section in sssd.conf :
>>
>> [domain/mydomain.co.id]
>> .. debug_level = 7 ..
>>
>> [sssd]
>> .. debug_level = 7 ..
>>
>> [sudo]
>> .. debug_level = 7 ..
>>
>> I didn't find any related information about the 4 step above.
> 
> I'm sorry, but I'm getting a bit confused about what is and what is not
> the problem. Can we take a step back and see what works in your
> environment and what does not?
> 
> Can you describe the workflow?
> 

-- 
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] Is there any delay after applied rules to user?

2015-07-30 Thread Dewangga Bachrul Alam
Hello!

I don't know start from where to tracking down this issue. I found
another something interesting.

1. Set `global_policy` password expired (both min and max) to 0 (zero)
2. Add user called `dummy`
3. Set global_policy password expired min (1) and max (90).
4. Add user called `dummy2`

Both user dummy and dummy2 have same password expiration :D
This problem is same with assign sudo/group to user.

I was set debug_level = 7 to following section in sssd.conf :

[domain/mydomain.co.id]
.. debug_level = 7 ..

[sssd]
.. debug_level = 7 ..

[sudo]
.. debug_level = 7 ..

I didn't find any related information about the 4 step above.

On 07/30/2015 08:54 PM, Jakub Hrozek wrote:
> On Thu, Jul 30, 2015 at 07:09:47PM +0700, Dewangga Bachrul Alam wrote:
>> Hello Jakub!
>>
>> Sorry for delayed email,
>> My bad, I disabled cache_credentials, not sssd_cache.
> 
> Then I think it's completely unrelated to the sudo rules problem.
> 
>>
>> I tried modified my user `dewangga` to remove sudo rules, the cache
>> still active even I restart the sssd service and delete all ccache* files.
> 
> Yes, cache can't be completely disabled with sssd. See:
> https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/
> 
>>
>> There's no information on sssd log folder.
>>
>> -rw---.  1 root root0 Jul 29 19:26 krb5_child.log
>> -rw---.  1 root root 105K Jul 30 04:49 ldap_child.log
>> -rw---.  1 root root0 Jul 29 19:26 sssd.log
>> -rw---.  1 root root0 Jul 29 19:26 sssd_merahciptamedia.co.id.log
>> -rw---.  1 root root0 Jul 29 19:26 sssd_nss.log
>> -rw---.  1 root root0 Jul 29 19:26 sssd_pac.log
>> -rw---.  1 root root0 Jul 29 19:26 sssd_pam.log
>> -rw---.  1 root root0 Jul 29 19:26 sssd_ssh.log
>> -rw---.  1 root root0 Jul 29 19:26 sssd_sudo.log
>>
>>
>> On 07/30/2015 02:33 PM, Jakub Hrozek wrote:
>>> On Thu, Jul 30, 2015 at 02:26:03PM +0700, NitrouZ wrote:
>>>> Hello!
>>>>
>>>> I set the cache value to False on sssd.conf. (On IPA server and client).
>>>
>>> Can you show me the exact config directive you used?
>>>
>>>>
>>>> On Thursday, July 30, 2015, Jakub Hrozek  wrote:
>>>>
>>>>> On Wed, Jul 29, 2015 at 10:03:14PM +0700, Dewangga wrote:
>>>>>> -BEGIN PGP SIGNED MESSAGE-
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> Thanks for the hints both of you, yes the sssd_cache is in play.
>>>>>> I've set the cache to false, is it have any impact to ipa
>>>>>> server/client (performance, security or another issue)?
>>>>>
>>>>> How exactly did you 'disable' the cache? The sssd cache can't be
>>>>> disabled, it can either be removed manually or the cache lifetime can be
>>>>> set short..
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Sent from iDewangga Device

-- 
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] Is there any delay after applied rules to user?

2015-07-30 Thread Dewangga Bachrul Alam
Hello Jakub!

Sorry for delayed email,
My bad, I disabled cache_credentials, not sssd_cache.

I tried modified my user `dewangga` to remove sudo rules, the cache
still active even I restart the sssd service and delete all ccache* files.

There's no information on sssd log folder.

-rw---.  1 root root0 Jul 29 19:26 krb5_child.log
-rw---.  1 root root 105K Jul 30 04:49 ldap_child.log
-rw---.  1 root root0 Jul 29 19:26 sssd.log
-rw---.  1 root root0 Jul 29 19:26 sssd_merahciptamedia.co.id.log
-rw---.  1 root root0 Jul 29 19:26 sssd_nss.log
-rw---.  1 root root0 Jul 29 19:26 sssd_pac.log
-rw---.  1 root root0 Jul 29 19:26 sssd_pam.log
-rw---.  1 root root0 Jul 29 19:26 sssd_ssh.log
-rw---.  1 root root0 Jul 29 19:26 sssd_sudo.log


On 07/30/2015 02:33 PM, Jakub Hrozek wrote:
> On Thu, Jul 30, 2015 at 02:26:03PM +0700, NitrouZ wrote:
>> Hello!
>>
>> I set the cache value to False on sssd.conf. (On IPA server and client).
> 
> Can you show me the exact config directive you used?
> 
>>
>> On Thursday, July 30, 2015, Jakub Hrozek  wrote:
>>
>>> On Wed, Jul 29, 2015 at 10:03:14PM +0700, Dewangga wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello!

 Thanks for the hints both of you, yes the sssd_cache is in play.
 I've set the cache to false, is it have any impact to ipa
 server/client (performance, security or another issue)?
>>>
>>> How exactly did you 'disable' the cache? The sssd cache can't be
>>> disabled, it can either be removed manually or the cache lifetime can be
>>> set short..
>>>
>>> --
>>> 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
>>>
>>
>>
>> -- 
>> Sent from iDewangga Device

-- 
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] Is there any delay after applied rules to user?

2015-07-29 Thread Dewangga Bachrul Alam
Hello!

I'm using FreeIPA 4.1.x on CentOS 7, Is there any delay after applied
some rules to specified user?

[root@ipa ~]# ipa sudorule-show
Rule name: wheel
  Rule name: Wheel
  Enabled: TRUE
  Host category: all
  Command category: all
  RunAs User category: all
  RunAs Group category: all
  Sudo order: 1
  Users: dewangga
  User Groups: wheel
  Sudo Option: !authenticate


On ipa-client, user `dewangga` asking for password when execute command
`sudo -l`

[dewangga@sherief-repository ~]$ sudo -l
[sudo] password for dewangga:

Here is `ipa user-show dewangga` result :

$ ipa user-show dewangga
  User login: dewangga
  First name: Dewangga
  Last name: Alam
  Home directory: /home/dewangga
  Login shell: /bin/bash
  Email address: [removed]
  UID: 64201
  GID: 64201
  Account disabled: False
  Password: False
  Member of groups: wheel
  Member of Sudo rule: Wheel
  Kerberos keys available: False
  SSH public key fingerprint: [removed] mahaesa-key (ssh-rsa)

Any helps are appreciated.
Thanks

-- 
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] Configure IPA Server work with Multiple domain Env

2015-05-20 Thread Dewangga Bachrul Alam
Yes, of course.
I will add NS record to parent zone if my IPA server are ready for
production. :D

Thanks for any comments and help.
Cheers! :)

On 05/20/2015 06:02 PM, Petr Spacek wrote:
> On 20.5.2015 12:56, Dewangga Bachrul Alam wrote:
>> Thanks Martin,
>>
>> Better I leave the configuration as is :D
>>
>> So, If I want to add another domain, I just add and point them to master
>> IPA Server, right? And add DNS Zone, A Rec, etc on IPA server by using
>> `ipa dnsrecord-add`.
>>
>> Isn't it?
> 
> Yes, + you have to add NS record *to the parent zone* so all clients know
> which servers are responsible for the new domain.
> 
> Petr^2 Spacek
> 
>>
>> On 05/20/2015 05:42 PM, Martin Kosek wrote:
>>> On 05/20/2015 12:38 PM, Dewangga Bachrul Alam wrote:
>>>> Hello!
>>>>
>>>> On 05/20/2015 05:30 PM, Martin Kosek wrote:
>>>>> On 05/20/2015 11:54 AM, Dewangga Bachrul Alam wrote:
>>>>>> Hello!
>>>>>>
>>>>>> I've tried to setup my IPA server to work on multiple domain env, for
>>>>>> the example, I have 20 instance/servers using mydomain.co.id then I have
>>>>>> another 10 instance/servers using mydomain.com, I want to manage both of
>>>>>> them on same IPA server.
>>>>>
>>>>> This is fine. If the alternate domain contain the "_kerberos.domain.com" 
>>>>> DNS
>>>>> TXT record with the ream, Kerberos client should be able to find the 
>>>>> right IPA
>>>>> server/KDC to talk to (if they have DNS discovery enabled). Recent FreeIPA
>>>>> versions add this record to owned DNS zones automatically.
>>>>
>>>> TXT record said like this :
>>>>
>>>> $ cat /var/named/dyndb-ldap/ipa/master/kincir.com/raw
>>>>
>>>> .. some content skipped ..
>>>>
>>>> $ORIGIN mydomain.com.
>>>> _kerberos  TXT "MYDOMAIN.CO.ID"
>>>> joyoboyo   A   103.xx.yy.98
>>>> liquid A   103.xx.yy.100
>>>>
>>>> Should I changes it? Or leave it as is?
>>>
>>> If this is the alternate DNS domain (REALM != DNS domain name), this should 
>>> be
>>> fine and Kerberos client should be able to tell which KDC/realm is 
>>> responsible
>>> for this domain.
>>>
>>>>>> On instance with mydomain.com, I've setup and point my DNS to the IPA
>>>>>> Server, the DNS Discovery was failed, but if I entered IPA server
>>>>>> address manually, the setup was success.
>>>>>
>>>>> If autodiscovery with hosts in your alternate domain does not work, you 
>>>>> can
>>>>> also use just
>>>>>
>>>>> # ipa-client-install --domain main.ipa.domain.com
>>>>>
>>>>> and it should find the IPA server.
>>>>>
>>>>>>
>>>>>> ---
>>>>>> [root@joyoboyo ~]# getent passwd dewangga
>>>>>> dewangga:*:94001:94001:Dewangga Alam:/home/dewangga:/bin/bash
>>>>>> [root@joyoboyo ~]# uname -a
>>>>>> Linux joyoboyo.mydomain.com 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15
>>>>>> 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>>>>> ---
>>>>>>
>>>>>> Is it normal? Or is there another configuration on krb5.conf? I found
>>>>>> something interesting on [domain_realm] section, but before I changes
>>>>>> them, better I ask to the mailing list.
>>>>>
>>>>> What I see above looks normal to me. [domain_realm] manual mapping can be 
>>>>> used
>>>>> if you have DNS autodiscovery disabled or you miss the DNS TXT record for
>>>>> Kerberos, IIRC.
>>>>>
>>>>>>
>>>>>> Thanks for any help and comments, this is my first time to configure IPA
>>>>>> Server :D
>>>>>
>>>>> Good, I hope you like it :-)
>>>>>
>>>>
>>>> And what if I setup replica IPA server, did mydomain.com will be
>>>> distributed to another replicated IPA server?
>>>
>>> Yup, all IPA data are replicated between masters.
>>>
>>
> 
> 

-- 
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] Configure IPA Server work with Multiple domain Env

2015-05-20 Thread Dewangga Bachrul Alam
Thanks Martin,

Better I leave the configuration as is :D

So, If I want to add another domain, I just add and point them to master
IPA Server, right? And add DNS Zone, A Rec, etc on IPA server by using
`ipa dnsrecord-add`.

Isn't it?

On 05/20/2015 05:42 PM, Martin Kosek wrote:
> On 05/20/2015 12:38 PM, Dewangga Bachrul Alam wrote:
>> Hello!
>>
>> On 05/20/2015 05:30 PM, Martin Kosek wrote:
>>> On 05/20/2015 11:54 AM, Dewangga Bachrul Alam wrote:
>>>> Hello!
>>>>
>>>> I've tried to setup my IPA server to work on multiple domain env, for
>>>> the example, I have 20 instance/servers using mydomain.co.id then I have
>>>> another 10 instance/servers using mydomain.com, I want to manage both of
>>>> them on same IPA server.
>>>
>>> This is fine. If the alternate domain contain the "_kerberos.domain.com" DNS
>>> TXT record with the ream, Kerberos client should be able to find the right 
>>> IPA
>>> server/KDC to talk to (if they have DNS discovery enabled). Recent FreeIPA
>>> versions add this record to owned DNS zones automatically.
>>
>> TXT record said like this :
>>
>> $ cat /var/named/dyndb-ldap/ipa/master/kincir.com/raw
>>
>> .. some content skipped ..
>>
>> $ORIGIN mydomain.com.
>> _kerberosTXT "MYDOMAIN.CO.ID"
>> joyoboyo A   103.xx.yy.98
>> liquid   A   103.xx.yy.100
>>
>> Should I changes it? Or leave it as is?
> 
> If this is the alternate DNS domain (REALM != DNS domain name), this should be
> fine and Kerberos client should be able to tell which KDC/realm is responsible
> for this domain.
> 
>>>> On instance with mydomain.com, I've setup and point my DNS to the IPA
>>>> Server, the DNS Discovery was failed, but if I entered IPA server
>>>> address manually, the setup was success.
>>>
>>> If autodiscovery with hosts in your alternate domain does not work, you can
>>> also use just
>>>
>>> # ipa-client-install --domain main.ipa.domain.com
>>>
>>> and it should find the IPA server.
>>>
>>>>
>>>> ---
>>>> [root@joyoboyo ~]# getent passwd dewangga
>>>> dewangga:*:94001:94001:Dewangga Alam:/home/dewangga:/bin/bash
>>>> [root@joyoboyo ~]# uname -a
>>>> Linux joyoboyo.mydomain.com 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15
>>>> 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>>> ---
>>>>
>>>> Is it normal? Or is there another configuration on krb5.conf? I found
>>>> something interesting on [domain_realm] section, but before I changes
>>>> them, better I ask to the mailing list.
>>>
>>> What I see above looks normal to me. [domain_realm] manual mapping can be 
>>> used
>>> if you have DNS autodiscovery disabled or you miss the DNS TXT record for
>>> Kerberos, IIRC.
>>>
>>>>
>>>> Thanks for any help and comments, this is my first time to configure IPA
>>>> Server :D
>>>
>>> Good, I hope you like it :-)
>>>
>>
>> And what if I setup replica IPA server, did mydomain.com will be
>> distributed to another replicated IPA server?
> 
> Yup, all IPA data are replicated between masters.
> 

-- 
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] Configure IPA Server work with Multiple domain Env

2015-05-20 Thread Dewangga Bachrul Alam
Hello!

On 05/20/2015 05:30 PM, Martin Kosek wrote:
> On 05/20/2015 11:54 AM, Dewangga Bachrul Alam wrote:
>> Hello!
>>
>> I've tried to setup my IPA server to work on multiple domain env, for
>> the example, I have 20 instance/servers using mydomain.co.id then I have
>> another 10 instance/servers using mydomain.com, I want to manage both of
>> them on same IPA server.
> 
> This is fine. If the alternate domain contain the "_kerberos.domain.com" DNS
> TXT record with the ream, Kerberos client should be able to find the right IPA
> server/KDC to talk to (if they have DNS discovery enabled). Recent FreeIPA
> versions add this record to owned DNS zones automatically.

TXT record said like this :

$ cat /var/named/dyndb-ldap/ipa/master/kincir.com/raw

.. some content skipped ..

$ORIGIN mydomain.com.
_kerberos   TXT "MYDOMAIN.CO.ID"
joyoboyoA   103.xx.yy.98
liquid  A   103.xx.yy.100

Should I changes it? Or leave it as is?

>> On instance with mydomain.com, I've setup and point my DNS to the IPA
>> Server, the DNS Discovery was failed, but if I entered IPA server
>> address manually, the setup was success.
> 
> If autodiscovery with hosts in your alternate domain does not work, you can
> also use just
> 
> # ipa-client-install --domain main.ipa.domain.com
> 
> and it should find the IPA server.
> 
>>
>> ---
>> [root@joyoboyo ~]# getent passwd dewangga
>> dewangga:*:94001:94001:Dewangga Alam:/home/dewangga:/bin/bash
>> [root@joyoboyo ~]# uname -a
>> Linux joyoboyo.mydomain.com 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15
>> 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>> ---
>>
>> Is it normal? Or is there another configuration on krb5.conf? I found
>> something interesting on [domain_realm] section, but before I changes
>> them, better I ask to the mailing list.
> 
> What I see above looks normal to me. [domain_realm] manual mapping can be used
> if you have DNS autodiscovery disabled or you miss the DNS TXT record for
> Kerberos, IIRC.
> 
>>
>> Thanks for any help and comments, this is my first time to configure IPA
>> Server :D
> 
> Good, I hope you like it :-)
> 

And what if I setup replica IPA server, did mydomain.com will be
distributed to another replicated IPA server?

Thanks

-- 
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] Configure IPA Server work with Multiple domain Env

2015-05-20 Thread Dewangga Bachrul Alam
Hello!

I've tried to setup my IPA server to work on multiple domain env, for
the example, I have 20 instance/servers using mydomain.co.id then I have
another 10 instance/servers using mydomain.com, I want to manage both of
them on same IPA server.

On instance with mydomain.com, I've setup and point my DNS to the IPA
Server, the DNS Discovery was failed, but if I entered IPA server
address manually, the setup was success.

---
[root@joyoboyo ~]# getent passwd dewangga
dewangga:*:94001:94001:Dewangga Alam:/home/dewangga:/bin/bash
[root@joyoboyo ~]# uname -a
Linux joyoboyo.mydomain.com 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15
04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
---

Is it normal? Or is there another configuration on krb5.conf? I found
something interesting on [domain_realm] section, but before I changes
them, better I ask to the mailing list.

Thanks for any help and comments, this is my first time to configure IPA
Server :D

-- 
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] Problem installing external SSL Certificate

2015-05-19 Thread Dewangga Bachrul Alam
This is the verbose log, tried to convert them to p12 format (dont know
it's right or not), still no luck.

http://fpaste.org/223608/88775143/raw/

Ref: http://www.redhat.com/archives/freeipa-users/2014-August/msg00338.html

Any additional hints?


On 05/19/2015 08:30 PM, Dewangga Bachrul Alam wrote:
> Hello!
> 
> I was build FreeIPA 4.1.4 on CentOS 7.1, the deployment was done, but
> could I changes the HTTP and dirsv certificate? I have wildcard
> certificate (thawte SSL CA - G2). It is compatible for FreeIPA (http and
> dirsv)?
> 
> I've tried to follow the instruction
> https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
> but no luck.
> 
> $ ipa-server-certinstall -wd mydomain.co.id.key \
> mydomain.co.id-bundled.crt
> 
> Directory Manager password:
> 
> Enter private key unlock password:
> 
> The full certificate chain is not present in mydomain.co.id.key,
> mydomain.co.id-bundled.crt
> 
> FYI, mydomain.co.id-bundled.crt chain have SIGNED then INTERMEDIATE
> certificate order. (2 chain)
> 
> I've tried to bundling them using root certificate, still have no luck.
> (3 chain, SIGNEDCERT, INTERMEDIATE, ROOTCERT).
> 
> Any comments will be appreciated :)
> Thanks
> 

-- 
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] Reinstall ipa client, problem with old CA

2015-05-19 Thread Dewangga Bachrul Alam
Well, thanks Martin for the info :)

On 05/19/2015 08:23 PM, Martin Kosek wrote:
> On 05/19/2015 03:21 PM, Dewangga Bachrul Alam wrote:
>> Thank you Martin,
>>
>> Yes, the IPA Server was built on CentOS 7.1. But, some client still
>> using CentOS 6.x, but I have plan upgrade them to 7.x.
>>
>> Is it gave a problem if some client still on CentOS 6.x and the IPA
>> Server built on CentOS 7.x ?
> 
> No, I do not see a problem with this setup. Clients will just simply use the
> capabilities they can do. We still tend to backport client features to
> RHEL-6.x, so it keeps getting the selected functionality (server does not).
> 
>>
>> On 05/19/2015 08:14 PM, Martin Kosek wrote:
>>> On 05/19/2015 10:53 AM, Dewangga Bachrul Alam wrote:
>>>> Hello!
>>>>
>>>> On 05/19/2015 12:53 PM, Martin Kosek wrote:
>>>>> On 05/19/2015 04:04 AM, Dewangga Bachrul Alam wrote:
>>>>>> Hello!
>>>>>>
>>>>>> I'm trying to reinstall ipa client, but have a problem with old/existing
>>>>>> ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA
>>>>>> server still on development and always reinstalled, I need to reproduce
>>>>>> any possible problem/error on FreeIPA 4.x on CentOS 7.
>>>>>>
>>>>>> The error was :
>>>>>> LDAP Error: Connect error: TLS error -8054:You are attempting to import
>>>>>> a cert with the same issuer/serial as an existing cert, but that is not
>>>>>> the same cert.
>>>>>>
>>>>>> Currently, I was renamed ca.crt to ca.crt.old and the ipa client
>>>>>> successfully reconnected to new FreeIPA Server using dns discovery.
>>>>>>
>>>>>> Is it normal? And why the ipa-client-install --uninstall didn't
>>>>>> completely remove the old ca.crt?
>>>>>
>>>>> Hello,
>>>>>
>>>>> ipa-client-install uninstall the CA certificate properly since FreeIPA
>>>>> 3.2. This is the upstream ticket:
>>>>> https://fedorahosted.org/freeipa/ticket/3537
>>>>>
>>>>> CentOS/RHEL speaking, this should be thus fixed in 7.0+. In 6.x
>>>>> versions, you need to delete the certificate manually if you reinstalled
>>>>> the IPA server.
>>>>>
>>>>> HTH,
>>>>> Martin
>>>>
>>>> Could you gimme advice, which version is suitable on production? 3.x or
>>>> 4.x ?.Or is there any release timeline for FreeIPA version (like EOL, etc).
>>>
>>> All versions in RHEL should be suitable for production - RHEL is an OS
>>> targeting production/stable environment.
>>>
>>> For FreeIPA, I would recommend using environment built on top of RHEL-7.1
>>> version (FreeIPA 4.1) as it contains the most fixes and most functionality 
>>> to
>>> be offered.
>>>
>>> I would not recommend having mixed RHEL-6.x and RHEL-7.x as you you will 
>>> have
>>> limited capabilities of your infrastructure as most of the new server 
>>> features
>>> are not backported to RHEL-6.x and clients connected to these servers could 
>>> not
>>> use them.
>>>
>>> Martin
>>>
> 

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


[Freeipa-users] Problem installing external SSL Certificate

2015-05-19 Thread Dewangga Bachrul Alam
Hello!

I was build FreeIPA 4.1.4 on CentOS 7.1, the deployment was done, but
could I changes the HTTP and dirsv certificate? I have wildcard
certificate (thawte SSL CA - G2). It is compatible for FreeIPA (http and
dirsv)?

I've tried to follow the instruction
https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
but no luck.

$ ipa-server-certinstall -wd mydomain.co.id.key \
mydomain.co.id-bundled.crt

Directory Manager password:

Enter private key unlock password:

The full certificate chain is not present in mydomain.co.id.key,
mydomain.co.id-bundled.crt

FYI, mydomain.co.id-bundled.crt chain have SIGNED then INTERMEDIATE
certificate order. (2 chain)

I've tried to bundling them using root certificate, still have no luck.
(3 chain, SIGNEDCERT, INTERMEDIATE, ROOTCERT).

Any comments will be appreciated :)
Thanks

-- 
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] Reinstall ipa client, problem with old CA

2015-05-19 Thread Dewangga Bachrul Alam
Thank you Martin,

Yes, the IPA Server was built on CentOS 7.1. But, some client still
using CentOS 6.x, but I have plan upgrade them to 7.x.

Is it gave a problem if some client still on CentOS 6.x and the IPA
Server built on CentOS 7.x ?

On 05/19/2015 08:14 PM, Martin Kosek wrote:
> On 05/19/2015 10:53 AM, Dewangga Bachrul Alam wrote:
>> Hello!
>>
>> On 05/19/2015 12:53 PM, Martin Kosek wrote:
>>> On 05/19/2015 04:04 AM, Dewangga Bachrul Alam wrote:
>>>> Hello!
>>>>
>>>> I'm trying to reinstall ipa client, but have a problem with old/existing
>>>> ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA
>>>> server still on development and always reinstalled, I need to reproduce
>>>> any possible problem/error on FreeIPA 4.x on CentOS 7.
>>>>
>>>> The error was :
>>>> LDAP Error: Connect error: TLS error -8054:You are attempting to import
>>>> a cert with the same issuer/serial as an existing cert, but that is not
>>>> the same cert.
>>>>
>>>> Currently, I was renamed ca.crt to ca.crt.old and the ipa client
>>>> successfully reconnected to new FreeIPA Server using dns discovery.
>>>>
>>>> Is it normal? And why the ipa-client-install --uninstall didn't
>>>> completely remove the old ca.crt?
>>>
>>> Hello,
>>>
>>> ipa-client-install uninstall the CA certificate properly since FreeIPA
>>> 3.2. This is the upstream ticket:
>>> https://fedorahosted.org/freeipa/ticket/3537
>>>
>>> CentOS/RHEL speaking, this should be thus fixed in 7.0+. In 6.x
>>> versions, you need to delete the certificate manually if you reinstalled
>>> the IPA server.
>>>
>>> HTH,
>>> Martin
>>
>> Could you gimme advice, which version is suitable on production? 3.x or
>> 4.x ?.Or is there any release timeline for FreeIPA version (like EOL, etc).
> 
> All versions in RHEL should be suitable for production - RHEL is an OS
> targeting production/stable environment.
> 
> For FreeIPA, I would recommend using environment built on top of RHEL-7.1
> version (FreeIPA 4.1) as it contains the most fixes and most functionality to
> be offered.
> 
> I would not recommend having mixed RHEL-6.x and RHEL-7.x as you you will have
> limited capabilities of your infrastructure as most of the new server features
> are not backported to RHEL-6.x and clients connected to these servers could 
> not
> use them.
> 
> 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] Reinstall ipa client, problem with old CA

2015-05-19 Thread Dewangga Bachrul Alam
Hello!

On 05/19/2015 12:53 PM, Martin Kosek wrote:
> On 05/19/2015 04:04 AM, Dewangga Bachrul Alam wrote:
>> Hello!
>>
>> I'm trying to reinstall ipa client, but have a problem with old/existing
>> ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA
>> server still on development and always reinstalled, I need to reproduce
>> any possible problem/error on FreeIPA 4.x on CentOS 7.
>>
>> The error was :
>> LDAP Error: Connect error: TLS error -8054:You are attempting to import
>> a cert with the same issuer/serial as an existing cert, but that is not
>> the same cert.
>>
>> Currently, I was renamed ca.crt to ca.crt.old and the ipa client
>> successfully reconnected to new FreeIPA Server using dns discovery.
>>
>> Is it normal? And why the ipa-client-install --uninstall didn't
>> completely remove the old ca.crt?
> 
> Hello,
> 
> ipa-client-install uninstall the CA certificate properly since FreeIPA
> 3.2. This is the upstream ticket:
> https://fedorahosted.org/freeipa/ticket/3537
> 
> CentOS/RHEL speaking, this should be thus fixed in 7.0+. In 6.x
> versions, you need to delete the certificate manually if you reinstalled
> the IPA server.
> 
> HTH,
> Martin

Could you gimme advice, which version is suitable on production? 3.x or
4.x ?.Or is there any release timeline for FreeIPA version (like EOL, etc).

-- 
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] Reinstall ipa client, problem with old CA

2015-05-18 Thread Dewangga Bachrul Alam
Hello!

I'm trying to reinstall ipa client, but have a problem with old/existing
ca.crt in `/etc/ipa/ca.crt`. Should I remove it manually? Since the IPA
server still on development and always reinstalled, I need to reproduce
any possible problem/error on FreeIPA 4.x on CentOS 7.

The error was :
LDAP Error: Connect error: TLS error -8054:You are attempting to import
a cert with the same issuer/serial as an existing cert, but that is not
the same cert.

Currently, I was renamed ca.crt to ca.crt.old and the ipa client
successfully reconnected to new FreeIPA Server using dns discovery.

Is it normal? And why the ipa-client-install --uninstall didn't
completely remove the old ca.crt?

Thank you.

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