* From: Magnus Hagander [mailto:mag...@hagander.net]
> I took a quick look at this one, and have some initial thoughts. > > I don't like the name "real_realm" as a parameter name. I'm wondering if > it might be better to reverse the meaning, and call it sspi_netbios_realm > (and then change the default to on, to be backwards compatible). What about "compat_realm" instead? "sspi_netbios_realm" is a bit long. Also, the domain short name is not really a realm name, and this would feel like implying that it is. > How does the real_realm thing work if you connect with a local account? > Hostname, or kerberos principal for the host? It fails. There is no UPN with a local account, so the conversion does not happen, and I thought it would be best from a security POV to let the logon fail rather than inventing a reason why it should succeed. > Code uses a mix of malloc() and palloc() (through sprintf). Is there a > reason for that? I wasn't sure which to prefer, so I looked around in auth.c, and other than RADIUS, everything seems to use malloc() (although the sample size is not too great). Should I use palloc() instead? > Looking at the docs: > > + Note that <application>libpq</> uses the SAM-compatible name if > no > + explicit user name is specified. If you use > + <application>libpq</> (e.g. through the ODBC driver), you should > + leave this option disabled. > > What's the actual usecase where it makes sense to change it? Seems that's > the more reasonable thing to document, with a reference to active > directory specifically (or is there also such a compatible name for local > accounts?) In an environment where sAMAccountName and userPrincipalName are different, it might be preferable to have something to map in pg_ident.conf that is actually a valid user name (UPN, in this case), rather than a mixture of both forms that isn't valid for either. Also, since I already have the UPN, adding the option is basically free and feels more useful than always throwing away half the information. Another thing: This business of getting a SID, turning it into a user name/domain pair, then using that to get the UPN (which probably involves converting it to the SID again somewhere in between) does not look very good to me. I'll have to see if it works, but what do you think about briefly impersonating the client, just long enough to get the SAM and UPN names? -- Christian -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
