John Giltner writes: >In addition to politics you may also run into password >length problems. Our distributed guys want 16 character >passwords at a minimum. They feel that 6 characters is >too short (our current RACF minumum), even with a 4 tries >and your revoked.
RACF (and the z/OS LDAP Server) have supported long passphrases for quite some time now, though (since 1.8 at least). And z/OS 1.10 probably closes any remaining gaps (such as passphrase support for TSO/E logon if you need that). So I don't think this is a problem any more. To the original poster.... If you can get everything using the z/OS LDAP Server, that's wonderful and neatly solves the problem. Well worth doing as much as you can. (Let's call that "directory consolidation.") The reality is that a lot of companies are going to have more than one authentication/authorization repository in their organization, unfortunately. Now, there are several ways to address this, and you might apply more than one weapon. In no particular order here are some solution categories: 0. Directory consolidation (as mentioned). Just point everything to the z/OS LDAP Server, basically. IBM did a lot of directory consolidation internally, and it's worked very well for us. (It's not 100%, but it's a very high percentage.) 1. You can sync directories with each other. Example product: Tivoli Directory Integrator (available for both z/OS and Linux on z, and other platforms)., 2. You can manage identities in multiple directories through a common identity provisioning/management/revocation service. Example product: Tivoli Identity Manager (available for both z/OS and Linux on z, and other platforms). 3. You can keep separate directories and identities but manage single sign-on through a front-end service (Web, client OS, etc.) which handles your different credentials on your behalf. Example product: Tivoli Access Manager (available for Linux on z, and other platforms; TAM supports z/OS LDAP and RACF). Other vendors in some or all of these solution categories include, in no particular order, CA, Novell, Cisco, RSA, Entrust, BMC, Vanguard, Sun, Oracle, and several others. HP just exited the market. You are correct that not all of them support z/OS, although some do. I agree that "politics" (or, more charitably, security policies) are a big part of the discussion. And this works both ways. There's a school of thought that RACF is sacred, and it should be its own security "zone," separated from those awful/evil/vulnerable other platforms, because our company applications and data on the mainframe are just so darn sensitive. I'm sympathetic to that argument, although it's oversimplified. (People are accessing mainframes from vulnerable clients, after all.) What I really think it means is that there's high value to extending RACF and z/OS LDAP-related services across the enterprise, making the mainframe the "security hub" in order to help protect and secure even more company assets, to get at least partial benefit even if these assets aren't lucky enough to be hosted on the mainframe. Note that there is enormous value in having security services hosted on the mainframe simply for availability reasons. Just as with encryption (if you lose the keys, you lose the data), if you lose your authentication/authorization services you lose access to the applications and data. So authentication/authorization (in particular) is one of those mission critical services in most organizations. I think this is probably a reason why some non-mainframe single sign-on implementations flounder. By the way, one of the lessons we learned is that you need the application developers to participate in the common security regime. Inside IBM there's a lot of "marketing" to line-of-business and other application development teams to use our common directory services, including an internal Web site describing how to do it, with environment-specific examples (such as code examples and downloadable kits). Otherwise security is an afterthought with many application designers and programmers. And, as the "single sign-on" universe grew within our company, employees themselves became some of the best marketers because they wouldn't tolerate that odd application that didn't participate. (That's called a "network effect."), Hope all that helps. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
