[Freeipa-users] bind-dyndb-ldap replication errors
list members, i am using bind-dyndb-ldap without freeipa, and i consistently get the below errors in my logs: update_zone (syncrepl) failed for master zone DN 'idnsName=24.168.192.in-addr.arpa.,cn=dns,ou=Daemons,dc=bpk2,dc=com'. Zones can be outdated, run `rndc reload`: unexpected error the zone that has issue varies, but it is always a zone that allows dynamic updates. it seems that some replication event fails and a manual resync of things has to be performed. any ideas what might be going on? fedora 24, with nearly all recent updates bind-9.10.4-3.P6.fc24.x86_64 bind-dyndb-ldap-10.1-1.fc24.x86_64 openldap-2.4.44-1.fc24.x86_64 i have multi master replication configured between 2 masters, and no other replication events seem to fail. i am not sure where to look for issues. named.conf: dynamic-db "bpk2.com" { library "ldap.so"; arg "uri ldap://192.168.88.1";; arg "base cn=dns,ou=Daemons,dc=bpk2,dc=com"; arg "auth_method sasl"; arg "sasl_mech GSSAPI"; arg "sasl_realm BPK2.COM"; arg "krb5_keytab FILE:/etc/named.keytab"; arg "krb5_principal DNS/server1.bpk2.com"; arg "ldap_hostname server1.bpk2.com"; arg "fake_mname dns.bpk2.com."; arg "dyn_update yes"; arg "connections 2"; }; zone config: dn: idnsName=24.168.192.in-addr.arpa.,cn=dns,ou=Daemons,dc=bpk2,dc=com dnsttl: 3600 idnsallowdynupdate: TRUE idnsallowquery: any; idnsallowsyncptr: TRUE idnsname: 24.168.192.in-addr.arpa. idnssoaexpire: 604800 idnssoaminimum: 86400 idnssoamname: dns.bpk2.com. idnssoarefresh: 10800 idnssoaretry: 900 idnssoarname: root.bpk2.com. idnssoaserial: 1491999811 idnsupdatepolicy: grant dhcp wildcard * any; idnszoneactive: TRUE nsrecord: dns.bpk2.com. objectclass: top objectclass: idnsZone objectclass: idnsRecord any help would be appreciated. thanks, brendan -- 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 mount NFS, but user only gets the permission question marks
On 03/02/2017 08:43 AM, Kees Bakker wrote: On 02-03-17 13:34, Brendan Kearney wrote: On 03/02/2017 05:40 AM, Kees Bakker wrote: On 24-02-17 14:38, Brendan Kearney wrote: On 02/24/2017 03:33 AM, Kees Bakker wrote: On 23-02-17 15:39, Brendan Kearney wrote: On 02/23/2017 09:11 AM, Kees Bakker wrote: On 23-02-17 13:51, Brendan Kearney wrote: On 02/23/2017 07:32 AM, Kees Bakker wrote: On 22-02-17 17:33, Brendan Kearney wrote: On 02/22/2017 10:26 AM, Kees Bakker wrote: On 22-02-17 14:05, Brendan Kearney wrote: On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome [...] Continuing story... I've tried various things in the meantime. I've set up two test environments with virtual machines (virtualbox). * with Fedora 25; this works. * with Ubuntu 16.04; I'm getting the same problem (permission denied and question marks). I also looked at the verbose output of rpc.gssd, it gives ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb@REALM in cache collection does the actual error message say @REALM, or did you substitute that to obscure sensitive info? if it does actually say @REALM, then you are missing a config directive somewhere, that specifies the kerberos realm. Be assured that I'm using the real thing. getting credentials for client with uid 60001 for server srv1.example.com getting credentials for client with uid 60001 for server srv1.example.com WARNING: Failed to create krb5 context for user with uid 60001 for server srv1.example.com So rpc.gssd is trying to create a krb5 context. It succeeds for uid=0 but not for another user. Log when root is listing the NFS directory Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handling gssd upcall (/run/rpc_pipefs/nfs/clnt14) Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,23,3,1,2 ' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handling krb5 upcall (/run/rpc_pipefs/nfs/clnt14) Mar 2 14:23:52 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is '*' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'srv1.example.com' is 'srv1.example.com' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'clnt1.example.com' is 'clnt1.example.com' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for CLNT1.REALM$@REALM while getting keytab entry for 'CLNT1.REALM$@REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for root/clnt1.example.com@REALM while getting keytab entry for 'root/clnt1.example.com@REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for nfs/clnt1.example.com@REALM while getting keytab entry for 'nfs/clnt1.example.com@REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Success getting keytab entry for 'host/clnt1.example.com@REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153 Mar 2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153 Mar 2 14:23:52 clnt1 rpc.gssd[3612]: using FILE:/tmp/krb5ccmachine_REALM as credentials cache for machine creds Mar 2 14:23:52 clnt1 rpc.gssd[3612]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_REALM Mar 2 14:23:52 clnt1 rpc.gssd[3612]: creating context using fsui
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 03/02/2017 05:40 AM, Kees Bakker wrote: On 24-02-17 14:38, Brendan Kearney wrote: On 02/24/2017 03:33 AM, Kees Bakker wrote: On 23-02-17 15:39, Brendan Kearney wrote: On 02/23/2017 09:11 AM, Kees Bakker wrote: On 23-02-17 13:51, Brendan Kearney wrote: On 02/23/2017 07:32 AM, Kees Bakker wrote: On 22-02-17 17:33, Brendan Kearney wrote: On 02/22/2017 10:26 AM, Kees Bakker wrote: On 22-02-17 14:05, Brendan Kearney wrote: On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome [...] Continuing story... I've tried various things in the meantime. I've set up two test environments with virtual machines (virtualbox). * with Fedora 25; this works. * with Ubuntu 16.04; I'm getting the same problem (permission denied and question marks). I also looked at the verbose output of rpc.gssd, it gives ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb@REALM in cache collection does the actual error message say @REALM, or did you substitute that to obscure sensitive info? if it does actually say @REALM, then you are missing a config directive somewhere, that specifies the kerberos realm. getting credentials for client with uid 60001 for server srv1.example.com getting credentials for client with uid 60001 for server srv1.example.com WARNING: Failed to create krb5 context for user with uid 60001 for server srv1.example.com But the user really did get a TGT. $ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: ke...@example.com Valid starting ExpiresService principal 02-03-17 10:25:25 03-03-17 10:25:22 krbtgt/example@example.com So, still no solution for Ubuntu + freeipa + nfs. BTW. I've enabled verbosity in /etc/idmapd.conf. The logging tells me it is OK. However, there is only any output when root (uid 0) does a NFS directory lookup. When a regular user tries to stat the NFS directory it does not even get to the point where id mapping is done. -- 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 mount NFS, but user only gets the permission question marks
On 02/24/2017 03:33 AM, Kees Bakker wrote: On 23-02-17 15:39, Brendan Kearney wrote: On 02/23/2017 09:11 AM, Kees Bakker wrote: On 23-02-17 13:51, Brendan Kearney wrote: On 02/23/2017 07:32 AM, Kees Bakker wrote: On 22-02-17 17:33, Brendan Kearney wrote: On 02/22/2017 10:26 AM, Kees Bakker wrote: On 22-02-17 14:05, Brendan Kearney wrote: On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) Thanks for the reply. In this case the user _is_ authenticated. keesb@client1:~$ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: ke...@example.com Valid starting ExpiresService principal 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to authenticate. (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) What other grants could be needed? HBAC Rules? Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it doesn't help to get access for the user.) there are principals to create and keytabs to be updated on hte NFS sever, if not done already. I did create a principal for the NFS server (using ipa service-add) and add to the keytab on the NFS server (using ipa-getkeytab) ... root@srv1# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 1 host/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 host/srv1.example@example.com (aes128-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes128-cts-hmac-sha1-96) Is this what you mean? yes, if that is done, the server side components should be done for kerberos. have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup? I don't think that a change of idmapd.conf (on the NFS server) is needed because all host names are FQDN and everything is in one and the same REALM. NFS needs to know how to map a user object to an ID and groups. identities established by kerberos do not directly translate to users. usually some sort of directory services are leveraged in order to accomplish this, though PAM and things like that can be used to. by setting things in idmapd.conf, you are telling NFS who to translate kerberos identities into usernames, so ownership and permissions can be sync'd. Both the NFS server and the client are configured as FreeIPA client. On the server the users are known (through PAM, SSSD). Only user "ubuntu" is a local (/etc/passwd) user. All other users are defined on the IPA server. root@srv1:~# ls -l /home total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb drwxr-xr-x 1 ubuntu ubuntu 142 aug 17 2016 ubuntu root@srv1:~# ls -ln /home total 0 drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb drwxr-xr-x 1 1000 1000 142 aug 17 2016 ubuntu On the client, same stor
Re: [Freeipa-users] sudo NOPASSWD for a single command
On 02/23/2017 09:43 AM, Auerbach, Steven wrote: sudo vgs >> statresults.txt should be sudo /sbin/vgs >> statresults.txt since that is what sudo allows. its almost like exact match for strings. -- 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 mount NFS, but user only gets the permission question marks
On 02/23/2017 09:11 AM, Kees Bakker wrote: On 23-02-17 13:51, Brendan Kearney wrote: On 02/23/2017 07:32 AM, Kees Bakker wrote: On 22-02-17 17:33, Brendan Kearney wrote: On 02/22/2017 10:26 AM, Kees Bakker wrote: On 22-02-17 14:05, Brendan Kearney wrote: On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) Thanks for the reply. In this case the user _is_ authenticated. keesb@client1:~$ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: ke...@example.com Valid starting ExpiresService principal 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to authenticate. (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) What other grants could be needed? HBAC Rules? Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it doesn't help to get access for the user.) there are principals to create and keytabs to be updated on hte NFS sever, if not done already. I did create a principal for the NFS server (using ipa service-add) and add to the keytab on the NFS server (using ipa-getkeytab) ... root@srv1# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 1 host/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 host/srv1.example@example.com (aes128-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes128-cts-hmac-sha1-96) Is this what you mean? yes, if that is done, the server side components should be done for kerberos. have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup? I don't think that a change of idmapd.conf (on the NFS server) is needed because all host names are FQDN and everything is in one and the same REALM. NFS needs to know how to map a user object to an ID and groups. identities established by kerberos do not directly translate to users. usually some sort of directory services are leveraged in order to accomplish this, though PAM and things like that can be used to. by setting things in idmapd.conf, you are telling NFS who to translate kerberos identities into usernames, so ownership and permissions can be sync'd. Both the NFS server and the client are configured as FreeIPA client. On the server the users are known (through PAM, SSSD). Only user "ubuntu" is a local (/etc/passwd) user. All other users are defined on the IPA server. root@srv1:~# ls -l /home total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb drwxr-xr-x 1 ubuntu ubuntu 142 aug 17 2016 ubuntu root@srv1:~# ls -ln /home total 0 drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb drwxr-xr-x 1 1000 1000 142 aug 17 2016 ubuntu On the client, same story root@client1:~# ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 02/23/2017 07:32 AM, Kees Bakker wrote: On 22-02-17 17:33, Brendan Kearney wrote: On 02/22/2017 10:26 AM, Kees Bakker wrote: On 22-02-17 14:05, Brendan Kearney wrote: On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) Thanks for the reply. In this case the user _is_ authenticated. keesb@client1:~$ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: ke...@example.com Valid starting ExpiresService principal 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to authenticate. (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) What other grants could be needed? HBAC Rules? Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it doesn't help to get access for the user.) there are principals to create and keytabs to be updated on hte NFS sever, if not done already. I did create a principal for the NFS server (using ipa service-add) and add to the keytab on the NFS server (using ipa-getkeytab) ... root@srv1# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 1 host/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 host/srv1.example@example.com (aes128-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes128-cts-hmac-sha1-96) Is this what you mean? yes, if that is done, the server side components should be done for kerberos. have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup? I don't think that a change of idmapd.conf (on the NFS server) is needed because all host names are FQDN and everything is in one and the same REALM. NFS needs to know how to map a user object to an ID and groups. identities established by kerberos do not directly translate to users. usually some sort of directory services are leveraged in order to accomplish this, though PAM and things like that can be used to. by setting things in idmapd.conf, you are telling NFS who to translate kerberos identities into usernames, so ownership and permissions can be sync'd. then the user should be able to pull the ticket for auth. Sorry to ask, but how do I do that? On the client, I suppose, and by the user ?? keesb@client1$ kinit nfs/srv1.example@example.com Password for nfs/srv1.example@example.com: But I don't have a password for that. Hmm. there is no need to init on the client side, as long as the TGT is obtained. you should never need to init the nfs/blah.. on the client side. OK So, it seems to me that all the basics are setup correctly. The mount succeeds. The user has a TGT and still the (non-root) user cannot even stat the mount point, nor the directory entry itself. What puzzles me is that root can see everything, also with
Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks
On 02/22/2017 10:26 AM, Kees Bakker wrote: On 22-02-17 14:05, Brendan Kearney wrote: On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) Thanks for the reply. In this case the user _is_ authenticated. keesb@client1:~$ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: ke...@example.com Valid starting ExpiresService principal 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to authenticate. (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. )) What other grants could be needed? HBAC Rules? Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it doesn't help to get access for the user.) there are principals to create and keytabs to be updated on hte NFS sever, if not done already. I did create a principal for the NFS server (using ipa service-add) and add to the keytab on the NFS server (using ipa-getkeytab) ... root@srv1# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 1 host/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 host/srv1.example@example.com (aes128-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes256-cts-hmac-sha1-96) 1 nfs/srv1.example@example.com (aes128-cts-hmac-sha1-96) Is this what you mean? yes, if that is done, the server side components should be done for kerberos. have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup? then the user should be able to pull the ticket for auth. Sorry to ask, but how do I do that? On the client, I suppose, and by the user ?? keesb@client1$ kinit nfs/srv1.example@example.com Password for nfs/srv1.example@example.com: But I don't have a password for that. Hmm. there is no need to init on the client side, as long as the TGT is obtained. you should never need to init the nfs/blah.. on the client side. Furthermore, I'm guessing that the host principle which I got after ipa-client-install is good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for it, which I did not do.) # klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 1 host/client1.example@example.com (aes256-cts-hmac-sha1-96) 1 host/client1.example@example.com (aes128-cts-hmac-sha1-96) [1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA [2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/ http://www.itp.uzh.ch/~dpotter/howto/kerberos -- 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 mount NFS, but user only gets the permission question marks
On 02/22/2017 05:23 AM, Kees Bakker wrote: On 21-02-17 19:49, Brendan Kearney wrote: On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) Thanks for the reply. In this case the user _is_ authenticated. keesb@client1:~$ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: ke...@example.com Valid starting ExpiresService principal 22-02-17 09:20:30 23-02-17 09:20:25 krbtgt/example@example.com no, the user has a TGT. a nfs/host.domain.tld@REALM ticket is needed to authenticate. What other grants could be needed? HBAC Rules? Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's say so [2]. Anyway, it doesn't help to get access for the user.) there are principals to create and keytabs to be updated on hte NFS sever, if not done already. then the user should be able to pull the ticket for auth. Furthermore, I'm guessing that the host principle which I got after ipa-client-install is good enough. (This [1] wiki suggests that I need to do a ipa-getkeytab for it, which I did not do.) # klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal -- 1 host/client1.example@example.com (aes256-cts-hmac-sha1-96) 1 host/client1.example@example.com (aes128-cts-hmac-sha1-96) [1] http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA [2] https://www.lisenet.com/2016/kerberised-nfs-server-on-rhel-7/ http://www.itp.uzh.ch/~dpotter/howto/kerberos -- 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 mount NFS, but user only gets the permission question marks
On 02/21/2017 10:57 AM, Kees Bakker wrote: Hey, Maybe one of the NFS users on this list could give me a hint what could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. I've set up an NFS server and I can mount the NFS directory on my client. So, I'm guessing that setting up Kerberos principal was done correctly. However, only root can actually access the mounted contents. Any other user only sees question marks as shown below. The mount command is simple. $ sudo mount -v -t nfs srv1.example.com:/home /nfshome mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' On the server side /etc/exports looks like this. /home*(rw,sync,sec=krb5i,no_subtree_check) $ sudo mount |grep nfs srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) $ sudo ls -ld /nfshome drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome $ sudo ls -l /nfshome total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb $ ls -l /nfshome ls: cannot access '/nfshome': Permission denied $ ls -l / | grep nfshome ls: cannot access '/nfshome': Permission denied d? ? ?? ?? nfshome sec=krb* means that the user accessing the mount has to authenticate with a kerberos ticket, and has to be the user or in the group granted access to the share. from the looks of things, the user did not authenticate, and that is why the permissions are question marks. check the kerberos tickets that the user has (klist output). Otherwise, the ownership might be user and group that the client machine does not recognize (think posix user/group that is not in sync between the NFS server and the client) brendan -- 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] bind-dyndb-ldap and replication requirements
i am asking this for a friend who is trying to figure out how to get bind-dyndb-ldap working against openldap on ubuntu. she does not have replication between two or more ldap instances, and needs to figure out the minimum requirements for bind-dyndb-ldap. i have been trying to help her, but i am unsure about what is needed, as i have n-way multi master replication working already. can anyone provide what the replication requirements are for bind-dyndb-ldap? currently, the SyncRepl module is loaded and the overlay is created and configured for the mdb. i have tried to help get olcServerID and olcMirrorMode set in cn=config and olcDatabase={2}mdb,cn=config respectively, but some errors were encountered there. is there a best practices doc that we can review? the environment, as best i can tell is ubuntu, openldap 2.4.42 and bind 9. exact os and bind versions are not known right now. thanks, brendan kearney -- 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] bind-dyndb-ldap issues
On 10/12/2016 02:35 AM, Petr Spacek wrote: Hello, these are debug messages and are harmless. Apparently you have verbose/debug messages enabled in named.conf: arg "verbose_checks yes"; If you want to get rid of these messages, just remove the line. What version of bind-dyndb-ldap are you using? Sufficiently new versions should use SyncRepl to pull all data from LDAP to memory (on start) so the read performance should be nearly identical as with plain BIND. Of course, writes/DNS updates will generate load on your LDAP server so the server needs to handle the load. Petr^2 Spacek On 11.10.2016 20:41, Brendan Kearney wrote: i am using bind-dyndb-ldap on fedora 24 without FreeIPA, and continue to have my logs swamped with errors about "check failed" from settings.c and fwd.c. i am completely up to date with every package, so the latest versions of everything are installed. [settings.c : 420: setting_update_from_ldap_entry] check failed: ignore [settings.c : 436: setting_update_from_ldap_entry] check failed: ignore [fwd.c : 378: fwd_setting_isexplicit] check failed: not found i have two boxes running a named instance each, in a "master/master" config. each has the zone data configured per below. the uri refers to the local ip of each server. dynamic-db "bpk2.com" { library "ldap.so"; arg "uri ldap://192.168.88.1/";; arg "base cn=dns,ou=Daemons,dc=bpk2,dc=com"; arg "auth_method simple"; arg "bind_dn cn=dnsUser,dc=bpk2,dc=com"; arg "password dnsPass"; arg "fake_mname server1.bpk2.com."; arg "dyn_update yes"; arg "connections 2"; arg "verbose_checks yes"; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; my dns container is defined in openldap as such: dn: cn=dns,ou=Daemons,dc=bpk2,dc=com cn: dns idnspersistentsearch: FALSE idnszonerefresh: 30 objectclass: top objectclass: nsContainer objectclass: idnsConfigObject where and how can i find the source of my issue? these issues are causing performance issues on the rest of my network. because of these errors, ldap throws errors about deferred operations for binding, too many executing, and pending operations. additionally, recursion also seems to be impacted. this is noticed most when streaming content. buffering, stuttering and pixelation are seen in the video streams. it could be the swamping of logs killing I/O or the actual recurision, but 100% the video issues are related. the log events match up exactly with the buffering. i had this issue with bind-dyndb-ldap and fedora 20 up until i recently upgraded. i went from F20 to F24, and put things on nice new SSDs, instead of spinning disks. the problem followed the upgrade. are there configuration items i am missing? are there tweaks i can do to improve something? how do i get rid of these errors, so dns performance (or the log swamping) is not affecting the rest of my network? thank you, brendan i am running 10.1.1 on F24. why or how would those error logs be related to LDAP seeing an influx of updates, that wind up causing LDAP operations to queue up and require pended transactions, etc?are there tweaks and tuning options i should have in my LDAP to manage this? thanks, brendan -- 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] bind-dyndb-ldap issues
i am using bind-dyndb-ldap on fedora 24 without FreeIPA, and continue to have my logs swamped with errors about "check failed" from settings.c and fwd.c. i am completely up to date with every package, so the latest versions of everything are installed. [settings.c : 420: setting_update_from_ldap_entry] check failed: ignore [settings.c : 436: setting_update_from_ldap_entry] check failed: ignore [fwd.c : 378: fwd_setting_isexplicit] check failed: not found i have two boxes running a named instance each, in a "master/master" config. each has the zone data configured per below. the uri refers to the local ip of each server. dynamic-db "bpk2.com" { library "ldap.so"; arg "uri ldap://192.168.88.1/";; arg "base cn=dns,ou=Daemons,dc=bpk2,dc=com"; arg "auth_method simple"; arg "bind_dn cn=dnsUser,dc=bpk2,dc=com"; arg "password dnsPass"; arg "fake_mname server1.bpk2.com."; arg "dyn_update yes"; arg "connections 2"; arg "verbose_checks yes"; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; my dns container is defined in openldap as such: dn: cn=dns,ou=Daemons,dc=bpk2,dc=com cn: dns idnspersistentsearch: FALSE idnszonerefresh: 30 objectclass: top objectclass: nsContainer objectclass: idnsConfigObject where and how can i find the source of my issue? these issues are causing performance issues on the rest of my network. because of these errors, ldap throws errors about deferred operations for binding, too many executing, and pending operations. additionally, recursion also seems to be impacted. this is noticed most when streaming content. buffering, stuttering and pixelation are seen in the video streams. it could be the swamping of logs killing I/O or the actual recurision, but 100% the video issues are related. the log events match up exactly with the buffering. i had this issue with bind-dyndb-ldap and fedora 20 up until i recently upgraded. i went from F20 to F24, and put things on nice new SSDs, instead of spinning disks. the problem followed the upgrade. are there configuration items i am missing? are there tweaks i can do to improve something? how do i get rid of these errors, so dns performance (or the log swamping) is not affecting the rest of my network? thank you, brendan -- 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] non-authoritative tricks for DNS resolution
On 07/18/2016 06:12 AM, Petr Spacek wrote: On 18.7.2016 03:25, Sullivan, Daniel [AAA] wrote: Would a DNS view (bind) work? http://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_06.htm Also, depending on what you are using for NAT, some devices will mangle the reply payload of A record lookups as they traverse NAT to avoid haripinning (a packet going out and then back in the same interface as it traverses NAT). This is known as DNS doctoring, at least in the world of Cisco. http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/72273-dns-doctoring-3zones.html Let me know if either of those will solve your problem. If not, I might have a misunderstanding of what you are asking. Dan On Jul 17, 2016, at 3:36 PM, Brendan Kearney wrote: i am looking to setup a VPN in order to access some resources, and want to point my clients at this resource via DNS. the resource i am accessing is internet resolvable, but i am accessing it via the VPN, and using a NAT for the VPN (full 1-to-1 or static NAT). i want to have a record in my DNS for this resource, using its proper name (which i am not authoritative for), but assign it the IP of my NAT. say for example, host.domain-ext.tld is the resource i want to access, and it resolves externally to 1.2.3.4. my VPN NAT would be 192.168.99.137. i want internal resolution of DNS to point to 192.168.99.137 so the network routing takes my internal clients to the VPN and not out to the internet. i am using isc bind, bind-dyndb-ldap, and fedora, but not freeipa, for dns. how do i setup the zone and record to accomplish this DNS trick? i have talked with some DNS gurus and they indicate that i can do something with the "@" record. it seems that the record i want, would be its own zone, and the @ record would point to the name, and the SOA would be the NAT IP. i could be wrong about the details, but something like this is how to setup resolution the way i want. any pointers would be greatly appreciated. Background note: All these DNS tricks are hacks to work around IP routing problem in configuration you described. If you really want to use DNS tricks, you can create a DNS zone with name equal to the you want to override and will this zone with A/ record at zone apex (@). The DNS approach has some inherent advantages: 1. All DNS names below the name you want to 'hijack' will not be resolvable in your network. E.g. if the name is hijacked.example.com. then sub-domains like anything.hijacked.example.com. will not be resolvable. 2. Your clients will go securely over VPN if and only if they use your local DNS servers. Any client configured (even accidentally) to use some other DNS server (e.g. public 8.8.8.8) will get the 'public' address and do not tunnel the traffic over VPN. Secure and reliable solution is not to use DNS but solve things on IP layer: On the network gateway, configure IPSec tunnel (or any other VPN) in a way that *the original IP address* is routed over VPN. This does not require any DNS tricks and thus will work regardless of client configuration. I hope it helps. our posture states that we do not route network space that is not ours, unless exigent circumstances dictate otherwise. we have dedicated address space to NAT pools, in order to facilitate this. we also forbid external dns resolution from endpoints, by limiting what can go out to the roots for recursion. misconfigured clients are not able to perform DNS resolution. we work with our counterparts on the other side of the VPN to ensure we are only adding a host record, and that sub-domains are not a point of failure for our access. in terms of setting up this zone, how would one construct the ldif to create it? because i am not using FreeIPA, i do not have the seemingly built-in tools to perform this function. any reading material on the subject is welcomed. thanks, brendan -- 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] non-authoritative tricks for DNS resolution
i am looking to setup a VPN in order to access some resources, and want to point my clients at this resource via DNS. the resource i am accessing is internet resolvable, but i am accessing it via the VPN, and using a NAT for the VPN (full 1-to-1 or static NAT). i want to have a record in my DNS for this resource, using its proper name (which i am not authoritative for), but assign it the IP of my NAT. say for example, host.domain-ext.tld is the resource i want to access, and it resolves externally to 1.2.3.4. my VPN NAT would be 192.168.99.137. i want internal resolution of DNS to point to 192.168.99.137 so the network routing takes my internal clients to the VPN and not out to the internet. i am using isc bind, bind-dyndb-ldap, and fedora, but not freeipa, for dns. how do i setup the zone and record to accomplish this DNS trick? i have talked with some DNS gurus and they indicate that i can do something with the "@" record. it seems that the record i want, would be its own zone, and the @ record would point to the name, and the SOA would be the NAT IP. i could be wrong about the details, but something like this is how to setup resolution the way i want. any pointers would be greatly appreciated. thanks, brendan -- 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] separating authoritative servers from recursive servers
On 10/06/2015 07:42 AM, Petr Spacek wrote: On 6.10.2015 03:40, Brendan Kearney wrote: i have two bind instances in somewhat of a multi-master server arrangement, where they share the same ldap backend via bind-dyndb-ldap. currently, they are authoritative and recursive servers, and i want to change things up a bit. i want to move the recursive function to a third device. for this, i believe i need to set a forwarder for the two current servers. i believe i would do this by adding the idnsForwarders object (with value) on the OU that is the idnsConfigObject. i am looking for a sanity check, to ensure that i am not overlooking something important. are there any steps i am missing? i want the current two instances to be authoritative for all my forward and reverse zones, and use the forwarder for all recursion. the forwarder instance is already running, and is setup to answer queries from only the two current instances. i think i just need to point the current instances to the forwarder instance, and turn off recursion on them. Hmm, I think that there is some confusion about terms we use. Pure authoritative server would give out answers only for zones it is authoritative for (i.e. zones defined in /etc/named.conf or LDAP) and refuse to answer all other queries. Is that what are you looking for? In contrast, a recursive server would answer query for any zone. If you really want to separate authoritative and recursive roles, then you should: (0. As always: Make sure that delegation for all your zones is correct.) 1. Set up recursive-only server. Add 'allow-recursion { IP_range; };' to named.conf. 2. Reconfigure all clients to use the recursive-only server and not to ask authoritative servers directly. 3. Reconfigure authoritative servers by adding allow-recursion { none; }; to named.conf. No changes in LDAP should be necessary. Does it answer your question? i want to have separation of duties in my dns infrastructure. the intention is to have clients point to the current instances of dns for all records. behind the scenes, i want to have those current instances be authoritative for my internal zones, and for queries that they are not authoritative for, they reach out to the third server/instance for recursive queries. the third server/instance for recursive queries should not be contacted by clients. the end result is a hierarchy of roles for the dns instances. from the bind docs: The forwarding facility can be used to create a large site-wide cache on a few servers, reducing traffic over links to external name servers. It can also be used to allow queries by servers that do not have direct access to the Internet, but wish to look up exterior names anyway. Forwarding occurs only on those queries for which the server is not authoritative and does not have the answer in its cache. I plan to remove external access for the two current dns instances and force them to use the instance set as the forwarder for all external or recursive lookups. it seems that the idnsForwarders attribute is where i start working on this. -- 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] separating authoritative servers from recursive servers
i have two bind instances in somewhat of a multi-master server arrangement, where they share the same ldap backend via bind-dyndb-ldap. currently, they are authoritative and recursive servers, and i want to change things up a bit. i want to move the recursive function to a third device. for this, i believe i need to set a forwarder for the two current servers. i believe i would do this by adding the idnsForwarders object (with value) on the OU that is the idnsConfigObject. i am looking for a sanity check, to ensure that i am not overlooking something important. are there any steps i am missing? i want the current two instances to be authoritative for all my forward and reverse zones, and use the forwarder for all recursion. the forwarder instance is already running, and is setup to answer queries from only the two current instances. i think i just need to point the current instances to the forwarder instance, and turn off recursion on them. thanks in advance, brendan -- 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] GSSAPI authentication for libvirt VNC
On 08/30/2015 12:49 PM, Marin Bernard wrote: Hi, I followed the instructions from freeipa.org ( https://www.freeipa.org/page/Libvirt_with_VNC_Consoles) to make libvirt and VNC use GSSAPI authentication with FreeIPA. The libvirt part works fine: I'm able to SSO the KVM host using TCP + SASL. However, I'm unable to get a VNC connection to any guest: both virt-manager and virt -viewer fail. The former speaks about a "closed or refused connection", and the latter just closes. On the KVM host, each VNC login attempt adds the following record to the systemd journal: qemu-kvm[3202]: GSSAPI server step 1 On the host, libvirt starts qemu-kvm with a SASL VNC, which seems correct to me: # ps -aux | grep qemu-kvm -vnc 0.0.0.0:0,sasl QEMU may read the VNC keytab $ ls -l /etc/qemu/ total 4 -rw---. 1 qemu root 458 30 août 15:48 krb5.tab Contents of /etc/sasl2/qemu-kvm.conf (comments removed) mech_list: gssapi keytab: /etc/qemu/krb5.tab The client seems to grab correct tickets: $ klist Ticket cache: KEYRING:persistent:121541:krb_ccache_jjD9A46 Default principal: ma...@cloud.olivarim.com Valid starting Expires Service principal 30/08/2015 16:11:22 31/08/2015 15:34:53 vnc/nice-hkvm-ctrl-01 .core.nice.cloud.olivarim@cloud.olivarim.com 30/08/2015 16:08:12 31/08/2015 15:34:53 libvirt/nice-hkvm-ctr l-01.core.nice.cloud.olivarim@cloud.olivarim.com KVM Host is Centos 7.2, up to date. FreeIPA server is Centos 7.2, up to date, with FreeIPA 4.1.0 rev. 18.el7.centos.4 Client is Fedora 22, up to date. I tried to disable both the firewall and SELinux but it did not change anything. Do you have any clues ? Thanks! Marin. my /etc/sasl2/qemu.conf (note the different file name, may be relevant*): mech_list: gssapi keytab: /etc/qemu/qemu.keytab sasldb_path: /etc/qemu/passwd.db auxprop_plugin: sasldb my /etc/sasl2/libvirt.conf: mech_list: gssapi keytab: /etc/libvirt/libvirt.keytab my /etc/qemu/qemu.keytab file has the principal used/needed for VNC (vnc/host.domain.tld@REALM). you can check yours with "klist -Kket /path/to/qemu.keytab" my /etc/libvirt/libvirt.keytab file has the principal used/needed for virt-manager or virsh console (libvirt/host.domain.tld@REALM). you can check your with "klist -Kket /path/to/libvirt.keytab" * the name of the file in /etc/sasl2/ is tied to the name of the application. find the sysadmin.html page for Cyrus-SASL-libs, which states: By default, the Cyrus SASL library reads it's options from /usr/lib/sasl2/App.conf (where "App" is the application defined name of the application). For instance, Sendmail reads it's configuration from "/usr/lib/sasl2/Sendmail.conf" and the sample server application included with the library looks in "/usr/lib/sasl2/sample.conf". -- 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] bind-dyndb-ldap and stub zones
i am wondering if bind-dyndb-ldap supports stub zones. below would be a use case for me. say i have a network with a lot of external client connectivity (over leased line, MPLS, VPN, etc). the clients connections are used for inbound, outbound or bi-directional traffic (file transfers, web traffic, data exchange, etc). because of the size of my network, my already large and complex routing scheme for my own needs does not need to be made more complex by having to route my client's address space, so i devote specific networks out of my address space to 1-to-1 or static NAT addresses. by doing this, i can push all that traffic to the vpn endpoints or routers that manage that connectivity, without having to route "foreign" networks in the core. to make life easier, i want to have DNS names assigned to the NAT addresses, but the names are not in my authoritative name space, and may be internet resolvable, should a recursive search be performed. say i have mydomain.tld registered, and i have 300.555.0.0/16 assigned (yes, i know that does not exist). i would devote 300.555.254.0/23 to these 1-to-1 NATs. client Example Corp has dedicated connectivity to me and i want to access their website over that connection. the site, www.example.com, is internet resolvable but i dont want to access the internet accessible site. i want DNS resolution to point to my NAT, and take the traffic to the VPN where the NAT occurs and the traffic is pushed across to the client. with stub zones, i could create a zone, example.com, put a record for www into that zone and assign it my 1-to-1 NAT address of 300.555.254.1. i push my internal requests for that resource towards my vpn or client connection router, and perform the NAT at that device. my routing stays free of "foreign" networks and the traffic ends up where i want it. can bind-dyndb-ldap manage stub zones? how would one create the necessary ldap entries? sub zones require some extra work, so i would imagine stub zones do too, if they are currently supported. -- 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 behind a load balancer
On Tue, 2015-03-31 at 13:54 -0400, Simo Sorce wrote: > On Tue, 2015-03-31 at 13:50 -0400, Simo Sorce wrote: > > But IPA is more complex and some operations will be performed directly > > against the specific server name, so you need to keep 2 sets of keys > > (one for the server name and one for the load balancer name), but that > > does not work right now. > > One experiment that can be done is to remove all "per-server" HTTP > services for the IPA server, and instead add their name as aliases on > the common load-balancer name. > > This would mean that all IPA servers would have just one key in their > HTTP keytab, but the KDC would release tickets readable by that key for > any name the clients may ask for. > > It is a bit tricky, every time you build a replica you want to > load-balance you'll have to go back and remove the service and switch > keytabs, but it may be an option. Of course if you brick IPA then you > get to keep the pieces :-) > > Simo. > careful there, as kerberos balks at CNAME records. i think you need to use A records. i ran into a couple odd issues and decided to only use A/PTR records for my stuff and never went "exploring" for options/alternatives. -- 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 behind a load balancer
On Tue, 2015-03-31 at 19:36 +0200, Matt . wrote: > OK, but as I say, without the loadbalancer, same domain it works. > All the more reason to capture the session and review it in wireshark. > My IPA server also sees the client name and ptr as I do nat. > > So you create a keytab for your host you are doing the commands from ? all of my hosts get a host principal and have it put in /etc/krb5.keytab. i run kadmin to generate them. freeipa likely has utilities for this, but am not sure what they are. > I was using a user keytab and run my commands as that user, that works > to ipa-01 > > It's getting something more clear. -- 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 behind a load balancer
On Tue, 2015-03-31 at 18:18 +0200, Matt . wrote: > OK, that makes it even more clear. > > an ldapwhoami might be an issue. As this client is known on a > different ldap server and I kinit to another ldap server. There is a > reason for this as we have out office network and our deployment > network. Users that manage are in the office ldap, user that are in > deployment are in the deployment ldap. I do my kinit > username@deployment.domain which works ok when I run my commands at > ipa-01.deployment.domain. > > But when I want to do a ldapwhoami it tries to connect to the office > ldap server which is not working of course. (I get a connection error > atm, need to investigate as that server is running fine). > > Get the idea ? > > Thanks again! > > Matt > > 2015-03-31 17:58 GMT+02:00 Brendan Kearney : > > On Tue, 2015-03-31 at 17:51 +0200, Matt . wrote: > >> Hi Brendan, > >> > >> Yes thanks for your great explanation, I have done that indeed. But in > >> some strange way, with only a 401 in access_log of apache I get a Non > >> valid ticket when I connect through my loadbalancer. I don't go "by" > >> my loadbalancer but through it (NAT) or should it go "by/next" to it ? > >> > >> I think we can get this fixed :) > >> > >> Thanks! > >> > >> Matt > >> > >> 2015-03-31 17:41 GMT+02:00 Brendan Kearney : > >> > On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote: > >> >> On 03/31/2015 10:38 AM, Matt . wrote: > >> >> > True, but we have some extra later between which does the cli command > >> >> > not usable (at least for the moment) > >> >> > > >> >> > I already know how to share the key's among all servers, that works > >> >> > fine, IPA/Apache/Kerberos only doesn't like the other hostname > >> >> > (loadbalancer), or the client doesn't understand it. > >> >> > > >> >> > So fixing this saves me really much more time than doing the another > >> >> > way. > >> >> > >> >> Kerberos is not load balancer friendly. It is something that is a known > >> >> property of Kerberos. > >> >> I remember MIT mentioning something that they did or might do to help > >> >> with that so it might make sense to ask this question on the MIT > >> >> Kerberos user list. > >> >> > >> >> > > >> >> > Thanks! > >> >> > > >> >> > Matt > >> >> > > >> >> > 2015-03-31 16:24 GMT+02:00 Petr Spacek : > >> >> >> On 31.3.2015 16:10, Matt . wrote: > >> >> >>> HI Petr, > >> >> >>> > >> >> >>> We had a several of reasons why we did that. We wanted to use one > >> >> >>> language for that, and also have formatted returns. There was also > >> >> >>> some security issue which came up. > >> >> >> I would be very interested in the security reason. If you see any > >> >> >> problem with > >> >> >> 'ipa' command or FreeIPA API please send me a private e-mail or > >> >> >> contact > >> >> >> secal...@redhat.com directly. > >> >> >> > >> >> >>> I could ask you, why does IPA json itself ? if you see what it posts > >> >> >>> and what it gets back as result it makes it much more clear in > >> >> >>> development. > >> >> >> I do not understand the question, sorry. > >> >> >> > >> >> >> If you want to see what 'ipa' command does run it with '-vv' > >> >> >> parameter: > >> >> >> $ ipa -vv user-find > >> >> >> > >> >> >> It will print JSON request and reply: > >> >> >> ipa: INFO: Request: { > >> >> >> "id": 0, > >> >> >> "method": "user_find", > >> >> >> "params": [ > >> >> >> [ > >> >> >> null > >> >> >> ], > >> >> >> { > >> >> >> "all": false, > >> >> >> "no_members": false,
Re: [Freeipa-users] freeipa behind a load balancer
On Tue, 2015-03-31 at 12:53 -0400, Simo Sorce wrote: > On Tue, 2015-03-31 at 11:41 -0400, Brendan Kearney wrote: > > On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote: > > > On 03/31/2015 10:38 AM, Matt . wrote: > > > > True, but we have some extra later between which does the cli command > > > > not usable (at least for the moment) > > > > > > > > I already know how to share the key's among all servers, that works > > > > fine, IPA/Apache/Kerberos only doesn't like the other hostname > > > > (loadbalancer), or the client doesn't understand it. > > > > > > > > So fixing this saves me really much more time than doing the another > > > > way. > > > > > > Kerberos is not load balancer friendly. It is something that is a known > > > property of Kerberos. > > > I remember MIT mentioning something that they did or might do to help > > > with that so it might make sense to ask this question on the MIT > > > Kerberos user list. > > > > > > > > > > > Thanks! > > > > > > > > Matt > > > > > > > > 2015-03-31 16:24 GMT+02:00 Petr Spacek : > > > >> On 31.3.2015 16:10, Matt . wrote: > > > >>> HI Petr, > > > >>> > > > >>> We had a several of reasons why we did that. We wanted to use one > > > >>> language for that, and also have formatted returns. There was also > > > >>> some security issue which came up. > > > >> I would be very interested in the security reason. If you see any > > > >> problem with > > > >> 'ipa' command or FreeIPA API please send me a private e-mail or contact > > > >> secal...@redhat.com directly. > > > >> > > > >>> I could ask you, why does IPA json itself ? if you see what it posts > > > >>> and what it gets back as result it makes it much more clear in > > > >>> development. > > > >> I do not understand the question, sorry. > > > >> > > > >> If you want to see what 'ipa' command does run it with '-vv' parameter: > > > >> $ ipa -vv user-find > > > >> > > > >> It will print JSON request and reply: > > > >> ipa: INFO: Request: { > > > >> "id": 0, > > > >> "method": "user_find", > > > >> "params": [ > > > >> [ > > > >> null > > > >> ], > > > >> { > > > >> "all": false, > > > >> "no_members": false, > > > >> "pkey_only": false, > > > >> "raw": false, > > > >> "version": "2.115", > > > >> "whoami": false > > > >> } > > > >> ] > > > >> } > > > >> ipa: INFO: Response: { > > > >> "error": null, > > > >> "id": 0, > > > >> "principal": "admin@IPA.EXAMPLE", > > > >> "result": { > > > >> "count": 2, > > > >> "result": [ > > > >> { > > > >> "dn": > > > >> "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example", > > > >> "gidnumber": [ > > > >> "138100" > > > >> ], > > > >> ... > > > >> > > > >> > > > >>> HTTP loadbalancing is not difficult at all, as we post to the > > > >>> webserver I need to have that part only auth right. We do more very > > > >>> specific loadbalancing stuff and this is the most easy one as it's > > > >>> only webserver forward, but IPA/Kerberos has an issue with the > > > >>> principal it seems... it cannot be hard to make that accepted I would > > > >>> say. > > > >> If you insist on Kerberos servers behind a load balancer... you will > > > >> need to > > > >> somehow share the Kerberos key among all servers. I will defer that to &g
Re: [Freeipa-users] freeipa behind a load balancer
On Tue, 2015-03-31 at 17:51 +0200, Matt . wrote: > Hi Brendan, > > Yes thanks for your great explanation, I have done that indeed. But in > some strange way, with only a 401 in access_log of apache I get a Non > valid ticket when I connect through my loadbalancer. I don't go "by" > my loadbalancer but through it (NAT) or should it go "by/next" to it ? > > I think we can get this fixed :) > > Thanks! > > Matt > > 2015-03-31 17:41 GMT+02:00 Brendan Kearney : > > On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote: > >> On 03/31/2015 10:38 AM, Matt . wrote: > >> > True, but we have some extra later between which does the cli command > >> > not usable (at least for the moment) > >> > > >> > I already know how to share the key's among all servers, that works > >> > fine, IPA/Apache/Kerberos only doesn't like the other hostname > >> > (loadbalancer), or the client doesn't understand it. > >> > > >> > So fixing this saves me really much more time than doing the another way. > >> > >> Kerberos is not load balancer friendly. It is something that is a known > >> property of Kerberos. > >> I remember MIT mentioning something that they did or might do to help > >> with that so it might make sense to ask this question on the MIT > >> Kerberos user list. > >> > >> > > >> > Thanks! > >> > > >> > Matt > >> > > >> > 2015-03-31 16:24 GMT+02:00 Petr Spacek : > >> >> On 31.3.2015 16:10, Matt . wrote: > >> >>> HI Petr, > >> >>> > >> >>> We had a several of reasons why we did that. We wanted to use one > >> >>> language for that, and also have formatted returns. There was also > >> >>> some security issue which came up. > >> >> I would be very interested in the security reason. If you see any > >> >> problem with > >> >> 'ipa' command or FreeIPA API please send me a private e-mail or contact > >> >> secal...@redhat.com directly. > >> >> > >> >>> I could ask you, why does IPA json itself ? if you see what it posts > >> >>> and what it gets back as result it makes it much more clear in > >> >>> development. > >> >> I do not understand the question, sorry. > >> >> > >> >> If you want to see what 'ipa' command does run it with '-vv' parameter: > >> >> $ ipa -vv user-find > >> >> > >> >> It will print JSON request and reply: > >> >> ipa: INFO: Request: { > >> >> "id": 0, > >> >> "method": "user_find", > >> >> "params": [ > >> >> [ > >> >> null > >> >> ], > >> >> { > >> >> "all": false, > >> >> "no_members": false, > >> >> "pkey_only": false, > >> >> "raw": false, > >> >> "version": "2.115", > >> >> "whoami": false > >> >> } > >> >> ] > >> >> } > >> >> ipa: INFO: Response: { > >> >> "error": null, > >> >> "id": 0, > >> >> "principal": "admin@IPA.EXAMPLE", > >> >> "result": { > >> >> "count": 2, > >> >> "result": [ > >> >> { > >> >> "dn": > >> >> "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example", > >> >> "gidnumber": [ > >> >> "138100" > >> >> ], > >> >> ... > >> >> > >> >> > >> >>> HTTP loadbalancing is not difficult at all, as we post to the > >> >>> webserver I need to have that part only auth right. We do more very > >> >>> specific loadbalancing stuff and this is the most easy one as it's > >> >>> only webserver forward, but IPA/Kerberos has an issue with the > >> >>> principal it seems...
Re: [Freeipa-users] freeipa behind a load balancer
On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote: > On 03/31/2015 10:38 AM, Matt . wrote: > > True, but we have some extra later between which does the cli command > > not usable (at least for the moment) > > > > I already know how to share the key's among all servers, that works > > fine, IPA/Apache/Kerberos only doesn't like the other hostname > > (loadbalancer), or the client doesn't understand it. > > > > So fixing this saves me really much more time than doing the another way. > > Kerberos is not load balancer friendly. It is something that is a known > property of Kerberos. > I remember MIT mentioning something that they did or might do to help > with that so it might make sense to ask this question on the MIT > Kerberos user list. > > > > > Thanks! > > > > Matt > > > > 2015-03-31 16:24 GMT+02:00 Petr Spacek : > >> On 31.3.2015 16:10, Matt . wrote: > >>> HI Petr, > >>> > >>> We had a several of reasons why we did that. We wanted to use one > >>> language for that, and also have formatted returns. There was also > >>> some security issue which came up. > >> I would be very interested in the security reason. If you see any problem > >> with > >> 'ipa' command or FreeIPA API please send me a private e-mail or contact > >> secal...@redhat.com directly. > >> > >>> I could ask you, why does IPA json itself ? if you see what it posts > >>> and what it gets back as result it makes it much more clear in > >>> development. > >> I do not understand the question, sorry. > >> > >> If you want to see what 'ipa' command does run it with '-vv' parameter: > >> $ ipa -vv user-find > >> > >> It will print JSON request and reply: > >> ipa: INFO: Request: { > >> "id": 0, > >> "method": "user_find", > >> "params": [ > >> [ > >> null > >> ], > >> { > >> "all": false, > >> "no_members": false, > >> "pkey_only": false, > >> "raw": false, > >> "version": "2.115", > >> "whoami": false > >> } > >> ] > >> } > >> ipa: INFO: Response: { > >> "error": null, > >> "id": 0, > >> "principal": "admin@IPA.EXAMPLE", > >> "result": { > >> "count": 2, > >> "result": [ > >> { > >> "dn": "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example", > >> "gidnumber": [ > >> "138100" > >> ], > >> ... > >> > >> > >>> HTTP loadbalancing is not difficult at all, as we post to the > >>> webserver I need to have that part only auth right. We do more very > >>> specific loadbalancing stuff and this is the most easy one as it's > >>> only webserver forward, but IPA/Kerberos has an issue with the > >>> principal it seems... it cannot be hard to make that accepted I would > >>> say. > >> If you insist on Kerberos servers behind a load balancer... you will need > >> to > >> somehow share the Kerberos key among all servers. I will defer that to > >> Kerberos experts here. > >> > >>> I'm still looking for solutions :) > >> Sure, but you will save a lot of time and nerves if you simply call 'ipa' > >> command :-) > >> > >> Have a nice day! > >> > >> Petr^2 Spacek > >> > >>> Cheers, > >>> > >>> Matt > >>> > >>> 2015-03-31 15:58 GMT+02:00 Petr Spacek : > On 31.3.2015 15:23, Matt . wrote: > > Hi Petr, > > > > We discussed that before indeed, but SRV is not usable in this case. > > > > My clients are just webservers (apache) doing some executes of CURL > > commands to ipa/json, actually the same commands as the webgui does > > using json, but we curl it. > > > > Do you have a better view now ? > Yes. If you have seen the previous discussion then you know that it will > be > pretty difficult to do this kind of load balancing. > > Why are you not using 'ipa' command or Python API we have instead? Why > to use > CURL and make things more complex? > > Petr^2 Spacek > > > 2015-03-31 15:03 GMT+02:00 Petr Spacek : > >> On 31.3.2015 14:35, Matt . wrote: > >>> Hi Petr, > >>> > >>> As this is not my topic it's for me quite "simple". > >>> > >>> I need to post to /ipa/json through a loadbalancer, nothing more. > >>> > >>> i have > >>> > >>> ldap-01.domain.tld (ipa1) > >>> ldap-01.domain.tld (ipa2) > >>> > >>> and my loadbalancer is ldap.domain.tld > >>> > >>> ldap requests over a loadbalancer are quite simple and working, but > >>> the json part is more difficult because of the ticket and the dns > >>> name. I have added a san ldap.domain.tld to the webgui and there is a > >>> http/ldap.domain.tld service on the ipa server. > >>> > >>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to > >>> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld > >>> after it failed my ticket is OK for l
Re: [Freeipa-users] Unknown Client?
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] Group Policy-like features in FreeIPA
OpenAFS? On Jan 12, 2015 11:04 AM, "Craig White" wrote: > *From:* freeipa-users-boun...@redhat.com [mailto: > freeipa-users-boun...@redhat.com] *On Behalf Of *Dale Macartney > *Sent:* Sunday, January 11, 2015 2:16 PM > *To:* freeipa-users@redhat.com > *Subject:* [Freeipa-users] Group Policy-like features in FreeIPA > > > > Morning folks > > I am currently working on a little pet project which I think some would > find useful. > > I would like to introduce some group policy like functionality into a > FreeIPA domain. > > For example: > > In an environment running FreeIPA Server with Fedora or RHEL based > workstations, I would like to be able to introduce a few extra features > which initially may be pushed via a login script (maybe even configure a > dbus session as well, who knows?). > > My intentions here would be to be able to apply host specific policies as > well as have the option for user specific policies which would be applied > when the user logs in. > > Practically speaking, adding an attribute to LDAP to specify a login > script file name is easy enough, however actually fetching this is where I > am hoping for a bit of brain storming. My thoughts would be the local user > would fetch the name of the login script via ldap, and then perhaps fetch > the file from a shared resource on the FreeIPA masters in order to be > executed locally. > > LDAP is obviously replicated, however to my knowledge, there is no file > synchronization between masters. I am thinking something similar to the MS > equivalent of the SYSVOL data that replicates between MS Domain > Controllers. One option would be to store all data within LDAP, however > I've seen many scenarios where admins store CD ISO's in replicated domain > data, so I am not certain this would be the best option. > > With this replicated data folder, I would be able to store centrally > managed scripts which would be used for hosts or users, and then configure > the default user template on each workstation (/etc/skel/) to add the login > script file name which would be fetched from the users LDAP attributes. > > Real world usability for what I am thinking of is a way to manage users > who can have their corporate email mailbox configured on login, > automatically setting the users session to point to an internal SSO enabled > proxy server or perhaps any other number of things which an admin may wish > to achieve without the need to manually do the work themselves. > > Has anyone undertaken a similar scenario in their environments or would > perhaps have any suggestions on how to manage the centrally accessible file > stores? > > Many thanks > > > Specifically, I haven’t fully implemented what you are asking but > obviously parts and pieces yes. > > One of the best features of Linux and all of its various toolsets is that > one are quite so overarching and the objectives are more focused. String > them together and you have a working tool set. As a system administrator, > you learn to pipe grep output to awk or sed or cut etc. > > SYSVOL ó NFS and if that doesn’t do it for you, check out Unison. > > I guess one of the temptations of FreeIPA is to try to make it exactly > like active directory. The FreeIPA developers are already doing an amazing > job without a ton of manpower. > > Craig > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Getfedora.org ssl cert issue
Can someone up-channel an issue with getfedora.org? The site changed URLs, and the cert was not amended to include the new URL as a Subject Alternative Name and now cert mismatches are occurring. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa / sudoers on centos 6.3 client
On Fri, 2015-01-02 at 15:19 +, Chris Card wrote: > I have existing machines running CentOS 6.3 which I want to include in > a freeipa domain. > > The domain controller machine is running Fedora 21 and > freeipa-server-4.1.1-2 while the latest version of ipa I can find that > runs on CentOS 6.3 is ipa-client-3.0.0-37.el6.x86_64. > > > I have successfully run ipa-client-install on the CentOS 6.3 client > and set up users who can ssh to the client using ssh-keys. > > > The problem is that I can't get sudo rules to work. I know that the > ipa client software version 3.0.0 doesn't automatically set up all the > configuration for sssd to control sudo access, but I have set up all > the configuration necessary manually: > > > On the client, /etc/nsswitch.conf has > > > sudoers files sss > > > /etc/sssd/sssd/conf has > > > [domain/default] > > > cache_credentials = True > krb5_realm = > krb5_server = :88 > id_provider = ldap > auth_provider = ldap > chpass_provider = ldap > ldap_tls_cacertdir = /etc/openldap/cacerts > [domain/] > > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = > id_provider = ipa > auth_provider = ipa > access_provider = ipa > chpass_provider = ipa > ipa_dyndns_update = True > ipa_server = > ldap_tls_cacert = /etc/ipa/ca.crt > sudo_provider = ldap > ldap_uri = ldap:// > ldap_sudo_search_base = ou=sudoers, > ldap_sasl_mech = GSSAPI > ldap_sasl_authid = host/ > ldap_sasl_realm = > krb5_server = > debug_level = 9 > [sssd] > services = nss, pam, ssh, sudo > config_file_version = 2 > > > domains = , default > debug_level = 9 > [nss] > debug_level = 9 > > > [pam] > debug_level = 9 > > > [sudo] > debug_level = 9 > [autofs] > > > I have validated the ldap sasl configuration using ldapsearch, so I'm > sure they are correct. > > > The nisdomainname command returns the domain name. > > > The sudo rules are: > # ipa sudorule-find > > 2 Sudo Rules matched > > Rule name: sudo-host1 > Enabled: TRUE > Command category: all > RunAs User category: all > User Groups: host1-rw > Host Groups: host1 > Sudo Option: -authenticate > > > Rule name: sudo-host2 > Enabled: TRUE > User Groups: host2-rw > Host Groups: host2 > Sudo Option: -authenticate > > Number of entries returned 2 > > > > When a user in user group host1-rw sshs to a client in host group > host1 and runs "sudo su -" the user gets prompted for a password even > though the sudo option -authenticate is set. > I'm not convinced that sudo is even attempting to use sssd, but I'm > not sure how to confirm this. > > > I have seen some references to /etc/sudo-ldap.conf in online > discussions of similar issues. This file exists on my client, but > everything is commented out. Do I need to put the ldap client > configuration in /etc/sudo-ldap.conf as well as /etc/sssd/sssd.conf > for CentOS 6.3 clients? > > > Any ideas about how to work out what is failing? > > > Chris > try "!authenticate" (without the quotes), not "-authenticate" (again, no quotes). -- 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] bind-dyndb-ldap and ddns updates from dhcp
On Wed, 2014-12-31 at 19:06 +0100, Jan Pazdziora wrote: > On Mon, Dec 29, 2014 at 07:12:26PM -0500, Brendan Kearney wrote: > > On Mon, 2014-12-29 at 16:53 -0500, Dmitri Pal wrote: > > > bind-dyndb-ldap isa back end driver for BIND to get data from an LDAP > > > storage. > > > The updates are done by BIND. The IPA BIND accepts kerberos based updates. > > > > > > http://www.freeipa.org/page/FreeIPAv2:Dynamic_updates_with_GSS-TSIG > > > > this allows for a ticketed client to update DNS records directly, which > > is not a best practice and is a huge security risk. clients should not > > be able to manipulate DNS zones. > > Only if you configure that. But you don't have to grant krb5-self, > you can grant the > > SERVICE\047ipaserver.example@example.com wildcard * ANY; > > and just have the DHCP service call nsupdate -g. > > > dynamic updates to DNS zones should come from DHCP, where dynamic > > addressing is managed. as such, i have directives in DHCP and DNS to > > establish authenticated updates between DHCP and DNS. for example: > > > > /etc/named.conf: > > > > key "dhcp" { > > algorithm hmac-md5; > > secret SomeRandomString; > > }; > > With FreeIPA, Kerberos authentication is really the preferred way > of integrating pieces together because it provides the identity of > the service running the action, not just some shared secret / password. > > > because the DHCP daemon is not kerberized, the update policies do not > > [...] > > > i am wondering how to manage DDNS updates from DHCP, where kerberized > > updates are not likely going to happen. > > What DHCP software is that and how hard would it be to Kerberize it? > i have played with nsupdate, and it does look like updates will be allowed if i remove the access restriction, but i am losing the authenticity of the update, since the TSIG shared secret signs the update. regardless of authentication, client updates to DNS zones are still a risk and a rogue app or user can still perform direct updates to zones, leading to impersonation/interception of services, denial of service attacks and more. endpoints, or their users, should not be trusted to make updates to DNS zones. TSIG signed updates from servers are still preferred over authenticated updates from endpoints or users. i am using ISC DHCP, and cannot speak to any level of effort required to incorporate Kerberos into the code. -- 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] bind-dyndb-ldap and ddns updates from dhcp
On Mon, 2014-12-29 at 16:53 -0500, Dmitri Pal wrote: > On 12/29/2014 04:47 PM, Brendan Kearney wrote: > > where can i find howto info around setting up bind-dyndb-ldap to accept > > ddns updates from dhcp? usually, i have a shared key defined in dns and > > dhcp, and the updates are authenticated. where are the docs for setting > > this up in bind-dyndb-ldap? > > > I am not sure I understand the use case correctly. > bind-dyndb-ldap isa back end driver for BIND to get data from an LDAP > storage. > The updates are done by BIND. The IPA BIND accepts kerberos based updates. > > http://www.freeipa.org/page/FreeIPAv2:Dynamic_updates_with_GSS-TSIG > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > this allows for a ticketed client to update DNS records directly, which is not a best practice and is a huge security risk. clients should not be able to manipulate DNS zones. dynamic updates to DNS zones should come from DHCP, where dynamic addressing is managed. as such, i have directives in DHCP and DNS to establish authenticated updates between DHCP and DNS. for example: /etc/named.conf: key "dhcp" { algorithm hmac-md5; secret SomeRandomString; }; ... zone "1.168.192.in-addr.arpa" IN { type master; file "dynamic/1.168.192.in-addr.arpa.db"; allow-update { key dhcp; }; }; zone "bpk2.com" IN { type master; file "dynamic/bpk2.com.db"; check-names ignore; allow-update { key dhcp; }; }; /etc/dhcp/dhcpd.conf key "dhcp"{ algorithm hmac-md5; secret SomeRandomString; }; zone 1.168.192.in-addr.arpa { primary 192.168.1.1; key dhcp; } zone bpk2.com { primary 192.168.1.1; key dhcp; } because the DHCP daemon is not kerberized, the update policies do not seem to cover the situation where clients are not allowed to update DNS zones themselves. i am wondering how to manage DDNS updates from DHCP, where kerberized updates are not likely going to happen. -- 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] bind-dyndb-ldap and ddns updates from dhcp
where can i find howto info around setting up bind-dyndb-ldap to accept ddns updates from dhcp? usually, i have a shared key defined in dns and dhcp, and the updates are authenticated. where are the docs for setting this up in bind-dyndb-ldap? -- 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] Fedora Core IPTables or FirewallID?
systemctl stop firewalld systemctl disable firewalld systemctl stop iptables systemctl disable iptables sudo iptables -nvL This is not a recommended config, as a firewall will save your bacon without you realizing it. Fwbuilder is a great package in the fedora repos that will write excellent firewall policies. Maybe take a look at that. On Aug 25, 2014 10:24 PM, "Chris Whittle" wrote: > I've got my server up and running great with one exception every time I > reboot I have to login and flush the iptables or nothing can connect. > > I've found a ton of fixes and none seem to work, I'm on FC20 does anyone > have experience with it and wouldn't mind helping? > > -- > 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] FreeIPA and FQDN requirements
Maybe I am reading too far into rfc 1178, but I hardly think making hostnames required to be fqdns is in anybodys interest. It is not a requirement now in any other technology anywhere, so what is the impetus to push it? I dont see any value in it On Aug 8, 2014 2:37 PM, "Rich Megginson" wrote: > On 08/08/2014 12:21 PM, brendan kearney wrote: > > Double check your example. -h means the hostname of the ldap server to > connect to and issue your query to. Man page calls it ldaphost. > > > Yes. > > I have not run across a client that does cert validation using ldap. Is > that IPA specific? > > > I'm not talking about cert validation using ldap. I'm talking about the > fact that, by default, the ldapsearch client will expect the hostname you > pass in to match the hostname in the ssl server cert subject DN. > > It seems that a lot of effort is being spent to justify a dependency on > fully qualified hostnames, when there is no reason to require it. In fact, > it may even break somethings or even violate some rfc. > > > If requiring fully qualified hostnames violates RFCs or other standards, > I'd like to hear about it. > > On Aug 8, 2014 1:43 PM, "Rich Megginson" wrote: > >> On 08/08/2014 11:17 AM, brendan kearney wrote: >> >> The cert should have the fqdn, just like the kerberos instance, but the >> hostname is not required to be fq'd. The lookup of a short name, as well >> as and more specifically the IP, in dns will result in the fqdn being >> returned by dns (the short name resolution being affected by domain and >> search directives in resolv.conf and the origin directive in dns if either >> of those are absent). >> >> Back to the point, dns lookup for cert matching is not dependent on >> hostnames. PTR lookups will always return fqdns, so a dependency on fqdns >> as hostnames is artificial, no? >> >> >> Most clients will also do the additional step of matching the hostname in >> the cert against the originally given hostname. For example, with >> ldapsearch: >> >> ldapsearch -xLLLZZ -h hostname ... >> >> This will fail if the server cert for hostname has >> "cn=hostname.domain.tld" >> >> On Aug 8, 2014 1:03 PM, "Rich Megginson" wrote: >> >>> On 08/08/2014 10:56 AM, brendan kearney wrote: >>> >>> Arent all of those lookups done in dns? >>> >>> >>> Yes. >>> >>> Wouldnt that mean hostnames being fqdn's is irrelevant? >>> >>> >>> Not sure what you mean. >>> >>> I guess if you issued your server certs with a subject DN of >>> "cn=hostname", instead of "cn=hostname.domain.tld", and you had the DNS PTR >>> lookups configured so that w.x.y.z returned "hostname" instead of >>> "hostname.domain.tld", then TLS/SSL would work. >>> >>> On Aug 8, 2014 12:11 PM, "Rich Megginson" wrote: >>> >>>> On 08/08/2014 08:57 AM, brendan kearney wrote: >>>> >>>> Kerberos is dependent on A records in dns. The instance (as in >>>> principal/instance@REALM) should match the A record in dns. >>>> >>>> There is absolutely no Kerberos dependency on hostnames being fully >>>> qualified. I have all my devices named with short names and I have no >>>> issues with Kerberos ticketing. >>>> >>>> This seems to be an artificial requirement in FreeIPA that is wrong. >>>> >>>> >>>> The other hostname requirement is for TLS/SSL, for MITM checking. By >>>> default, when an SSL server cert is issued, the subject DN contains cn=fqdn >>>> as the leftmost component. clients use this fqdn to verify the server. >>>> That is, client knows the IP address of the server - client does a reverse >>>> lookup (i.e. PTR) to see if the server returned by that lookup matches the >>>> cn=fqdn in the server cert. This requires reverse lookups are configured >>>> and that the fqdn is the first name/alias returned. >>>> >>>> On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" < >>>> bruno-barb...@prodesan.com.br> wrote: >>>> >>>>> Hello everyone, >>>>> >>>>> I'm running through an issue where an application needs its server's >>>>> hostname to be in short name format, such as "server" and not " >>>>> server.example.com". When I started dep
Re: [Freeipa-users] FreeIPA and FQDN requirements
Double check your example. -h means the hostname of the ldap server to connect to and issue your query to. Man page calls it ldaphost. I have not run across a client that does cert validation using ldap. Is that IPA specific? It seems that a lot of effort is being spent to justify a dependency on fully qualified hostnames, when there is no reason to require it. In fact, it may even break somethings or even violate some rfc. On Aug 8, 2014 1:43 PM, "Rich Megginson" wrote: > On 08/08/2014 11:17 AM, brendan kearney wrote: > > The cert should have the fqdn, just like the kerberos instance, but the > hostname is not required to be fq'd. The lookup of a short name, as well > as and more specifically the IP, in dns will result in the fqdn being > returned by dns (the short name resolution being affected by domain and > search directives in resolv.conf and the origin directive in dns if either > of those are absent). > > Back to the point, dns lookup for cert matching is not dependent on > hostnames. PTR lookups will always return fqdns, so a dependency on fqdns > as hostnames is artificial, no? > > > Most clients will also do the additional step of matching the hostname in > the cert against the originally given hostname. For example, with > ldapsearch: > > ldapsearch -xLLLZZ -h hostname ... > > This will fail if the server cert for hostname has "cn=hostname.domain.tld" > > On Aug 8, 2014 1:03 PM, "Rich Megginson" wrote: > >> On 08/08/2014 10:56 AM, brendan kearney wrote: >> >> Arent all of those lookups done in dns? >> >> >> Yes. >> >> Wouldnt that mean hostnames being fqdn's is irrelevant? >> >> >> Not sure what you mean. >> >> I guess if you issued your server certs with a subject DN of >> "cn=hostname", instead of "cn=hostname.domain.tld", and you had the DNS PTR >> lookups configured so that w.x.y.z returned "hostname" instead of >> "hostname.domain.tld", then TLS/SSL would work. >> >> On Aug 8, 2014 12:11 PM, "Rich Megginson" wrote: >> >>> On 08/08/2014 08:57 AM, brendan kearney wrote: >>> >>> Kerberos is dependent on A records in dns. The instance (as in >>> principal/instance@REALM) should match the A record in dns. >>> >>> There is absolutely no Kerberos dependency on hostnames being fully >>> qualified. I have all my devices named with short names and I have no >>> issues with Kerberos ticketing. >>> >>> This seems to be an artificial requirement in FreeIPA that is wrong. >>> >>> >>> The other hostname requirement is for TLS/SSL, for MITM checking. By >>> default, when an SSL server cert is issued, the subject DN contains cn=fqdn >>> as the leftmost component. clients use this fqdn to verify the server. >>> That is, client knows the IP address of the server - client does a reverse >>> lookup (i.e. PTR) to see if the server returned by that lookup matches the >>> cn=fqdn in the server cert. This requires reverse lookups are configured >>> and that the fqdn is the first name/alias returned. >>> >>> On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" < >>> bruno-barb...@prodesan.com.br> wrote: >>> >>>> Hello everyone, >>>> >>>> I'm running through an issue where an application needs its server's >>>> hostname to be in short name format, such as "server" and not " >>>> server.example.com". When I started deploying FreeIPA in the very >>>> beginning of this year, I remember I couldn't install freeipa-client with a >>>> bare "ipa-client install", because of this: >>>> >>>> >>>> >>>> [root@server ~]# hostname >>>> server >>>> [root@server ~]# hostname -f >>>> server.example.com >>>> [root@server ~]# ipa-client-install >>>> Discovery was successful! >>>> Hostname: server.example.com >>>> Realm: EXAMPLE.COM >>>> DNS Domain: example.com >>>> IPA Server: ipa01.example.com >>>> Base DN: dc=example,dc=com >>>> >>>> Continue to configure the system with these values? [no] yes >>>> User authorized to enroll computers: admin >>>> Synchronizing time with KDC... >>>> Unable to sync time with IPA NTP Server, assuming the time is in sync. >>>> Please check that port 123 UDP is opened. >>>> Password for ad...@example.com: &
Re: [Freeipa-users] FreeIPA and FQDN requirements
The cert should have the fqdn, just like the kerberos instance, but the hostname is not required to be fq'd. The lookup of a short name, as well as and more specifically the IP, in dns will result in the fqdn being returned by dns (the short name resolution being affected by domain and search directives in resolv.conf and the origin directive in dns if either of those are absent). Back to the point, dns lookup for cert matching is not dependent on hostnames. PTR lookups will always return fqdns, so a dependency on fqdns as hostnames is artificial, no? On Aug 8, 2014 1:03 PM, "Rich Megginson" wrote: > On 08/08/2014 10:56 AM, brendan kearney wrote: > > Arent all of those lookups done in dns? > > > Yes. > > Wouldnt that mean hostnames being fqdn's is irrelevant? > > > Not sure what you mean. > > I guess if you issued your server certs with a subject DN of > "cn=hostname", instead of "cn=hostname.domain.tld", and you had the DNS PTR > lookups configured so that w.x.y.z returned "hostname" instead of > "hostname.domain.tld", then TLS/SSL would work. > > On Aug 8, 2014 12:11 PM, "Rich Megginson" wrote: > >> On 08/08/2014 08:57 AM, brendan kearney wrote: >> >> Kerberos is dependent on A records in dns. The instance (as in >> principal/instance@REALM) should match the A record in dns. >> >> There is absolutely no Kerberos dependency on hostnames being fully >> qualified. I have all my devices named with short names and I have no >> issues with Kerberos ticketing. >> >> This seems to be an artificial requirement in FreeIPA that is wrong. >> >> >> The other hostname requirement is for TLS/SSL, for MITM checking. By >> default, when an SSL server cert is issued, the subject DN contains cn=fqdn >> as the leftmost component. clients use this fqdn to verify the server. >> That is, client knows the IP address of the server - client does a reverse >> lookup (i.e. PTR) to see if the server returned by that lookup matches the >> cn=fqdn in the server cert. This requires reverse lookups are configured >> and that the fqdn is the first name/alias returned. >> >> On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" < >> bruno-barb...@prodesan.com.br> wrote: >> >>> Hello everyone, >>> >>> I'm running through an issue where an application needs its server's >>> hostname to be in short name format, such as "server" and not " >>> server.example.com". When I started deploying FreeIPA in the very >>> beginning of this year, I remember I couldn't install freeipa-client with a >>> bare "ipa-client install", because of this: >>> >>> >>> >>> [root@server ~]# hostname >>> server >>> [root@server ~]# hostname -f >>> server.example.com >>> [root@server ~]# ipa-client-install >>> Discovery was successful! >>> Hostname: server.example.com >>> Realm: EXAMPLE.COM >>> DNS Domain: example.com >>> IPA Server: ipa01.example.com >>> Base DN: dc=example,dc=com >>> >>> Continue to configure the system with these values? [no] yes >>> User authorized to enroll computers: admin >>> Synchronizing time with KDC... >>> Unable to sync time with IPA NTP Server, assuming the time is in sync. >>> Please check that port 123 UDP is opened. >>> Password for ad...@example.com: >>> Joining realm failed: The hostname must be fully-qualified: server >>> Installation failed. Rolling back changes. >>> IPA client is not configured on this system. >>> >>> >>> >>> So, using the short name as hostname didn't work for install, I then >>> make it like "ipa-client install --hostname=`hostname -f` --mkhomedir -N", >>> and it installs and works like a charm, BUT it updates the machine's >>> hostname to FQDN. >>> >>> What I tested and, at first, worked: after deploying and ipa-client >>> installation with those parameters which work, renaming the machine back to >>> a short name AT FIRST is not causing any problems. I can login with my ssh >>> rules perfectly, but I don't find any IPA technical docs saying it >>> will/won't work if I change the hostname back to short name and not FQDN. >>> >>> Searching for it, I found on RedHat guide: "The hostname of a system is >>> critical for the correct operation of Kerberos and SSL. Both of these >>> security mech
Re: [Freeipa-users] FreeIPA and FQDN requirements
Arent all of those lookups done in dns? Wouldnt that mean hostnames being fqdn's is irrelevant? On Aug 8, 2014 12:11 PM, "Rich Megginson" wrote: > On 08/08/2014 08:57 AM, brendan kearney wrote: > > Kerberos is dependent on A records in dns. The instance (as in > principal/instance@REALM) should match the A record in dns. > > There is absolutely no Kerberos dependency on hostnames being fully > qualified. I have all my devices named with short names and I have no > issues with Kerberos ticketing. > > This seems to be an artificial requirement in FreeIPA that is wrong. > > > The other hostname requirement is for TLS/SSL, for MITM checking. By > default, when an SSL server cert is issued, the subject DN contains cn=fqdn > as the leftmost component. clients use this fqdn to verify the server. > That is, client knows the IP address of the server - client does a reverse > lookup (i.e. PTR) to see if the server returned by that lookup matches the > cn=fqdn in the server cert. This requires reverse lookups are configured > and that the fqdn is the first name/alias returned. > > On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" < > bruno-barb...@prodesan.com.br> wrote: > >> Hello everyone, >> >> I'm running through an issue where an application needs its server's >> hostname to be in short name format, such as "server" and not " >> server.example.com". When I started deploying FreeIPA in the very >> beginning of this year, I remember I couldn't install freeipa-client with a >> bare "ipa-client install", because of this: >> >> >> >> [root@server ~]# hostname >> server >> [root@server ~]# hostname -f >> server.example.com >> [root@server ~]# ipa-client-install >> Discovery was successful! >> Hostname: server.example.com >> Realm: EXAMPLE.COM >> DNS Domain: example.com >> IPA Server: ipa01.example.com >> Base DN: dc=example,dc=com >> >> Continue to configure the system with these values? [no] yes >> User authorized to enroll computers: admin >> Synchronizing time with KDC... >> Unable to sync time with IPA NTP Server, assuming the time is in sync. >> Please check that port 123 UDP is opened. >> Password for ad...@example.com: >> Joining realm failed: The hostname must be fully-qualified: server >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> >> >> So, using the short name as hostname didn't work for install, I then make >> it like "ipa-client install --hostname=`hostname -f` --mkhomedir -N", and >> it installs and works like a charm, BUT it updates the machine's hostname >> to FQDN. >> >> What I tested and, at first, worked: after deploying and ipa-client >> installation with those parameters which work, renaming the machine back to >> a short name AT FIRST is not causing any problems. I can login with my ssh >> rules perfectly, but I don't find any IPA technical docs saying it >> will/won't work if I change the hostname back to short name and not FQDN. >> >> Searching for it, I found on RedHat guide: "The hostname of a system is >> critical for the correct operation of Kerberos and SSL. Both of these >> security mechanisms rely on the hostname to ensure that communication is >> occurring between the specified hosts." >> I've also found this message >> http://osdir.com/ml/freeipa-users/2012-03/msg6.html which seems to >> be related to my case, but what I need to know is: where does it state FQDN >> is a mandatory requirement in order to FreeIPA to work and/or is there >> anything else (a patch, update, whatever) to solve this issue, so I don't >> need to change my applications? >> >> Thank you and sorry for the wall of a text. >> >> PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is not >> the same server as IPA (it forwards to a Windows DC). >> >> RPMs: >> libipa_hbac-1.9.2-129.el6_5.4.x86_64 >> libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 >> python-iniparse-0.3.1-2.1.el6.noarch >> ipa-pki-common-theme-9.0.3-7.el6.noarch >> ipa-pki-ca-theme-9.0.3-7.el6.noarch >> ipa-admintools-3.0.0-37.el6.x86_64 >> ipa-server-selinux-3.0.0-37.el6.x86_64 >> ipa-server-3.0.0-37.el6.x86_64 >> ipa-python-3.0.0-37.el6.x86_64 >> ipa-client-3.0.0-37.el6.x86_64 >> >> >> >> -- >> 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 > -- 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 and FQDN requirements
Correction, its primary/instance@REALM On Aug 8, 2014 10:57 AM, "brendan kearney" wrote: > Kerberos is dependent on A records in dns. The instance (as in > principal/instance@REALM) should match the A record in dns. > > There is absolutely no Kerberos dependency on hostnames being fully > qualified. I have all my devices named with short names and I have no > issues with Kerberos ticketing. > > This seems to be an artificial requirement in FreeIPA that is wrong. > On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" < > bruno-barb...@prodesan.com.br> wrote: > >> Hello everyone, >> >> I'm running through an issue where an application needs its server's >> hostname to be in short name format, such as "server" and not " >> server.example.com". When I started deploying FreeIPA in the very >> beginning of this year, I remember I couldn't install freeipa-client with a >> bare "ipa-client install", because of this: >> >> >> >> [root@server ~]# hostname >> server >> [root@server ~]# hostname -f >> server.example.com >> [root@server ~]# ipa-client-install >> Discovery was successful! >> Hostname: server.example.com >> Realm: EXAMPLE.COM >> DNS Domain: example.com >> IPA Server: ipa01.example.com >> Base DN: dc=example,dc=com >> >> Continue to configure the system with these values? [no] yes >> User authorized to enroll computers: admin >> Synchronizing time with KDC... >> Unable to sync time with IPA NTP Server, assuming the time is in sync. >> Please check that port 123 UDP is opened. >> Password for ad...@example.com: >> Joining realm failed: The hostname must be fully-qualified: server >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> >> >> So, using the short name as hostname didn't work for install, I then make >> it like "ipa-client install --hostname=`hostname -f` --mkhomedir -N", and >> it installs and works like a charm, BUT it updates the machine's hostname >> to FQDN. >> >> What I tested and, at first, worked: after deploying and ipa-client >> installation with those parameters which work, renaming the machine back to >> a short name AT FIRST is not causing any problems. I can login with my ssh >> rules perfectly, but I don't find any IPA technical docs saying it >> will/won't work if I change the hostname back to short name and not FQDN. >> >> Searching for it, I found on RedHat guide: "The hostname of a system is >> critical for the correct operation of Kerberos and SSL. Both of these >> security mechanisms rely on the hostname to ensure that communication is >> occurring between the specified hosts." >> I've also found this message >> http://osdir.com/ml/freeipa-users/2012-03/msg6.html which seems to >> be related to my case, but what I need to know is: where does it state FQDN >> is a mandatory requirement in order to FreeIPA to work and/or is there >> anything else (a patch, update, whatever) to solve this issue, so I don't >> need to change my applications? >> >> Thank you and sorry for the wall of a text. >> >> PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is not >> the same server as IPA (it forwards to a Windows DC). >> >> RPMs: >> libipa_hbac-1.9.2-129.el6_5.4.x86_64 >> libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 >> python-iniparse-0.3.1-2.1.el6.noarch >> ipa-pki-common-theme-9.0.3-7.el6.noarch >> ipa-pki-ca-theme-9.0.3-7.el6.noarch >> ipa-admintools-3.0.0-37.el6.x86_64 >> ipa-server-selinux-3.0.0-37.el6.x86_64 >> ipa-server-3.0.0-37.el6.x86_64 >> ipa-python-3.0.0-37.el6.x86_64 >> ipa-client-3.0.0-37.el6.x86_64 >> >> >> >> -- >> 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] FreeIPA and FQDN requirements
Kerberos is dependent on A records in dns. The instance (as in principal/instance@REALM) should match the A record in dns. There is absolutely no Kerberos dependency on hostnames being fully qualified. I have all my devices named with short names and I have no issues with Kerberos ticketing. This seems to be an artificial requirement in FreeIPA that is wrong. On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" < bruno-barb...@prodesan.com.br> wrote: > Hello everyone, > > I'm running through an issue where an application needs its server's > hostname to be in short name format, such as "server" and not " > server.example.com". When I started deploying FreeIPA in the very > beginning of this year, I remember I couldn't install freeipa-client with a > bare "ipa-client install", because of this: > > > > [root@server ~]# hostname > server > [root@server ~]# hostname -f > server.example.com > [root@server ~]# ipa-client-install > Discovery was successful! > Hostname: server.example.com > Realm: EXAMPLE.COM > DNS Domain: example.com > IPA Server: ipa01.example.com > Base DN: dc=example,dc=com > > Continue to configure the system with these values? [no] yes > User authorized to enroll computers: admin > Synchronizing time with KDC... > Unable to sync time with IPA NTP Server, assuming the time is in sync. > Please check that port 123 UDP is opened. > Password for ad...@example.com: > Joining realm failed: The hostname must be fully-qualified: server > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > > > So, using the short name as hostname didn't work for install, I then make > it like "ipa-client install --hostname=`hostname -f` --mkhomedir -N", and > it installs and works like a charm, BUT it updates the machine's hostname > to FQDN. > > What I tested and, at first, worked: after deploying and ipa-client > installation with those parameters which work, renaming the machine back to > a short name AT FIRST is not causing any problems. I can login with my ssh > rules perfectly, but I don't find any IPA technical docs saying it > will/won't work if I change the hostname back to short name and not FQDN. > > Searching for it, I found on RedHat guide: "The hostname of a system is > critical for the correct operation of Kerberos and SSL. Both of these > security mechanisms rely on the hostname to ensure that communication is > occurring between the specified hosts." > I've also found this message > http://osdir.com/ml/freeipa-users/2012-03/msg6.html which seems to be > related to my case, but what I need to know is: where does it state FQDN is > a mandatory requirement in order to FreeIPA to work and/or is there > anything else (a patch, update, whatever) to solve this issue, so I don't > need to change my applications? > > Thank you and sorry for the wall of a text. > > PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is not > the same server as IPA (it forwards to a Windows DC). > > RPMs: > libipa_hbac-1.9.2-129.el6_5.4.x86_64 > libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 > python-iniparse-0.3.1-2.1.el6.noarch > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-admintools-3.0.0-37.el6.x86_64 > ipa-server-selinux-3.0.0-37.el6.x86_64 > ipa-server-3.0.0-37.el6.x86_64 > ipa-python-3.0.0-37.el6.x86_64 > ipa-client-3.0.0-37.el6.x86_64 > > > > -- > 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] Setting up IPA to log remotely
On Tue, 2014-06-03 at 00:42 +, Steven Jones wrote: > Hi, > > I'll raise a request for this to be added then. > > Its a bit of an enterprise requirement feature that is of use for us. > > Not having much luck with rsyslog and application logs at the moment, good > and accurate docs seem lacking for RHEL6. > > regards > > Steven > > From: Rob Crittenden > Sent: Tuesday, 3 June 2014 9:27 a.m. > To: Steven Jones > Cc: freeipa-users@redhat.com > Subject: Re: [Freeipa-users] Setting up IPA to log remotely > > Steven Jones wrote: > > Is there a way to get IPA to send its logs remotely? > > We intend to do something like this with audit, most likely using the > systemd journal, but it's a ways off. > > For now you'd need to do it manually on a per-service basis. I'd suggest > looking at rsyslogd. You should be able to at least get the Apache and > 389-ds logs using that. > > rob > > > > ___ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users check out http://www.rsyslog.com/doc/master/index.html for good and accurate docs. i am using fedora 16 and 20 with RELP, fowarding syslog from everywhere to a central location, and then dumping the logs into mysql. phplogcon bolts on top of it for a web view of all the logs. on a sending source: $ModLoad imuxsock # provides support for local system logging (e.g. via logger command) $SystemLogRateLimitInterval 0 $IMUXSockRateLimitInterval 0 $ModLoad imklog # provides kernel logging support (previously done by rklogd) #$ModLoad immark # provides --MARK-- message capability # Provides UDP syslog reception $ModLoad imudp $UDPServerRun 514 # Provides TCP syslog reception $ModLoad imtcp $InputTCPServerRun 514 # Provides RELP transmission $ModLoad omrelp *.* :omrelp:192.168.25.1:20514;RSYSLOG_ForwardFormat &~ on a receiving destination: $ModLoad imuxsock # provides support for local system logging (e.g. via logger command) $SystemLogRateLimitInterval 0 $IMUXSockRateLimitInterval 0 $ModLoad imklog # provides kernel logging support (previously done by rklogd) #$ModLoad immark # provides --MARK-- message capability # Provides UDP syslog reception $ModLoad imudp $UDPServerRun 514 # Provides TCP syslog reception $ModLoad imtcp $InputTCPServerRun 514 # Provides RELP reception $ModLoad imrelp $InputRELPServerRun 20514 # Provides MySQL connectivity $ModLoad ommysql # MASSIVE INSERT RATE FOR DB / SCALED DB LOGGING $WorkDirectory /var/spool/rsyslog # default location for work (spool) files $ActionQueueType LinkedList # use asynchronous processing $ActionQueueFileName dbq# set file name, also enables disk mode $ActionResumeRetryCount -1 # infinite retries on insert failure # for PostgreSQL replace :ommysql: by :ompgsql: below: *.* :ommysql:server.domain.tld,Syslog,user,password ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] DDNS with DHCPD and IPA
Dont allow clients to ddns update. Force the update to occur from dhcpd to named On Apr 3, 2014 1:53 PM, "Simo Sorce" wrote: On Thu, 2014-04-03 at 10:38 -0700, Andy Tomlin wrote: > I posted this on the DHCP mailing list, but think it may belong here > instead. > > > > I am running Centos 6.5 and have installed ipa to allow all our linux > machines to authenticate. We have windows machines that get their ip address > from server and since installing ipa the ddns no longer works. Googling > around does not show much help. The key files match. There is a bug in kerberos libraries that prevent Windows clients from successfully performing DDNS against BIND servers that we fixed only recently. This is the fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1066000 Not sure if this has been backported to RHEL/CentOS tbh. This is for Windows clients directly performing DDNS updates using GSS-TSIG. -- Now reading the following lines it seem you are mixing GSS-TSIG and plain TSIG, well you can't do that. ATM I think we accept only GSS-TSIG updates in IPA, while BIND DHCP seem to be capable only of TSIG updates. CCing Petr as he may have some ideas on whether this is something we can work around. Simo. > > > My named.conf is as follows: > > > > [root@alfred ~]# cat /etc/named.conf > > options { > > // turns on IPv6 for port 53, IPv4 is on by default for all ifaces > > listen-on-v6 {any;}; > > listen-on port 53 { 127.0.0.1; 10.0.1.2; }; > > > > // Put files that named is allowed to write in the data/ directory: > > directory "/var/named"; // the default > > dump-file "data/cache_dump.db"; > > statistics-file "data/named_stats.txt"; > > memstatistics-file "data/named_mem_stats.txt"; > > > > //forward first; > > //forwarders { > > // 192.168.1.254; > > // 8.8.8.8; > > //}; > > > > // Any host is permitted to issue recursive queries > > allow-recursion { any; }; > > > > tkey-gssapi-credential "DNS/alfred.xxx.com"; > > tkey-domain "xxx.COM"; > > }; > > > > include "/etc/named/ddns.key"; > > > > /* If you want to enable debugging, eg. using the 'rndc trace' command, > > * By default, SELinux policy does not allow named to modify the /var/named > directory, > > * so put the default debug log file in data/ : > > */ > > logging { > > channel default_debug { > > file "data/named.run"; > > severity dynamic; > > }; > > }; > > > > zone "." IN { > > type hint; > > file "named.ca"; > > }; > > > > include "/etc/named.rfc1912.zones"; > > > > dynamic-db "ipa" { > > library "ldap.so"; > > arg "uri ldapi://%2fvar%2frun%2fslapd-xxx-COM.socket"; > > arg "base cn=dns, dc=xxx,dc=com"; > > arg "fake_mname alfred.xxx.com."; > > arg "auth_method sasl"; > > arg "sasl_mech GSSAPI"; > > arg "sasl_user DNS/alfred.xxx.com"; > > arg "zone_refresh 0"; > > arg "psearch yes"; > > arg "serial_autoincrement yes"; > > }; > > > > My dhcpd.conf is as follows: > > [root@alfred ~]# cat /etc/dhcp/dhcpd.conf > > # dhcpd.conf > > # > > # Sample configuration file for ISC dhcpd > > # > > > > # option definitions common to all supported networks... > > option domain-name "xxx.com"; > > option domain-name-servers 10.0.1.2, 8.8.8.8, 8.8.4.4; > > > > ddns-updates on; > > ddns-update-style interim; > > ignore client-updates; > > update-static-leases on; > > > > default-lease-time 600; > > max-lease-time 7200; > > > > # Use this to enble / disable dynamic dns updates globally. > > #ddns-update-style none; > > > > # If this DHCP server is the official DHCP server for the local > > # network, the authoritative directive should be uncommented. > > authoritative; > > > > # Use this to send dhcp log messages to a different log file (you also > > # have to hack syslog.conf to complete the redirection). > > log-facility local7; > > > > # No service will be given on this subnet, but declaring it helps the > > # DHCP server to understand the network topology. > > > > #subnet 10.152.187.0 netmask 255.255.255.0 { > > #} > > > > include "/etc/dhcp/ddns.key"; > > > > zone xxx.com. { > > primary 127.0.0.1; > > key DDNS_UPDATE; > > } > > > > zone 2.0.10.in-addr.arpa. { > > primary 127.0.0.1; > > key DDNS_UPDATE; > > } > > > > # This is a very basic subnet declaration. > > > > subnet 10.0.0.0 netmask 255.255.0.0 { > > range 10.0.2.50 10.0.2.250; > > option routers 10.0.1.2; > > } > > > > [root@alfred ~]# > > > > When windows client gets a dhcp address, the following is in the log > > > > [root@alfred ~]# tail -n50 /var/log/messages > > Apr 2 19:40:50 alfred named[8491]: client 127.0.0.1#59786: updating zone > 'xxx.com/IN': update failed: rejected by secure update (REFUSED) > > Apr 2 19:40:50 alfred dh
Re: [Freeipa-users] bind-dyndb-ldap: using keytabs for auth to ldap
> No, it is not. > http://port389.org/wiki/History ok then. still, i am trying to learn the individual pieces and get them working together. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] bind-dyndb-ldap: using keytabs for auth to ldap
> Hello! > Before I dive into details, please read about the following bug: > https://fedorahosted.org/bind-dyndb-ldap/ticket/134 > > I just found it, fixed it and I'm attaching patch for you so you don't need > to > wait for a new release :-) thanks, but i am not sure how to apply patches. > Your LDAP server will get the whole principal and it is up to the server how > it will map it to some existing entity. what do you do on the IPA side? did you follow some best practice? i am trying not to reinvent the wheel. > BTW documentation about named.conf syntax is in README: > https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/plain/README as well as in the package. i did consult the doc. > Let us know if you encounter any problem. certainly will. > BTW did you see FreeIPA project? It integrates LDAP+Kerberos with management > tools and nice user interface and solver Microsoft AD integration. > > Maybe it could save you some headaches ... not a big fan of 389, as it is a fork of openldap, though RH has done some nifty things with it (dogtag, IPA, etc). i am a bit of a purist, thats all. also, this is a learning exercise for me. i am trying to understand the inner workings of each of the pieces and see how they interoperate with each other. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] using keytabs for auth to ldap
What distribution you use? Fedora Which distribution version you use? Fedora 20, with latest updates Which architecture you use? x86_64 on a qemu VM What plugin version you use? bind-dyndb-ldap-4.1-1.fc20.x86_64 Do you use bind-dyndb-ldap as part of FreeIPA installation? no, using openldap-servers-2.4.39-2.fc20.x86_64 Which version of BIND you use? bind-9.9.4-12.P2.fc20.x86_64 Please provide dynamic-db section from configuration file /etc/named.conf dynamic-db "bpk2.com" { library "ldap.so"; arg "uri ldap://127.0.0.1/";; arg "base cn=dns,dc=bpk2,dc=com"; arg "auth_method simple"; arg "bind_dn cn=Manager,dc=bpk2,dc=com"; arg "password ***REMOVED***"; arg "sync_ptr yes"; arg "dyn_update yes"; arg "connections 2"; arg "verbose_checks yes"; }; Do you have some other text based or DLZ zones configured? no Do you have some global forwarders configured in BIND configuration file? no Do you have some settings in global configuration object in LDAP? dn: cn=dns,dc=my-domain,dc=com cn: dns idnspersistentsearch: FALSE idnszonerefresh: 30 objectclass: top objectclass: nsContainer objectclass: idnsConfigObject i want to use bind-dyndb-ldap with keytabs against my directory. i have created the principal DNS/test.bpk2@bpk2.com, and can have created the keytab file. what i want to know is: what ldap object should i create to match up against the kerberos principal? i have to grant access to the ldap tree, so what ID will be presented to ldap when using the keytab? am i able to use the sasl_username without the sasl_password to establish that? being that i want to use a keytab, the username would be in there, correct? when i list the keys in the keytab, there is a PRIMARY, an INSTANCE and a REALM (DNS/test.bpk2@bpk2.com). is the PRIMARY (DNS) or the INSTANCE (test.bpk2.com) what has to be linked in ldap to the kerberos identity? do i need a specific olcAuthzRegexp to massage the kerberos ID into a proper ldap DN, like i am doing already for my ID? example: {0}uid=([^,]*),cn=bpk2.com,cn=gssapi,cn=auth uid= $1,ou=Users,dc=bpk2,dc=com i am running n-way multi master ldap. does the uri directive support more than one value (ldap://ldap1.bpk2.com ldap://ldap2.bpk2.com)? can the SRV records be used to point the uri directive at the ldap servers by querying for them? ha, thats a-chicken-and-the-egg topic, but an interesting one... i am assuming my named.conf will change to include: arg "uri ldap://ldap1.bpk2.com/ ldap://ldap2.bpk2.com";; arg "auth_method sasl"; arg "sasl_mech GSSAPI"; arg "krb5_keytab FILE:/etc/named.keytab"; is there anything else obvious that i am missing? thank you, brendan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] bind-dyndb-ldap 4.1 upgrade
On Tue, 2014-03-04 at 14:11 +0100, Petr Spacek wrote: > Hello, > > On 3.3.2014 22:57, Brendan Kearney wrote: > > Which distribution version you use? Fedora 20, with latest updates > > What plugin version you use? bind-dyndb-ldap-3.5-1.fc20.x86_64 > > Please make sure that you read and follow > https://www.redhat.com/archives/freeipa-interest/2014-February/msg1.html > before you upgrade bind-dyndb-ldap to version 4.x. > > The bind-dyndb-ldap 4.1 is being pushed to Fedora-updates repo right now. > > I will comment on your configuration in-line: > > Do you use bind-dyndb-ldap as part of FreeIPA installation? no, using > > openldap-servers-2.4.39-2.fc20.x86_64 > Please make sure that syncrepl provider is configured on your LDAP server. > Syncrepl support on server side is *required* from version 4.0. > > > Please provide dynamic-db section from configuration > > file /etc/named.conf > > dynamic-db "my-domain.com" { > > library "ldap.so"; > > arg "uri ldap://127.0.0.1/";; > > arg "base cn=dns,dc=my-domain,dc=com"; > > arg "auth_method simple"; > > arg "bind_dn cn=Manager,dc=my-domain,dc=com"; > > arg "password *"; > > arg "psearch no"; > This option was removed (replaced by mandatory syncrepl). > > > // arg "serial_autoincrement yes"; > This feature is now mandatory so the option was removed. Please make sure > that > bind-dyndb-ldap has write access to the configured sub-tree. > > > arg "sync_ptr yes"; > > arg "dyn_update yes"; > > arg "connections 2"; > > arg "cache_ttl 300"; > This option was removed (replaced by mandatory syncrepl). > > > arg "verbose_checks yes"; > > }; > > I hope this helps to prevent surprise after upgrade. > > Let us know if you encounter any problems! > syncrepl is configured and i am using it for N-Way Multi Master Replication between 2 hosts. are there specific configs i need to add/change for the bind-dyndb-ldap piece? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] best practices for subdomains
On Mon, 2014-03-03 at 09:33 +0100, Petr Spacek wrote: > On 1.3.2014 23:20, Brendan Kearney wrote: > > i am using bind-dyndb-ldap outside of freeipa, and want to create > > _tcp.my-domain.com and _udp.my-domain.com subdomains. i have tried, but > > seem to come up short and nslookup fails for the records i try to create > > in the subdomains. some googling and searching in the wiki have not > > provided me with much go on. below is an attempt at _tcp.my-domain.com > > > > dn: idnsName=_tcp.my-domain.com.,cn=dns,dc=my-domain,dc=com > > dnsttl: 3600 > > idnsallowdynupdate: FALSE > > idnsallowsyncptr: FALSE > > idnsname: _tcp.my-domain.com. > > idnssoaexpire: 604800 > > idnssoaminimum: 86400 > > idnssoamname: server.my-domain.com. > > idnssoarefresh: 10800 > > idnssoaretry: 900 > > idnssoarname: root.server.my-domain.com. > > idnssoaserial: 1 > > idnsupdatepolicy: grant MY-DOMAIN.COM krb5-self * A; > > idnszoneactive: TRUE > > nsrecord: server.my-domain.com. > > objectclass: top > > objectclass: idnsZone > > objectclass: idnsRecord > > > > what is the correct way to create a subdomain? > > First of all, do you really want to create *subdomains* for _tcp and _udp or > do you just need to create couple records like _ldap._tcp in a existing > domain? It is very unusual to create separate subdomains for _tcp and _udp. > > I'm attaching small snippet which shows how to add _ldap._tcp SRV record to > existing domain ipa.example. > > Please be so kind and send us information mentioned on > https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting#a3.Whatweneedtoknow > > We would like to know how users use bind-dyndb-ldap, which LDAP server is > used > outside FreeIPA and so on. > > Have a nice day! > > ___ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users What distribution you use? Fedora Which distribution version you use? Fedora 20, with latest updates Which architecture you use? x86_64 on a qemu VM What plugin version you use? bind-dyndb-ldap-3.5-1.fc20.x86_64 Do you use bind-dyndb-ldap as part of FreeIPA installation? no, using openldap-servers-2.4.39-2.fc20.x86_64 Which version of BIND you use? bind-9.9.4-11.P2.fc20.x86_64 Please provide dynamic-db section from configuration file /etc/named.conf dynamic-db "my-domain.com" { library "ldap.so"; arg "uri ldap://127.0.0.1/";; arg "base cn=dns,dc=my-domain,dc=com"; arg "auth_method simple"; arg "bind_dn cn=Manager,dc=my-domain,dc=com"; arg "password *"; arg "psearch no"; // arg "serial_autoincrement yes"; arg "sync_ptr yes"; arg "dyn_update yes"; arg "connections 2"; arg "cache_ttl 300"; arg "verbose_checks yes"; }; Do you have some other text based or DLZ zones configured? no Do you have some global forwarders configured in BIND configuration file? no Do you have some settings in global configuration object in LDAP? dn: cn=dns,dc=my-domain,dc=com cn: dns idnspersistentsearch: FALSE idnszonerefresh: 30 objectclass: top objectclass: nsContainer objectclass: idnsConfigObject without a doubt i want to use subdomains (or subzones, if that the correct term) for _tcp and _udp. kerberos, kerberos-adm, kerberos-master, kpasswd, ldap, nfs4, wpad and ntp are the SRV records i want to manage, and having them in the regular forward zone is not as clean, neat and organized as i want to be. also, i may want to have forward subdomains (sub.my-domain.com, for example, with testhost.sub.my-domain.com as an A record). the example included in the package did have a similar example on how to put a SRV into the zone, but again, i want to manage those records with a subdomain (or subzone, if that is the correct term). ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] best practices for subdomains
i am using bind-dyndb-ldap outside of freeipa, and want to create _tcp.my-domain.com and _udp.my-domain.com subdomains. i have tried, but seem to come up short and nslookup fails for the records i try to create in the subdomains. some googling and searching in the wiki have not provided me with much go on. below is an attempt at _tcp.my-domain.com dn: idnsName=_tcp.my-domain.com.,cn=dns,dc=my-domain,dc=com dnsttl: 3600 idnsallowdynupdate: FALSE idnsallowsyncptr: FALSE idnsname: _tcp.my-domain.com. idnssoaexpire: 604800 idnssoaminimum: 86400 idnssoamname: server.my-domain.com. idnssoarefresh: 10800 idnssoaretry: 900 idnssoarname: root.server.my-domain.com. idnssoaserial: 1 idnsupdatepolicy: grant MY-DOMAIN.COM krb5-self * A; idnszoneactive: TRUE nsrecord: server.my-domain.com. objectclass: top objectclass: idnsZone objectclass: idnsRecord what is the correct way to create a subdomain? thank you, brendan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap
> Do you plan to use FreeIPA command line interface or not? > > With FreeIPA, you can create equivalent records with this set of commands: > $ ipa dnszone-add bpk2.com > $ ipa dnsrecord-add bpk2.com _kerberos --txt-rec=... > etc. > > Those commands allow you to create almost equivalent data in LDAP. This > doesn't work for you? > > Please note that dnsrecord-add command contains zone name (as the first > argument), so the FQDN can be constructed from the first and second argument. i am using bind-dyndb-ldap without FreeIPA, or 389. It is on Fedora, with OpenLDAP and a bunch of steps to get it working. i am using phpLdapAdmin to administrate the ldap instance and have created the needed configs in ldap, using the existing sample ldif as a guide. > > DNS zone is represented by LDAP object which contains all other named in the > zone: > idnsname=bkp2.com,cn=dns,dc=ipa,dc=test > > Each name inside particular zone is represented by own LDAP object: > idnsname=_kerberos, idnsname=bkp2.com,cn=dns,dc=ipa,dc=test > > As a result, FQDN can be constructed for each relative name in the zone > simply > by concatenating second and first idnsname components. > > Is it now clearer why bind-dyndb-ldap don't have equivalent of $ORIGIN? no. you say that the FQDN can be constructed by stinging together 2 of the values in the DN, but neither bind, nor the bind-dyndb-ldap "plug-in" are doing that. > > attached is my forward zone (frozen before copying data, so that the jnl > > entries were written out). > > > > the desired outcome is to have zones configured so that unqualified > > queries are looked up locally and return properly, if appropriate, > > before being forwarded to any forwarders or via the hints to the roots > > or whatever is configured to be done with a record that does not have a > > locally authoritative entry. > > AFAIK 'unqualified' names are purely client-side thing. I belive that all > names have to be expanded to FQDN *before* the query is sent to any DNS > server. (See search directive in /etc/resolv.conf.) > and there are no conceivable scenarios where an unqualified query could ever get to the bind server? regardless of opinions on how frequent/infrequent it could happen, the fact is that this is an entirely legitimate scenario that improperly fails with an error. > > while zytrax does have good articles, the reference i provided is > > directly out of the bind admin guide, and likely a more authoritative > > voice on the subject. > > I agree. Please note that both sources say the same information, just in > other > words. > > > i have validated that when no $ORIGIN directive is set, a query using > > the short name will fail when looked up locally, and will either be > > forwarded or recursively searched for. the examples i provided go > > against bind+bind-dyndb-ldap, and the short name query fails. doing the > > same lookups against my straight bind instance, using the attached zone > > file, gives authoritative responses for both short and FQDN queries. > > I belive that your zone file will be perfectly functional if you remove > origin > completely. You will have to replace name for SOA record. it does not matter what will or will not work with my zones. what i am trying to account for is lookups failing against bind when using the bind-dyndb-ldap backend and a short name is specified. since the $ORIGIN directive is written into RFC, why is it electively being dropped, resulting in a broken implementation because of the lack of compliance? > $ diff -u bpk2.com.db.orig bpk2.com.db.noorigin > --- bpk2.com.db.orig 2013-10-23 09:09:47.568113243 +0200 > +++ bpk2.com.db.noorigin 2013-10-23 09:10:09.347112464 +0200 > @@ -1,6 +1,5 @@ > -$ORIGIN . > $TTL 3600 ; 1 hour > -bpk2.com IN SOA server.bpk2.com. root.server.bpk2.com. ( > +@IN SOA server.bpk2.com. root.server.bpk2.com. ( > 21684 ; serial > 10800 ; refresh (3 hours) > 3600 ; retry (1 hour) > @@ -9,7 +8,6 @@ > ) > NS vpn.bpk2.com. > NS server.bpk2.com. > -$ORIGIN bpk2.com. > $TTL 600; 10 minutes > _kerberos TXT "BPK2.COM" > $TTL 5 ; 5 seconds > > > I assume that your zone definition in named.conf looks like: > zone "bpk2.com." IN { > type master; > file "bpk2.com.db"; > }; > > As a result, default origin "bpk2.com." is appended to all names in zone file > - and that is it. > > Do not forget to bump serial and check server logs if the new zone file was > loaded correctly ... > > Have a nice day! > ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap
my config uses bind and bind-dyndb-ldap to host zone data in ldap. i am trying to achieve the equivalent directives and configuration of bind +bind-dyndb-ldap that i have in straight bind. attached is my forward zone (frozen before copying data, so that the jnl entries were written out). the desired outcome is to have zones configured so that unqualified queries are looked up locally and return properly, if appropriate, before being forwarded to any forwarders or via the hints to the roots or whatever is configured to be done with a record that does not have a locally authoritative entry. while zytrax does have good articles, the reference i provided is directly out of the bind admin guide, and likely a more authoritative voice on the subject. i have validated that when no $ORIGIN directive is set, a query using the short name will fail when looked up locally, and will either be forwarded or recursively searched for. the examples i provided go against bind+bind-dyndb-ldap, and the short name query fails. doing the same lookups against my straight bind instance, using the attached zone file, gives authoritative responses for both short and FQDN queries. $ORIGIN . $TTL 3600 ; 1 hour bpk2.comIN SOA server.bpk2.com. root.server.bpk2.com. ( 21684 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 3600 ; minimum (1 hour) ) NS vpn.bpk2.com. NS server.bpk2.com. $ORIGIN bpk2.com. $TTL 600; 10 minutes _kerberos TXT "BPK2.COM" $TTL 5 ; 5 seconds cache A 192.168.25.1 A 192.168.50.1 ceton A 192.168.200.1 $TTL 3600 ; 1 hour desktop A 192.168.1.60 $TTL 1800 ; 30 minutes TXT "004f797684e9ec50c37966ab6377f6e5c6" $TTL 3600 ; 1 hour dhcp01 CNAME server dhcp02 CNAME vpn edge1037A 192.168.3.1 TXT "31f8a6da151fb3fc048a6e3dbcd4099896" HP001560497B44 CNAME printer inspire A 192.168.2.145 $TTL 1800 ; 30 minutes TXT "3105220f898df9aa1cecba75583223a0e2" $TTL 3600 ; 1 hour iphone A 192.168.2.146 TXT "318d91a7366c7a0cbd8ac4a8cf5f11f2f8" ipsec A 192.168.52.1 $TTL 600; 10 minutes kerberosA 192.168.25.1 A 192.168.50.1 $TTL 3600 ; 1 hour laptop A 192.168.1.139 $TTL 1800 ; 30 minutes TXT "002a031452f258ef236a2463b272372ad6" $TTL 3600 ; 1 hour ldapA 192.168.37.3 ldap-master CNAME server ldap1 CNAME server ldap2 CNAME vpn modem A 192.168.100.1 music CNAME desktop ncsiCNAME server ns01CNAME vpn ns02CNAME server ntp CNAME vpn printer A 192.168.1.3 TXT "316f7731238b38ada102f07b426eb98a95" $TTL 600; 10 minutes proxy A 192.168.37.1 proxy1 CNAME server proxy2 CNAME vpn router CNAME router-vlan254 $TTL 3600 ; 1 hour router-ipmi A 192.168.253.3 $TTL 600; 10 minutes router-vlan1A 192.168.1.254 router-vlan2A 192.168.2.254 router-vlan25 A 192.168.25.254 router-vlan253 A 192.168.253.254 router-vlan254 A 192.168.254.254 router-vlan3A 192.168.3.254 router-vlan37 A 192.168.37.254 router-vlan50 A 192.168.50.254 router-vlan52 A 192.168.52.254 server A 192.168.25.1 server-ipmi A 192.168.253.1 server-old A 192.168.1.1 switch A 192.168.254.253 wpad.tcpTXT "service: wpad:!http://www.bpk2.com:80/wpad.dat"; SRV 0 0 80 server $TTL 3600 ; 1 hour testA 192.168.1.169 $TTL 1800 ; 30 minutes TXT "00b6f6a38a5caaab7be5bdc35d2d3e7acc" $TTL 600; 10 minutes tproxy CNAME server vpn A 192.168.50.1 vpn-ipmiA 192.168.253.2 wifi-g A 192.168.1.253 wifi-guest A 192.168.3.253 wifi-n
[Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap
list, i am trying to setup BIND to use the DynDB LDAP backend, and have found that the $ORIGIN directive is not used or documented for use with the backend. the use case is the for the $ORIGIN directive is to handle unqualified queries. Below is an example of what happens without the $ORIGIN directive set in a zone: [brendan@test ~]$ nslookup server 127.0.0.1 Server: 127.0.0.1 Address: 127.0.0.1#53 ** server can't find server: SERVFAIL [brendan@test ~]$ nslookup server.my-domain.com 127.0.0.1 Server: 127.0.0.1 Address: 127.0.0.1#53 Name: server.my-domain.com Address: 192.168.1.1 the below is the BIND Admin Reference Manual entry for the $ORIGIN directive. The $ORIGIN Directive Syntax: $ORIGIN domain-name [comment] $ORIGIN sets the domain name that will be appended to any unqualified records. When a zone is first read in there is an implicit $ORIGIN . (followed by trailing dot). The current $ORIGIN is appended to the domain specified in the $ORIGIN argument if it is not absolute. $ORIGIN example.com. WWW CNAME MAIN-SERVER is equivalent to WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM. would a Request For Enhancement be needed or should a bug be filed for this missing functionality? thank you, brendan kearney ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users