[OmniOS-discuss] Backup CIFS Server
Hello, I have two Omnios storage servers, a primary and a backup. Users authenticate via Active Directory. Since updating to r151018, kerberos seems to be a little pickier when allowing clients to connect. Before, if my secondary took over the primary's IP, connections made with the primary's domain name to the secondary came through fine. Now, they are rejected with the following error: smbd: krb5ssp: gss_accept_sec_context, mech=0xfcaa0160, major=0x7, minor=0x25ea101 smbd: krb5: No principal in keytab matches desired name Rejecting requests addressed to domain names that are not its own seems like the proper thing to do, so I'm curious if anybody else is using Omnios as a backup server meant to operate in the primary's place. Should I somehow configure them to have the same kerberos keys? Is there a way to dumb down kerberos to behave like it used to? Would it be a bad idea to dumb down kerberos in this way? Any input is greatly appreciated. Thank you, Steve ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Backup CIFS Server
> On May 31, 2016, at 11:33 AM, Steven Ford wrote: > > Hello, > > I have two Omnios storage servers, a primary and a backup. Users authenticate > via Active Directory. > > Since updating to r151018, kerberos seems to be a little pickier when > allowing clients to connect. Before, if my secondary took over the primary's > IP, connections made with the primary's domain name to the secondary came > through fine. Now, they are rejected with the following error: > > smbd: krb5ssp: gss_accept_sec_context, mech=0xfcaa0160, major=0x7, > minor=0x25ea101 > smbd: krb5: No principal in keytab matches desired name > > Rejecting requests addressed to domain names that are not its own seems like > the proper thing to do, so I'm curious if anybody else is using Omnios as a > backup server meant to operate in the primary's place. > > Should I somehow configure them to have the same kerberos keys? Is there a > way to dumb down kerberos to behave like it used to? Would it be a bad idea > to dumb down kerberos in this way? Generally, yes, both servers should probably have identical keytabs which contain each other's specific principals, since one is expected to act like the other at some point (ie, in a failover scenario) ... if I'm understanding your situation correctly. /dale signature.asc Description: Message signed with OpenPGP using GPGMail ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] LSI3108
I have worked with the 20.00.04.00 and it has worked very well. But the 07 has had problems. All on freebsd or freenas. Haven't tested with omni. If anyone has the sata 6gb firmware sitting around version 20.00.04.00 would love to get my hands on it linda On 5/23/16 3:50 PM, Eric Sproul wrote: On Mon, May 23, 2016 at 4:18 PM, Dan McDonald wrote: And if you do, make sure it's version 19 or lower. The IT firmware > 19 is known to be flaky. Check the illumos list archives for details on why. We may want to revisit that advice-- I've noticed that LSI/Avago have revised v20 firmware several times, presumably to fix bugs. Their support downloads currently show "20.00.07.00" available for download. I haven't had a chance to try that one yet, but I do have some dev systems running 20.00.04.00 without any apparent issues. These are direct-attach configurations, i.e. no expanders. Eric ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Backup CIFS Server
On Tue, 31 May 2016 11:33:22 -0400 Steven Ford wrote: > > Should I somehow configure them to have the same kerberos keys? Is there a > way to dumb down kerberos to behave like it used to? Would it be a bad idea > to dumb down kerberos in this way? > On windows you use ktpass.exe to generate keytab files: https://technet.microsoft.com/en-us/library/cc753771(v=ws.11).aspx Check parameter /out On Unix like systems the command is ktutil: http://web.mit.edu/kerberos/krb5-1.12/doc/admin/admin_commands/ktutil.html The generated keytab file can be distributed to any number of hosts and enables the beholder of the keytab to create a security context with the AD without username and password either as a client or a server so you should keep safe. Typical client use: To get a service token (identify and authorize) to a server/service. Typical server use: To verify and validate service tokens from clients. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -- /usr/games/fortune -es says: There are only two kinds of tequila. Good and better. pgpywYP3jZU2J.pgp Description: OpenPGP digital signature ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] cifs connectivity to DC gets lost
On 16-05-30 07:24 PM, Gordon Ross wrote: On Tue, May 24, 2016 at 6:52 PM, Geoff Nordli wrote: On 16-05-24 03:41 PM, Geoff Nordli wrote: I just upgraded a server from OI to OmniOS-r151018. I am having a few issues with the connectivity to AD. I was able to join the domain no problem, but then the domain is getting disconnected and after several hours I need to join the domain again. May 24 15:25:12 stor1 idmap[472]: [ID 849457 daemon.error] > :::172.16.100.10 rc=0 May 24 15:25:12 stor1 idmap[472]: [ID 778215 daemon.error] DC name dc1.domain.ca != 172.16.100.10? May 24 15:25:12 stor1 idmap[472]: [ID 884951 daemon.notice] Configuration changed May 24 15:25:12 stor1 idmap[472]: [ID 452651 daemon.error] adutils: ldap_lookup_init failed May 24 15:25:12 stor1 idmap[472]: [ID 884951 daemon.notice] Configuration changed May 24 15:25:13 stor1 smbd[15085]: [ID 511178 daemon.notice] Failed to establish NETLOGON credential chain with DC: 172.16.100.10 (UNSUCCESSFUL) May 24 15:25:13 stor1 smbd[15085]: [ID 714496 daemon.notice] The machine account information on the domain controller does not match the local storage. May 24 15:25:13 stor1 smbd[15085]: [ID 777225 daemon.notice] To correct this, use 'smbadm join' May 24 15:25:13 stor1 smbd[15085]: [ID 527292 daemon.notice] failed to establish NETLOGON credential chain May 24 15:25:13 stor1 smbd[15085]: [ID 505820 daemon.notice] with server 172.16.100.10 for domain domain.ca (UNSUCCESSFUL) time is synced between the two machines. When I issue the join, I am able to get things connected again. any thoughts? Pulled from the idmap log: adutils: ldap_lookup_init, host 172.16.100.10 LDAP: 172.16.100.10:3268: Local error 172.16.100.10: Local error 172.16.100.10: additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database) adutils: ldap_lookup_init failed unable to discover Domains in the Forest You figured it out. Kerberos can only authenticate with a named host, and the log message above say that idmap/libadutils is trying to use ldap+gssapi+kerberos to authenticate with a DC specified only by IP address. That's never going to work... Good to know. That must have gotten set somewhere when I was trying different things. Right now the: kpasswd_server is set to a host name. pdc is set to an IP address. This configuration seems to be working OK. thanks, Geoff ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss