Re: [OmniOS-discuss] Backup CIFS Server

[Michael Rasmussen]

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=0xD3C9A00E
mir  datanom  net
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE501F51C
mir  miras  org
http://pgp.mit.edu:11371/pks/lookup?op=get=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] Backup CIFS Server

[Dale Ghent]

> 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

[OmniOS-discuss] Backup CIFS Server

[Steven Ford]

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