A trick to determine the vendor of an unmarked (or physically inaccessible) AP is to learn its BSSID (which is basically the MAC address of the AP's 802.11 wireless NIC). The first half (the first 3 bytes == 6 hex digits) of a typical MAC address in an IEEE OUI (Organizationally Unique Identifier). You can look up the OUI to company mapping on the IEEE website.
An easy way to find the BSSID of any AP you can associate to is to option-click the AirPort menu extra (the AirPort icon menu in the menubar) while associated. You'll see several extra pieces of diagnostic information in grey, including the BSSID. So if the BSSID show up as, say, "0:1f:f3:12:34:56", the OUI is "00:1f:f3". The IEEE lookup on the page linked above doesn't like colons, so either remove them like "001ff3" or replace them with hyphens like "00-1f-f3". Note that Mac OS X often drops the the leading zero in any given byte in a MAC address, so if any byte of the MAC address only has one digit, you'll have to put the leading zero back in before searching for it on the IEEE OUI lookup.
Some times an OUI lookup fails to conclusively identify the manufacturer of an AP. For example, if the 2's place bit of the first byte of the MAC address is set, that's the "local" bit, which means that the MAC address is "locally administered", which means it's not a real guaranteed-globally-unique MAC address, but one that was "made up", perhaps by the network administrator who configured the AP. Other times, the OUI lookup will tell you who made the wireless NIC card of the AP, or who made the chipset on the card, but not who made the AP itself.
If the OUI lookup approach doesn't work for you, take a picture of the AP and post it. Maybe someone here will recognize it. Also, what cables can you see going into the APs? Do you see one or more coax cables but no Ethernet cable? Then the box you're looking at is probably just an external antenna, and the real AP is out of view, perhaps above the drop-ceiling. You could also be looking at some other piece of building infrastructure, like an industrial-style smoke detector, heat detector, a motion sensor for automatic lights, or an antenna for some completely unrelated wireless technology (like an indoor cell signal repeater). Just because your Wi-Fi signal strength is good near that box doesn't mean that box is your actual AP. I learned that lesson the hard way -- I misidentified a mostly-unmarked white antenna enclosure as being the AP in a building because my Wi-Fi signal strength was strong near it, and didn't realize that it was an antenna for an indoor cell signal repeater, and the real AP happened to be hidden above the drop ceiling two meters farther down the hall.
If your APs turn out to be Cisco boxes running in lightweight mode, beware of these Cisco bugs:
CSCsy73154—The access point does not forward the DHCP offer to the client.
...which is sometimes called:
CSCsz22901—The access point does not forward the DHCP offer to the client, so the client fails to get an IP address.
My site was running Cisco APs in lightweight mode (specifically 1252s in B/G/N + A/N HT20 mode, but I don't know that it matters), in conjunction with various models of Cisco Wireless LAN Controllers (WLCs) and Wireless Service Modules (WiSMs).
Even without any security enabled on a certain network, some Mac clients would sometimes fail to get DHCP leases. 802.11 monitor-mode packet traces, in conjunction with wired Ethernet packet traces between the APs and the controllers (showing the unencrypted LWAPP session) showed that the clients were successfully associating and sending their DHCP Discover packets, and the DHCP server was replying with a DHCP Offer, and the WLC/WiSM was forwarding that DHCP Offer to the Cisco AP, but the Cisco AP was never forwarding that DHCP Offer along to the client.
These issues were fixed in the following Cisco WLC/WiSM software releases from the summer of 2009:
4.2.207.0 (not to be confused with 4.2.205.0 which does NOT have the fix)
5.2.193.0
6.0.x.x -- I believe any public 6.x release has the fix.
If your site is running a 5.0.x.x or 5.1.x.x release on your Cisco WLCs/WiSMs, you'll need to evaluate upgrading to 5.2 or 6.0, because I think if Cisco was ever going to fix this for those build series, they would have done so by now.